Spec

Forward-design a handoff-grade spec from a thread's durable inputs, end-to-end. You read the thread's context, draft a spec body that covers all seven required semantic-contract elements plus the two spec obligations, write the single thread-root spec.md, and confirm its path. You work straight from the durable inputs without interviewing the user element by element. Writing the file is where you stop — do not stage, commit, or push.

A handoff-grade spec is one a downstream reader with no prior context can read alone and know what to build: what the outcome is, what is in and out of scope, how it must behave, what binds it, what is deliberately left free, and how a reviewer will know it is right.

Inputs

The spec is forward-designed from the thread's durable inputs plus whatever the invocation points you at:

• seed.md — why the thread exists and what triggered it; the source of the spec's context.
• decisions.md — the settled DR<N> decisions the spec must encode and must not contradict.
• proposal.md (when present) — the direction-setting sketch the spec elaborates into expected behavior, constraints, and acceptance guidance.
• A referenced artifact or the user's prompt — an explicit path, a GitHub issue, or the prompt itself when nothing else is referenced. Treat an issue's title and labels as additional context.

If which input is meant is ambiguous — a reference names "the proposal" or "the spec" with no clear referent, or several artifacts could be intended — that is a preflight failure, not an in-run decision: refuse before drafting, name the ambiguous reference and how to disambiguate it, write nothing, and end with Outcome: REFUSED — <the ambiguity and how to re-invoke>. Never silently pick by recency.

Semantic contract