specification-writinglisted

## Purpose Produce a **Zero-Question Specification** — a spec so complete that any competent executor (AI agent, engineer, contractor, cross-functional team) can begin work immediately without asking a single clarifying question. A Zero-Question Spec is not the same as a long spec. Length is a symptom, not a goal. The goal is that every assumption is surfaced, every ambiguity is resolved or explicitly marked TBD with an owner and deadline, every acceptance criterion is binary-testable, and every scope boundary names the adjacent capability it excludes. This codex encodes six interlocking frameworks that systematize the transition from "rough feature intent" to "executable specification." Each framework targets a specific class of spec failure. Together, they eliminate the five most common causes of execution failure: unclear outcomes, untestable criteria, invisible scope creep, missing executor context, and silent assumptions. --- ## When to Use / When NOT to Use ### When to Use - Writing a **product or feature spec** for a new user-facing capability - Writing an **API contract spec** that multiple teams or services will implement against - Writing an **agent task spec** for an AI agent that will execute autonomously - Writing a **process or workflow spec** that crosses team boundaries - Writing an **infrastructure or migration spec** where failure conditions are critical - Writing a **research or discovery spec** where "done" is ambiguous without explicit criteria - U