authoring-prdlisted

# Authoring a PRD The Yoke loop is only as good as its stories. Keep the backlog continuous: new requests become new stories; they do not require a release object. ## Story rules 1. One iteration per story. Prefer 5–12 small stories over a few epics. 2. Each story leaves the project buildable and testable. 3. Acceptance describes observable behavior, never implementation. Give each of 2–5 criteria a stable `id`, behavioral `text`, and `verify` list with one or more real commands proving that exact outcome. 4. Use dense priorities from 1; order by dependency, then risk. 5. Greenfield `STORY-1` creates the skeleton, runnable suite, and `verify.command`. 6. Express performance with numbers and executable benchmarks, not words such as “fast”. 7. Resolve planning questions before unattended execution. `yoke prd check` rejects unresolved placeholders; critical irreversible choices use the structured decision channel. 8. Use `needs` only for hard prerequisites, `area` for collision domains, and `agent` only as a Claude/Codex/Gemini affinity hint. 9. Keep planning on the start model. Add an `assessment` to each story: `taskClass` (`mechanical`, `implementation`, `debugging`, `architecture`), `difficulty`, `uncertainty`, `risk`, `scope`, `testability` (each `low`, `medium`, `high`), a concise `reason`, and an actionable `approach` including checks. High testability means executable checks reliably detect mistakes. Small security-sensitive changes can still b