Specify

Turn the selected capability into agreed behavior and acceptance. Interview only where decisions remain unresolved; synthesize directly when current context is settled.

Stay on the observable side: what users and other systems can see and rely on, including an external contract such as a public API or an event others consume. How the code delivers it (modules, internal interfaces, the data model, technology) is out of scope; record a technical idea the user raises under a "Technical notes" heading in the capability's draft, not as agreed behavior.

The documents and their rules are in project-documents.md; its terms (authorized, obligation, lazy, pointer) apply throughout, with full changelog records.

Gather and reconcile

Find the project's documents through AGENTS.md, as project-documents.md describes. Inspect the conversation, applicable instructions, the domain outline, system-wide and capability requirements, existing specifications, backlog, working state, glossary, and relevant code. Fetch the full body and comments of referenced remote records when they are relevant inputs.

Identify the selected capability and account for every applicable requirement. Reuse existing agreements. A missing blocking decision stays explicit and open until the user settles it.

Resolve the frontier

Settle only the unresolved decisions needed to complete the selected scope, through the interview method.

When a term is fuzzy, disputed, or clashes with the glossary or the code, raise it before carrying on: name the conflict, test it with a concrete scenario, recommend a canonical term, and once the user agrees, write it to the glossary following glossary-format.md. Reading the existing vocabulary needs none of this.