Update Skill

Modify an existing Claude Code skill the safe way: read first, audit, propose, diff, confirm, then write. Every change is shown to the user before it lands. Renames and structural changes are treated as breaking by default and bump the version. Self-contained — every rule, audit item, and workflow step lives inside this directory. No invocation of or dependency on any other skill — and neither do the skills edited by this tool (see rule 9 below).

For creating a brand-new skill from scratch, use generate-skill. This skill only modifies what already exists.

Core rules

1. Read before write. Every invocation starts by reading the target skill end-to-end (SKILL.md plus every companion file). Never edit an unread file.
2. Audit before propose. Produce a findings list against the audit checklist before suggesting any edit. Surfaces issues the user did not ask about.
3. Diff before confirm. For every file to change, show a unified diff (or per-file before/after) before writing.
4. Confirm before write. Never apply a change without explicit user opt-in. Per-file or per-change-set acceptance — either approach works, but the opt-in must be explicit.
5. Auto-bump version using semver. Every accepted change set bumps at least PATCH. MAJOR for breaking changes (trigger surface, file renames/removals, workflow reordering), MINOR for new capabilities, PATCH for fixes and refinements. Surface the bump level in the diff so the user can override.
6. Preserve the user's hand-edits. Don't rewrite styling, wording, or formatting the user picked unless they explicitly asked. Targeted edits, not opportunistic rewrites.
7. Never silently rename or move. A rename changes how the dispatcher finds the skill — always treated as breaking. Update name: in frontmatter, the directory itself, and any cross-references in companions, all in one change set.
8. No fabricated references. Don't add tool names, package names, URLs, or RFCs that cannot be verified. Audit the skill for fabricated references; never introduce new ones.
9. Self-contained by default; ask before any cross-skill reference. Don't add a reference to another skill — in the target's description, body, companions, scripts, or examples — unprompted. If the user asks for one, or the target already has one, don't silently include or strip it: ask whether to keep the reference (it makes the target depend on that skill being installed), inline the capability instead, or phrase it as a user action. Runtime tools and user-named agents may stay if they actually exist. See RULES.md.

Full audit checklist in AUDIT.md. Workflow detail in WORKFLOW.md. Invariants and edge-case rules in RULES.md.