Update Skill

Update Skill

Update an existing skill from explicit conversation feedback. Read the target skill before editing, identify the smallest canonical file that owns the rule, apply the change, and validate links and metadata afterwards.

Use

Call this skill only after feedback or a correction is concrete enough to store:

/update-skill <skill-name>

Do not update a skill merely because an output was generated. The conversation must contain a durable preference, rule, boundary, or workflow correction.

Writer routing

When the target is writer, first resolve the active skills root from the runtime configuration and read <skills-root>/writer/MAINTENANCE.md. Do not hardcode a user-specific absolute path or assume ~/.claude/skills.

Classify the feedback as a shared rule, primary type, type add-on, lens, source object, domain, format, format integration, reviewer, check, or routing rule. Edit the corresponding canonical module. Update writer/SKILL.md only when the feedback changes module selection or a hard boundary. If a feedback item says that a repository implementation must not be treated as a paper fact, update writer/references/objects/paper.md and/or objects/repository.md, not a generic explanation paragraph. If it changes module selection, reviewer activation, format precedence, or compatibility behavior, update writer/SKILL.md only for that routing contract.

Keep one rule in one canonical location. Do not create a compatibility wrapper, copy an old skill, or add a format integration merely to repeat rules already expressed by a type and a format. The legacy writer entry points have been removed. If a cross-module contract changes, update the owning module first and make only the smallest link or route adjustment.

Process

1. Review the conversation and state the durable feedback in one sentence.
2. Locate the target skill under the active skills root. Do not assume ~/.claude/skills; use the actual configured skills repository.
3. Read the target SKILL.md and any maintenance/index file it names.
4. Read the canonical module and nearby references needed to avoid duplication.
5. Apply the smallest edit that captures the feedback; preserve unrelated user changes.
6. Search for stale paths, duplicate wording, and old entry-point names. For writer, check MAINTENANCE.md, the module map, format integrations, and any retained thin wrappers.
7. Validate YAML frontmatter, referenced files, and relevant evals. Compile or render only when the changed rule affects source or layout.
8. Report the changed files, the learned rule, and validation results. Create a git commit only when the user explicitly requests one or the surrounding workflow explicitly requires it.

Feedback categories

• Style: tone, sentence shape, paragraph density, punctuation, or emphasis.
• Structure: section order, narrative before elements, or argument shape.
• Source policy: citations, evidence hierarchy, claim identity, or unknowns.
• Format syntax: Markdown, LaTeX, Typst, or another source language.
• Type behavior: report, explanation, textbook, or a bounded variant.
• Workflow: routing, reviewer isolation, rendering, or validation gates.

Prefer a concise rule with a concrete trigger and expected behavior. Preserve examples only when they clarify a fragile boundary.