spec-impactlisted

Use before changing how something already works - "what breaks if we change the refund window?", "who else depends on this before I touch it?". Finds everything the change ripples to across other capability specs, decision records and code, so the change does not land having updated only the obvious file.
repository-standards/core · ★ 4 · Testing & QA · score 77

Install: claude install-skill repository-standards/core

# spec-impact Run when you are about to change how a capability works. Start from the **spec**, then find the ripple. This is analysis - do not edit code yet. ## Steps 1. **Primary capability.** Which `specs/<capability>/` does this change belong to? If it is a genuinely new domain (rare), flag it - do not create a new capability spec just because a request or ticket exists. Search existing capabilities first. **Check the primary spec's `Status` first.** A `retired` capability stays in the repo as a record, not as something to extend - if the change targets one, stop and say so, and point at the BDR/ADR that retired it. A genuinely new need in that area is a new capability, specced fresh, not a reopening. **Check `Status` on every capability this reaches, not only the primary** - the ripple below finds retired specs too, and skipping them is how a retired spec ends up stating something a later change made false. A retired **ripple** target is not a stop: report it as a correction target (ADR-036), so the change fixes what it falsified rather than leaving it. 2. **Read** the primary spec and the code it maps to (`specs/capability-map.json`). Read the topic's dossier too, if it has one (`docs/discovery/<topic>/`, ADR-024)