القائمة
Validate requirements documents for EARS compliance, completeness, and consistency. Use after creating requirements.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Structure Claude prompts for clarity and better results using roles, explicit instructions, context, positive framing, and strategic organization. Use when crafting prompts for complex tasks, long documents, tool workflows, or code generation.
Pause agent execution to have the human validate decisions, choose between options, answer freetext, or comment on a document — via the `hl` CLI. Every interaction is a kickoff that returns a job handle immediately; collect the human's answer later with `hl job result`. Use for material design decisions, approval gates, picks between meaningful alternatives, and markdown doc review. Not for trivial yes/no confirmations the agent should decide itself.
Validate technical designs against requirements for coverage, feasibility, and architectural soundness. Use after creating a design.
Validate implementation plans against requirements and design. Use after creating a plan to ensure full coverage and no ambiguities.
Design CLIs for humans and LLM agents — subcommand shape, output streams, exit codes, JSON modes, TTY-aware color, structured errors, mutation safety. Use when building or refactoring a CLI, adding machine-readable output, writing --help, deciding stdout vs stderr, or making a tool agent-friendly.
Systematic debugging methodologies for hard bugs. Covers rubber ducking, code tracing, hypothesis testing, logging strategies. Use when stuck on bugs that resist quick fixes.
| name | review-requirements |
| description | Validate requirements documents for EARS compliance, completeness, and consistency. Use after creating requirements. |
| user-invocable | false |
| allowed-tools | Task, Read, Grep, Glob |
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: