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 the solution space — step back and look for a fundamentally different angle.

The point is not to document alternatives for posterity. It's to catch yourself before committing to an approach that has a better option sitting next to it.

Anti-pattern: strawman alternatives. "Alternative: rewrite everything from scratch. Rejected: too much work." This doesn't force any real thinking.

Open Decisions

If the spec lists open decisions, naming alternatives, or "options under consideration," resolve every one before materializing MCP work items or dispatching implementation. A spec with unresolved choices left in it is not ready to dispatch.

Mid-implementation pivots cost 5-10× the time of a pre-dispatch user round-trip. Once an agent is in a worktree, a naming change or interface change requires unwinding partial code, retracting commits, re-spec'ing the work, and re-dispatching. Resolving the same question before dispatch is a single short conversation.

The orchestrator should pause for a user round-trip rather than dispatch with ambiguity. A short pause now is cheaper than a partial implementation later.

If a decision genuinely cannot be resolved at planning time (e.g., depends on a measurement only available post-implementation), it isn't an "open decision" — it's a deliberate two-phase approach. Document it as such, scope the first phase explicitly, and create a separate work item for the second phase. Don't leave the choice latent in the spec.

Cite Contracts, Don't Restate Them

When a spec prescribes call sequences, API semantics, or any fact owned by another artifact (a tool description, a source file, another spec), cite the authoritative location and direct the implementer to verify against it before relying on it. A restated copy drifts from its source — and a spec's confident restatement reads as authority to the agent that implements it faithfully.

If the spec claims something was verified, name exactly what was checked. "Verified against source" that checked one path while prescribing another is how a partially verified claim ships a defect (two sessions of evidence: task-scope facts contradicting target files, 2026-07-27; a design prescribing advance_item trigger sequences that gate-block, 2026-07-31).

This discipline applies to the plan artifact as much as to spec notes. Specification notes are generated from the plan and inherit its errors silently, so plan-mode output that names a file path, tool contract, or call sequence must cite the authoritative location and be verified against it before any child item inherits it. The rule above was first installed for spec notes only (2026-07-31); the next occurrence (retro 6d562acb, 2026-08-04) originated one artifact upstream — the approved plan asserted a dispatch surface at ralph-iteration.md when the live file was skills/ralph/iteration-prompt.md, and a child's specification note and its first review verdict both inherited the wrong path. If a further occurrence still originates in a plan, treat that as evidence that prose rules cannot carry this load and add a mechanical check (every path a plan names must resolve on disk).

Semantic claims carry a file:line. Any sentence that states nullability, redaction, ownership, or an honest limit (what a guard does NOT cover) cites the file:line that establishes it. This holds for spec notes and for everything written from them — a CHANGELOG bullet, an API doc line, a hook or KDoc header comment. Worked case (2026-09-29, #384): the spec and a hook header said note attribution is shown only when the caller is ADMIN and the flag is false; the code redacts only when redactNoteAttribution && !isAdmin (AttributionRedactor.kt:53), so it is shown when ADMIN OR the flag is false. The error survived from spec to header because the sentence was written from intent and no line was opened. For a NEW-SURFACE claim with no code yet, cite the spec decision that fixes the behavior and mark the claim for the reviewer to confirm in the diff. Prose that is not a semantic claim needs no citation — this is not a blanket citation rule.

Verification Commands

Before writing a verification command into a spec, plan, or skill, run it twice: once on the target platform against known-good input (it must succeed) and once against known-bad input (it must fail). A command that has not been shown to fail on bad input has not been shown to verify anything — a check that silently always passes is worse than no check, because it is trusted. Record the command in the form actually executed, not a reconstruction.

Non-Goals

Name what someone might reasonably expect this work to include but that is deliberately excluded. If you cannot name a single non-goal, the scope is not tight enough.

Non-goals prevent scope creep during implementation. Without them, agents tend to gold-plate — adding adjacent improvements that weren't asked for and that introduce unplanned risk.