spec-updatelisted

Use when behaviour is about to change and the spec needs to say how it will work afterwards, before the code moves - "we're changing how cancellations work, spec it first", "this branch changes X, make the spec match". On a branch the spec is the target and the git diff is the delta; updates every affected spec, not only the one that came to mind.
repository-standards/core · ★ 4 · Code & Development · score 77

Install: claude install-skill repository-standards/core

# spec-update The spec is the driver. Change it **first** - describe how the capability should work and look after this change - then plan, then code. This is the "spec changed during work" step. ## Steps 1. From `spec-impact`, take the primary + affected capabilities. If any of them has `Status: retired`, stop before **extending** it - `spec-impact` should have already caught this, but do not extend a retired capability just because its spec file is still there to edit. **Correcting it is a different act, and it is required** (ADR-036). If this change makes a statement in the retired spec false - a renamed enum, a dropped table, a rule that no longer holds - fix that statement here, in this pull request, the same way a live spec's would be fixed: say what the capability did, name the change that superseded it, leave `Status: retired` alone, and add no behaviour. `retired` freezes what the capability does, not whether its file tells the truth (R4). If you cannot write the correction without deciding something, it is not a correction - stop and write the record. 2. **Ask what the change does to each spec's boundary before editing it** - the calls are in "Questions this skill must ask", below. Then, for **each** affected