karvey-requirementslisted

# Karvey Requirements ## Purpose Generate requirements in EARS format for the change, produce the spec-delta with ADDED/MODIFIED/REMOVED operations, and register the Features in ClickUp or PLAN.md. ## Execution steps ### Step 1 — Load context Read: - `docs/spec/changes/{change-id}/spec.json` - `docs/spec/changes/{change-id}/prd.md` (PRD generated in karvey-init) - `docs/spec/changes/{change-id}/proposal.md` - `docs/spec/specs/{capability}/spec.md` (current living spec) - `rules/ears-format.md` - `rules/living-specs.md` - `rules/security-tiers.md` The requirements must derive from the PRD and cover its objectives and acceptance criteria. If there's a `karvey-grill` brief in the conversation, incorporate it. If the codebase is brownfield: dispatch a subagent to explore existing implementations: > "Explore the codebase looking for functionality related to {capability}. Summarize: (1) what exists, (2) relevant interfaces/endpoints, (3) patterns the new requirements must respect. Less than 100 lines." ### Step 2 — Clarify scope before generating For each functional area identified in `proposal.md`, ask whether there's any scope ambiguity or edge-case behavior. Ask only the necessary questions — don't ask about what's already clear. **Don't ask about**: technology, architecture, implementation patterns (that goes in karvey-architecture). ### Step 3 — Generate a draft of requirements.md Generate it grouping requirements by functional area. Apply strict EARS format. Keep