Files
holocron/plugins/kyberforge/.apm/skills/skill-author/references/improve.md
Defame1297 3811f5481b fix(kyberforge): unblock the scaffold and finish the #125 and ADR-0022 edits
Three related half-applied changes from #130, each leaving the corpus in a state its own
documentation contradicts.

Why:
- `assets/templates/SKILL.md` shipped `metadata:` fully commented out, and `new-skill.sh` only
  substitutes SKILL_NAME. Every scaffolded skill therefore lacked the `metadata.version` ADR-0022
  made mandatory and was blocked at first commit by the very hook this PR added. The commented
  example also read `"1.0"` — neither the `0.1.0` new-skill seed nor valid semver.
- `agent-audit/references/scope-project-user.md` still joined `disable-model-invocation` and
  `user-invocable` with a slash — #125's defect verbatim — while pointing the reader at the file
  this PR had just corrected to say the opposite.
- ADR-0022 required the "when present" bump conditional dropped and `metadata.version` moved into
  create.md's required list. It was dropped from SKILL.md but left in README.md, and the field was
  edited in place under a heading that still authorises removing it entirely.

Implementation notes:
- The template emits `metadata: version: "0.1.0"` live, captioned as required, with the optional
  keys left commented. `new-skill.bats` gains a case asserting a live key and three-part semver, so
  this cannot regress.
- `description-quality.md` now asserts only what the vendored Copilot research supports: two fields
  with opposite defaults, and the retired `infer` replaced by the pair rather than by either alone.
  The unsupported negative it previously stated as fact is gone.
- The `1.0.0` retrofit seed is stated in improve.md and retrofit.md, which the retrofit flow
  actually reads — create.md, where it lived, is unreachable from that path. The compression item
  moved out of the file-churn checklist, whose preamble excluded the wording-only change it covers.
- Executable git commands in these three skills now carry the ADR-0023 rtk prefix.

Refs: #125, #127
ADR: 0022, 0023
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EeH8SCbcrCAQrtymkNuhKP
2026-09-09 05:15:23 +00:00

4.6 KiB

source_keys
source_keys
agentskills-best-practices
agentskills-evaluating-skills
agentskills-optimizing-descriptions

Improving an existing skill

Return to SKILL.md Step 4 once Step 4 below is done — validation, versioning and commit verification are shared with the create flow and are not repeated here.

Step 1 — Verify inputs

Confirm the skill directory path exists and that at least one improvement signal is present in the conversation or a referenced file.

If the skill directory is missing, ask for it. If no signals are present, stop: "This skill applies existing signals to a skill. For a blind review without signals, use /skill-audit instead."

Signals can come from anywhere in the conversation or referenced files:

  • Grill session output (most common predecessor in the factory sequence)
  • /skill-audit findings (PASS/FAIL/SUGGESTION punch list)
  • Human feedback (feedback.json, inline in conversation, PR or issue comments)
  • Session context describing what went wrong

Also verify the name field in frontmatter matches the skill's directory name exactly.

Step 2 — Gather and group signals

Read the current skill files (SKILL.md and any files in scripts/, references/, assets/, tests/). Then collect all signals from the conversation and any file paths the user has referenced.

Group signals by root cause, not symptom. Patching per symptom is the default failure mode: three eval failures may all trace to one missing instruction. Ask: "What single gap in the skill causes this cluster of failures?" One root cause → one fix. Do not make a separate edit for each symptom.

Example:
- Session context: output format is wrong on every run
- Audit finding: no output template defined
- User feedback: "I always have to ask it to format the output"
→ Root cause: SKILL.md has no output format specification → one fix: add an output template

Step 3 — Announce planned changes

Before editing, state:

  • Which root causes were identified and what evidence supports each
  • Which files will be changed and what will change in each

Then proceed — edits are reversible via git, no approval checkpoint needed.

Step 4 — Apply changes

Edit any file in the skill directory that the signals point to: SKILL.md, scripts/, references/, assets/, tests/, README.md.

Generalize, do not patch. Find the underlying gap, not the specific example that failed. A fix scoped only to the test cases you have seen will overfit and perform worse on new inputs.

Keep it lean. Remove instructions that are not pulling their weight. For every sentence you add, ask: "Would the agent get this wrong without it?" A shorter, focused skill consistently outperforms an exhaustive one.

Explain the why. Reasoning-based instructions outperform rigid directives. If you find yourself writing a rule in all caps (ALWAYS/NEVER), reframe it: explain why the behavior matters so the agent can apply judgment in edge cases.

Retrofit before extending. Any edit to a skill that predates ADR-0020 has to bring it into the contract first — the gates are hot and carry no baseline file, so a one-line fix to a non-compliant skill cannot be committed until the description and body meet references/contract.md. Treat that retrofit as part of the same change, not a follow-up.

If the skill's description exceeds 250 characters, or its body-only word count exceeds 600, read references/retrofit.md before editing. It carries the ordered cut procedure, the mutually-exclusive-flows test, the reference-file conventions this flow needs, the collateral checklist for README.md and references/sources.md, and a worked description retrofit. Do not improvise the cuts — four dry runs invented six to ten different answers to the same questions.

If a signal points to a script or reference file, edit that file directly rather than adding a workaround in SKILL.md.

A skill carrying no metadata.version is seeded at "1.0.0", not bumped — SKILL.md Step 4's patch bump presumes a version to bump, and ADR-0022 reserves "0.1.0" for a newly created skill. references/retrofit.md carries the reasoning.

Check for regressions before handing back. SKILL.md Step 4 tells you to resolve every FAIL, which says nothing about a check that passed before these edits and no longer does. Compare the closing audit against the skill's pre-edit state — a PASS that has become a SUGGESTION, or a SUGGESTION that has become a FAIL, is damage this flow caused and is in scope for it. Only the improve flow can make that comparison; the create flow has no prior state to compare against.

Then return to SKILL.md Step 4.