review-requirements

What this skill does

# Review Requirements

**Input:** `$ARGUMENTS`

Parse input to extract the requirements file path.

## Phase 1: Structural Validation

Spawn a Task agent to check requirements quality:

Task tool parameters:
  subagent_type: general-purpose
  model: sonnet
  description: Structural requirements validation
  prompt: |
    Validate the requirements at: $ARGUMENTS

    ## Process

    1. Read the requirements file
    2. Read CLAUDE.md, .claude/rules/*.md for project context
    3. Validate against criteria below

    **Threshold: Only flag issues that would block design or cause genuine confusion.**

    ### Criteria
    - **EARS Compliance**: Every acceptance criterion uses an EARS pattern (WHEN/SHALL, WHILE/SHALL, IF/THEN SHALL, WHERE/SHALL). Flag criteria that don't follow the pattern.
    - **Glossary Consistency**: Terms defined in the glossary are used consistently. Terms used in criteria are defined in the glossary.
    - **Non-Technical**: Requirements describe observable behavior, not implementation. Flag technical prescriptions (specific technologies, schemas, code patterns).
    - **Completeness**: Has introduction, glossary (3-10 terms), and 3-7 user stories. Each user story has acceptance criteria.
    - **Testability**: Each acceptance criterion is verifiable—an observer could determine pass/fail. Flag vague criteria ("system should be fast", "user-friendly").
    - **Error Coverage**: Requirements address key failure scenarios, especially at system boundaries.

    ## Output

    If no issues: `PASS`

    If issues exist, list each with category and explanation. Keep it terse.

If structural validation fails, report issues and stop.

## Phase 2: Consistency Review

Spawn a Task agent to check internal consistency:

Task tool parameters:
  subagent_type: general-purpose
  model: sonnet
  description: Requirements consistency review
  prompt: |
    Check the requirements at: $ARGUMENTS for internal consistency.

    ## Process

    1. Read the requirements file
    2. Check for:
       - Contradictions between acceptance criteria (one says X, another implies not-X)
       - Overlapping requirements that could conflict during implementation
       - Missing dependencies (requirement A assumes something that no other requirement establishes)
       - Scope gaps (scenarios a user would expect that no requirement covers)

    ## Critical Rules

    - If requirements are consistent and complete, report PASS. Finding nothing is valid.
    - Do NOT fabricate concerns. Only flag issues where you can explain what would go wrong.
    - Do NOT flag: subjective preferences, alternative phrasings, speculative future requirements.
    - Threshold: Would a designer or implementer be confused, build the wrong thing, or miss a scenario?

    ## Output

    If no issues: `PASS — requirements are internally consistent.`

    If issues exist:
    - **{issue}** — {what's inconsistent or missing} → {what could go wrong}

## Phase 3: Aggregate

Collect results from all phases. Drop PASS results.

If all phases pass: report `PASS` to the user.

If issues found:
- Deduplicate
- Group by severity
- Present each issue with: which phase found it, the gap, and the risk
- Keep the report concise