harness-skill-creator

name	harness-skill-creator
description	Use when bootstrapping or tightening the smallest harness-oriented skill from an existing repository, workflow, evaluation corpus, or harness-analysis chain. Trigger for meta skills, reusable harness workflows, Qoder/Codex plugin skill sets, skill blueprints, and harness-analysis-like skills that need evidence-backed references, validation gates, and qodercli forward-tests.

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.
3. Load references/bootstrap-patterns.md after the first inventory. Use it to extract patterns, not product-specific rules.
4. 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
5. 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.
6. 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.
7. 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.