From rpi
Validates requirements documents for EARS compliance, glossary consistency, completeness, testability, non-technical phrasing, and internal consistency including contradictions and gaps. Use after creating requirements.
npx claudepluginhub crouton-labs/crouton-kit --plugin rpiThis skill is limited to using the following tools:
**Input:** `$ARGUMENTS`
Implements Playwright E2E testing patterns: Page Object Model, test organization, configuration, reporters, artifacts, and CI/CD integration for stable suites.
Guides Next.js 16+ Turbopack for faster dev via incremental bundling, FS caching, and HMR; covers webpack comparison, bundle analysis, and production builds.
Discovers and evaluates Laravel packages via LaraPlugins.io MCP. Searches by keyword/feature, filters by health score, Laravel/PHP compatibility; fetches details, metrics, and version history.
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: