$npx -y skills add WrathZA/skillforge --skill skill-forge-updateGuided update for an existing SKILL.md: structured recap, drift detection, change elicitation with conflict checking, per-item application with approval, and post-change quality gate. Use when an existing SKILL.md needs revision, modification, or improvement.
| 1 | # Skill Forge Update |
| 2 | <!-- Pattern: Process (guided skill update workflow) --> |
| 3 | |
| 4 | Understand before touching. Confirm before applying. Judge what you've done. |
| 5 | |
| 6 | --- |
| 7 | |
| 8 | ## Phase 0 — Load & Recap |
| 9 | |
| 10 | **Skip condition**: If a `/skill-forge-recap` result for the same skill is already in the conversation context, verify the skill name matches, skip Phase 0 entirely, and proceed to Phase 1 using that recap. Ensure the agentskills spec cache (`~/.claude/tmp/agentskills-spec-<today>.md`) is current before Phase 1 — frontmatter validation in Phase 1 requires up-to-date field lists. |
| 11 | |
| 12 | **MANDATORY** — Before reading the skill, fetch current platform docs in parallel: |
| 13 | - **WebFetch `https://agentskills.io/specification`** — live frontmatter requirements and field constraints |
| 14 | - **WebFetch `https://code.claude.com/docs/en/skills`** — Claude Code-specific features (new frontmatter fields, description char limits, invocation controls) |
| 15 | |
| 16 | If either fetch fails, proceed with spec knowledge already in context; note "spec/docs unavailable — using cached knowledge" in the drift check output. |
| 17 | |
| 18 | Note any constraints or features relevant to the skill being updated. These inform both the recap and the consistency checks in Phase 1. |
| 19 | |
| 20 | Identify the target skill. The user may name it, paste a path, or point to it in context. |
| 21 | |
| 22 | If no skill is identified, ask once: "Which skill do you want to update? (name or path)" |
| 23 | |
| 24 | If the named skill file does not exist, stop: "Can't find [name] — check the path and re-invoke." |
| 25 | |
| 26 | Read the skill completely. Produce a structured recap: |
| 27 | |
| 28 | ``` |
| 29 | ## [Skill Name] — Recap |
| 30 | |
| 31 | **Does:** [1–2 sentences: core task and when it fires] |
| 32 | **Pattern:** [Tool / Process / Navigation / Mindset / Philosophy] |
| 33 | **Workflow:** [numbered phases or key steps, one line each] |
| 34 | **NEVER rules:** [count] covering [topics] |
| 35 | **References:** [list references/ files, or "none"] |
| 36 | ``` |
| 37 | |
| 38 | **Drift check**: before flagging anything, ask: *would an agent reading only the description load this skill at the right moment, and would what loads match what the description promised?* That question — not symptom-matching — is the test. Then compare the frontmatter `description` field against the actual implementation. If they diverge (description omits key phases, misnames the trigger, or claims behaviour the skill doesn't exhibit), surface the discrepancy: |
| 39 | |
| 40 | ``` |
| 41 | Drift detected: [what the description says] vs [what the skill actually does] |
| 42 | (s)uggest fixes / (i)gnore and continue |
| 43 | ``` |
| 44 | |
| 45 | On `(s)`: produce a corrected description and add it to the Phase 1 change list as item 0 (applied first). On `(i)`: proceed without changing the description. |
| 46 | |
| 47 | State the recap to the user. Confirm: |
| 48 | |
| 49 | ``` |
| 50 | Does this match your understanding? (y)es / (n)o |
| 51 | ``` |
| 52 | |
| 53 | On `(n)`: collect the correction, update the recap, confirm again before proceeding. After two corrections without agreement, ask directly: "What specifically is inaccurate?" rather than guessing again. Use that answer to produce a third recap iteration; if it still doesn't match, stop and ask the user to draft the recap themselves before continuing. |
| 54 | |
| 55 | --- |
| 56 | |
| 57 | ## Phase 1 — Change Elicitation Loop |
| 58 | |
| 59 | **Goal**: A numbered change list that is specific, unambiguous, and consistent with the existing skill and principles. Do not touch the file until the list is confirmed. |
| 60 | |
| 61 | ### Loop |
| 62 | |
| 63 | Elicit changes, paraphrase back with the updated change list and consistency check below, then ask: |
| 64 | |
| 65 | ``` |
| 66 | (c)ontinue / (r)evise |
| 67 | ``` |
| 68 | |
| 69 | On `(r)`: collect more input, update the change list recap, loop again. |
| 70 | |
| 71 | On `(c)`: lock the numbered list and proceed to Phase 2. |
| 72 | |
| 73 | After each response, produce: |
| 74 | |
| 75 | ``` |
| 76 | ## Proposed changes |
| 77 | |
| 78 | 1. [Change — specific enough to apply unambiguously] |
| 79 | 2. ... |
| 80 | |
| 81 | ## Consistency check |
| 82 | |
| 83 | [ ] Rule conflict: [conflicting rule text, or "none"] |
| 84 | [ ] Duplicate guidance: [overlapping section, or "none"] |
| 85 | [ ] Principles violation: [issue, or "none"] |
| 86 | [ ] Scope unclear: [vague term that needs scoping, or "none"] |
| 87 | ``` |
| 88 | |
| 89 | ### What triggers each consistency flag |
| 90 | |
| 91 | **Rule conflict**: New NEVER contradicts an existing NEVER; new step breaks existing flow order. |
| 92 | |
| 93 | **Duplicate guidance**: New section covers the same ground as an existing one — flag and ask: "merge or replace?" |
| 94 | |
| 95 | **Principles violation**: NEVER missing WHY or INSTEAD. Request for generic advice ("write clean code", "be thorough"). Any rule that restates what Claude does by default. Unknown frontmatter field added (valid Claude Code extensions: `when_to_use`, `argument-hint`, `disable-model-invocation`, `context`, `agent`, `model`, `effort`, `paths`, `hooks`, `shell`, `user-invocable`, `allowed |