Create Spec

Capture a settled design as an unambiguous engineering spec ready to hand to an implementer. The implementer should be able to read the spec alone and understand what the expected solution looks like, what's pinned down, and what degrees of freedom they have.

This skill is the output of the design phase, not part of it. If significant design questions remain, resolve them in a design discussion (using the appropriate skill) before invoking this one. Refinement here is for tightening ambiguity in the recorded design, not for re-opening it.

Specs are short-lived

A spec lives for the lifetime of the project and is deleted at close-out. It is not an ADR or architecture doc.

That means it's appropriate (and often necessary) for a spec to talk about:

• The current state of the system at the time of writing
• Transition states the system will pass through during the project
• Migration steps, feature flags, deprecation timelines, and other temporary details
• Code paths or systems that exist today but won't after the project lands

If you find yourself writing something that should outlive the project (a durable architectural decision, a long-lived convention, a system invariant), don't worry about extracting it inline — the project close-out phase (drive-close-project) walks the project artifacts (specs and plans) and lifts any long-lived design decisions into ADRs or subsystem docs before deleting projects/{project}/. Capture the decision in the spec where it naturally lives; close-out will move it to its durable home.