harness-skill-creator

Harness Skill Creator

Create the smallest skill that makes another agent repeat one harness job with

evidence, validation, and clear ownership.

Workflow

1. Resolve source, target, and host: canonical skills/<name>/, .agents/skills/ wrapper, or both.
2. Inspect the source chain before designing: entry SKILL.md, first-hop

references, scripts, validators, templates, specs, tests, plugin manifests,

and any real smoke evidence.

1. Load references/bootstrap-patterns.md after the first inventory. Use it to

extract patterns, not product-specific rules.

1. Draft the minimum viable skill map:

• skill name and trigger sentence
• one job the skill owns
• files to create under skills/<skill-name>/, usually SKILL.md plus one reference
• evidence boundary and validation commands
• forward-test prompt and pass/fail gates

1. Initialize new canonical skills with the system skill-creator helper when

available. Add scripts/ only for stable repeated automation; keep ad-hoc

evaluation prompts out of runtime scripts.

1. Write the SKILL.md as a router. Put trigger conditions in frontmatter

description, keep the body short, and route detailed rules to first-hop

references.

1. 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 root skills/.

• 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/find checks.
• 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 files is a string array of skills/<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.