Create the smallest skill that makes another agent repeat one harness job with evidence, validation, and clear ownership.
Workflow
- Resolve source, target, and host: canonical
skills/<name>/,.agents/skills/wrapper, or both. - Inspect the source chain before designing: entry
SKILL.md, first-hop references, scripts, validators, templates, specs, tests, plugin manifests, and any real smoke evidence. - Load
references/bootstrap-patterns.mdafter the first inventory. Use it to extract patterns, not product-specific rules. - Draft the minimum viable skill map:
- skill name and trigger sentence
- one job the skill owns
- files to create under
skills/<skill-name>/, usuallySKILL.mdplus one reference - evidence boundary and validation commands
- forward-test prompt and pass/fail gates
- Initialize new canonical skills with the system
skill-creatorhelper when available. Addscripts/only for stable repeated automation; keep ad-hoc evaluation prompts out of runtime scripts. - Write the
SKILL.mdas a router. Put trigger conditions in frontmatterdescription, keep the body short, and route detailed rules to first-hop references. - Validate locally, then forward-test. Treat qodercli output as model evidence; local validators and file inspection decide pass/fail.
Design Gates
- Prefer one skill over a stage tree until the target process proves multiple reusable stages.
- Copy ownership shape, not product names, branch policy, private commands, or source-specific team routing.
- Keep
.agents/skills/as a wrapper or mirror when the workflow is shared by the plugin; canonical judgment belongs under rootskills/. - Do not add install, network, server, migration, or dependency-changing commands unless the user requested them and source evidence supports them.
- Prefer portable Node/Python validators or target-owned commands. Do not default generated validation gates to Unix-only
grep/findchecks. - In attachment-only or no-tools forward-tests, never emit tool-call markup, shell probes, or inspection plans; return the skill map with
status: "insufficient-evidence"when needed. - Forward-test
filesis a string array ofskills/<skill-name>/...paths, not objects. - If the generated skill cannot pass
quick_validate.py <skill-dir>, do not describe it as usable. - After any forward-test, verify git status or file inventory for every repo the model was allowed to read or write.
Validation
Run the narrowest useful gates for the created skill:
python3 <skill-creator-root>/scripts/quick_validate.py <skill-dir>
qodercli --cwd <neutral-dir> --plugin-dir <harness-root> -p "<forward-test prompt>"
qodercli plugin validate <harness-root>
Reject missing frontmatter, stale placeholders, broken links, unsupported commands, source-only assumptions, pseudo tool calls, or broad reports.