Stats
Actions
Tags
Help us improve
Share bugs, ideas, or general feedback.
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`
Share bugs, ideas, or general feedback.
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.