spec-quality

# Specification Quality Framework This skill defines the minimum thinking floor for plans and specifications. The sections below represent what every plan must address. They are not a ceiling — if the problem demands additional analysis, add it. But these areas must not be skipped. **Where this applies at each level:** for a `feature-implementation` parent, the queue-phase `feature-summary` note stays lean by design (goal, findings→tasks table, dependency edges, a pointer to non-goals — target under 2k chars) and does not carry the full disciplines below. The disciplines below apply in full to each child's `task-scope` note (or to `specification`/ `diagnosis` notes on schemas without a parent/child split) — that is where alternatives, blast radius, risk flags, and test strategy must actually be worked through. The value of a spec is entirely in the thinking it forces before code is written. If a section doesn't change how you'd approach implementation, it isn't earning its place. Every sentence should either prevent a mistake or force a decision. --- ## Specification Disciplines These are the required areas of analysis. Each one exists because skipping it leads to a specific, recurring class of failure. ### Alternatives Considered Evaluate at least two real approaches. "Do nothing" always counts as one. For each alternative, state what it would look like and the specific trade-off that led to its rejection. If you can only think of one approach, you haven't explored t...