From rpi
Validates requirements documents for EARS compliance, glossary consistency, completeness, and testability. Flags contradictions and scope gaps before design work begins.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rpi:review-requirementsThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Input:** `$ARGUMENTS`
Input: $ARGUMENTS
Parse input to extract the requirements file path.
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.
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}
Collect results from all phases. Drop PASS results.
If all phases pass: report PASS to the user.
If issues found:
npx claudepluginhub crouton-labs/crouton-kit --plugin rpiCritiques requirements documents using dimensions for confirmation bias detection, completeness validation, clarity checks, testability assessment, and priority validation in peer reviews.
Audits single sphinx-needs requirement against ISO 26262-8 §6's 11 axes. Emits JSON with per-axis pass/fail or 0-3 scores, reasons, action items for failures, and overall verdict.
Authors, updates, and validates atomic functional and non-functional requirements with traceability matrices, validation packs, and explicit human-in-the-loop approvals. Use for creating or reviewing requirements as source of truth.