Files
holocron/plugins/kyberforge/.apm/skills/skill-author/references/improve.md
Defame1297 5d0f988ed8 fix(kyberforge): resolve PR #144 review and audit round 3
- factory-audit: hook events judged per deployed target after apm's
  rename (Claude/Copilot event sets FAIL, others SUGGESTION); Claude
  plugin layouts accepted as hook sources; interpreter options and
  sh -c strings checked; bats 378 -> 386
- primitive-author: Must 4/5 match the audit; reference hand-back
  points at the right steps; Step 4.2 --target all fallback
- skill-author: new-skill.sh repair only on the template marker line,
  so complete skills stay a no-op; provenance and calibration text
- forge: restore "already named" qualifier; drop false HITL claim
- apm-workflow: token example uses an env var
- docs/hooks.md: the apm-hooks.json sidecar is committed, not ignored

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KkT7RSDwDbmrM9T34b6sTi
2026-09-28 21:32:18 +00:00

5.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 — Signal sources

The dispatch in SKILL.md Step 1 has already confirmed the directory and at least one signal.

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

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

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/.

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 does not meet the contract has to bring it into compliance 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.

Retrofit against the number that actually failed: the audit reports description characters and body-only words separately. Audit the skill in its real package directory, never a scratch copy, where boundary resolution reports DID NOT RUN and exits 0 without checking anything. Cut in this order, stopping once the gate clears; the order puts the cuts that lose the least behaviour first:

  1. Gotchas that paraphrase a step below them — delete the Gotcha, keep the step.
  2. Spec restatements — text repeating a published spec, a tool's --help, or a limit the validator already enforces.
  3. Capability enumeration — keep one capability clause in the description; drop the rest.
  4. Per-flow prose — move each flow into its own references/ file behind a dispatch table.

Still over after all four means the skill does two jobs: split it rather than compressing prose.

Re-cite what moved. After content moves between files, update references/sources.md's Contributing files for every slug whose content moved, and drop any file the edit deleted. factory-audit's scripts/validate-provenance.sh fails a listed file that no longer exists, but exits 0 when content moved out of a file that still exists and still lists the slug, so that stale claim ships unless you fix it here.

Re-check every relocated gate's reachability. A Gotcha or gate moved out of the body into one flow's references/ file is invisible to every other branch, and the word counts improve either way. For each one you move, list the flows that need it: it belongs in one flow's file only when exactly one flow reaches it, otherwise in the body's common-gates section.

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

Do not create a new script unless a signal explicitly calls for it. Writing one from scratch requires out-of-scope transcript analysis — flag the opportunity as a suggestion instead.

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.

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.