write-spec

To turn a vague feature request into an implementation specification, use guided discovery to clarify scope, analyze tradeoffs, and secure explicit approval before drafting final specs. This prevents premature coding by enforcing structured discovery and risk analysis.

You need to write formal requirements before coding when non-trivial product or engineering work lacks fully defined scope, goals, success criteria, risk surfaces, or design direction. High-risk changes involving auth, billing, migrations, or security strictly require this upfront specification.

The best way to define project scope for a complex product change is through a one-question-at-a-time clarification process that only asks questions materially impacting implementation. This is followed by framing 2-3 viable approaches with explicit tradeoffs to select the simplest workable option.

An approval workflow improves product planning by requiring explicit direction approval before drafting specs and optional file-level approval for saved specs. It enforces placeholder and contradiction checks, ensuring engineering teams implement safely defined, high-risk changes without scope creep.

Yes, you can use structured discovery for multi-session risk analysis and repeat feature work. It applies stricter reviews and verifies prior behavior to ensure high-risk changes involving migrations or security are explicitly defined and approved before implementation.

Skipping requirements discovery for ambiguous requests risks premature coding without defined success criteria or design direction. It bypasses necessary risk analysis and tradeoff evaluation for high-risk changes, leading to unsafe implementation and unmanaged scope.