requirementslisted

# Blueprint: requirements Read `${CLAUDE_PLUGIN_ROOT}/FORMAT.md` first (or `FORMAT.md` at the repo root if you are working inside the blueprint repo itself). It defines the ID grammar and the exact document shape. Do not improvise a variant. ## Input Argument is a feature slug or a path. Resolve in this order: 1. Explicit path given (`/blueprint:requirements docs/oauth-plan.md`) → use it. 2. Slug given (`/blueprint:requirements token-refresh`) → read `.blueprint/token-refresh/plan.md`. 3. Nothing given → if exactly one `.blueprint/*/plan.md` exists, use it. Otherwise ask which. 4. No plan at all → the conversation *is* the plan. Say so, and write `plan.md` from what the user has told you before continuing. ## What you do 1. **Read the plan and the codebase it lands in.** Grep for the systems it touches. A requirement written without knowing what already exists is how you get R-ids for things that shipped last year. 2. **Extract intent, not implementation.** The plan will contain solution language ("add a Redis cache"). Requirements record the need behind it ("repeat lookups SHALL complete in under 50ms"). If a constraint is genuinely fixed by the user (must use their existing Postgres), record it under Scope as a stated constraint, not as an AC. 3. **Write one `### R<n>` per user-visible capability.** If two requirements always change together and no one would ever want one without the other, they are one requirement. 4. **Write ACs i