Collect the controlling statements: the user's request and corrections, linked issues, existing public contracts. Current behavior is evidence of constraints, not of intent.
Build the glossary (identity and lifetime of each noun) and fix units and domains (behavior models).
Model behavior: a state transition table for anything with a lifecycle, a decision table for rules with three or more conditions, the linearization point for races, retry semantics, abuse cases at trust boundaries.
Write one requirement per response in the EARS form that matches its trigger (requirement forms), with an ID and [source: ...].
Write acceptance criteria as Given/When/Then observations at the contract boundary, including boundaries, failures, and races (acceptance).
Record open decisions (DEC-...) with options and consequences for everything the sources do not settle.
Run python3 scripts/check_requirements.py SPEC.md until it reports defects=0, then deliver in the repository's issue or spec format.
If code exists or is being written, map each criterion to a test and run a discrimination check (break the behavior, see the test fail).

Route the situation to a card

Situation	Card
Requirement has no trigger	Ubiquitous
Behavior responds to an event	Event-driven
Behavior depends on a mode or state	State-driven
Errors, failures, misuse	Unwanted behavior, abuse cases
Behavior only in some configurations	Optional feature
State and event together	Complex
Requirement bundles several responses	One response
Spec uses MUST/SHOULD	Normative keywords
"Fast", "scalable", "reliable"	Measurable quality, vague terms
Where did this requirement come from?	Sources
Unknown policy, limit, or durability	Open decisions
Nouns with several meanings	Glossary, units
Entity with a lifecycle	State table
Many interacting conditions	Decision table
Concurrent operations	Linearization point, interleavings
Retries, duplicate requests	Retry semantics
Writing acceptance criteria	Given/When/Then, boundaries, observations
Turning criteria into tests	Mapping, discrimination

Rules

One shall, one response, one ID, one source per requirement.
No invented numbers, limits, or policies; unknowns go to DEC- items.
No implementation in requirements (classes, tables, libraries) unless the request constrains it.
Every requirement has at least one acceptance criterion; every criterion references existing requirements and is observable at the contract boundary.
Specify races by their linearization point and test them with a barrier; sleeps make the test flaky.
Say whether each statement describes desired or current behavior.

Bundled tools

scripts/check_requirements.py SPEC.md [--json]: counts requirements, EARS patterns, and defects (missing source, non-EARS, several shall, vague terms, TBD, unverified requirements, bad criteria); exit 0 clean, 1 defects, 2 unreadable.
assets/examples/: the worked export-cancellation spec (0 defects), its vague first draft, a reference implementation, one acceptance test per criterion, and verify.sh, which also breaks the implementation to prove the tests discriminate.

References

Requirement forms: line format, the six EARS patterns, one response, normative keywords, measurable quality, vague terms, sources, open decisions.
Behavior models: glossary, units, state and decision tables, linearization points, retries, abuse cases.
Acceptance criteria: Given/When/Then, test mapping, interleavings, boundaries, observations, discrimination.

Completion evidence

The deliverable contains the glossary, models used, requirements, acceptance criteria, and open decisions; the checker output with defects=0; and, when code exists, the test run showing each criterion's test and the discrimination check result.

define-requirements

Define Requirements

Workflow