Agent Skill Installation Workflow
Rule
Installing a skill means making it usable and discoverable by intent, not merely archiving its files.
Required Workflow
When the user asks to install a skill from GitHub or another source:
- Inspect current git status.
- Fetch the narrowest relevant upstream path, preferably with sparse checkout when the user provides a subdirectory URL.
- Preserve a source mirror under
D:\agent-resources\repos\<name>or another documented D-drive source path when useful. - Install usable skill files under
D:\agent-resources\skills\<group>\<skill-name>and link them into supported agent homes when they should be global. - If a pack contains independently triggerable sub-skills, install those sub-skills directly as well when that improves usability.
- Read the upstream
SKILL.mdand nearby references/scripts before summarizing. - Install or download missing narrow dependencies into
.wiki-tmp/or another D-drive project-local cache when practical. - Run realistic validation:
- Guidance-only skills: verify install paths, frontmatter, trigger intent, and enough content to be discoverable.
- Scripted skills: run help/version commands and at least one non-destructive smoke test.
- Browser or publishing skills: verify runtime setup, but require explicit user confirmation before account actions, submissions, or live posts.
- Update
D:\agent-resources\SKILL-INDEX.mdwith conciseWhat,When, andPathentries so future agents can trigger the skill implicitly. - Record function, contribution, concrete usage, local paths, dependencies, smoke-test results, and limitations in wiki pages when public-safe and durable.
- Update
wiki/index.md, relevant entity/topic pages,wiki/log.md, andwiki/catalog.jsonwhen wiki pages change. - Run
python scripts/wiki.py catalogandpython scripts/wiki.py lint. - Stage only scoped resource installs, links, docs, and wiki updates.
- Commit and push.
Anti-Toyification Rule
- Do not skip dependency installation or runtime verification just to finish faster.
- Do not report a skill as usable when only files were copied and executable dependencies were not checked.
- If a dependency cannot be fully installed, record the exact blocker and the highest non-destructive validation achieved.
- Prefer D-drive local/cache installs over C-drive or global installs unless the user explicitly asks otherwise.
- Do not commit downloaded toolchains, build artifacts, browser profiles, account state, or caches unless they are deliberate source files.
Current Examples
- paper-orchestra: source mirror plus 9 installed skills and wiki usage pattern.
- content-creation-publisher: aggregate skill plus 5 direct sub-skills, Bun runtime validation, and publishing safety boundary.
- frontend-design: guidance-only frontend aesthetic skill installed and documented.
- chrome-automation: executable browser automation skill installed with D-drive agent-browser runtime and real CDP smoke test.
- feishu-bridge and lark-cli: official Lark/Feishu CLI runtime installed on D drive, selected official lark-* skills installed, router skill added, command-level smoke tests passed, and OAuth-gated live-resource tests explicitly marked pending.
- readme-blueprint-generator: GitHub
awesome-copilotREADME specialist skill mirrored locally, installed under.codex/skills, enhanced for top-tier README rewrites, and used to refresh the project README.
Counterpoints And Gaps
- AMBIGUOUS: Some skills are pure instruction documents; their “test” is necessarily install/discovery and future-output quality rather than a deterministic command.
- AMBIGUOUS: Some executable skills need account access, credentials, paid APIs, or public posting; validation should stop at non-destructive smoke tests unless the user explicitly approves live actions.
- INFERRED: The workflow should not force broad global toolchain installs when a narrow D-drive local runtime can validate the skill.