majiayu000 vibe-requirements-validator
Vague requirements cause expensive rework. Catch them early.
When to Use This Skill
- Reviewing a PRD or feature spec before implementation
- Writing acceptance criteria for user stories
- When you notice requirements like "make it fast" or "improve UX"
- Before estimating effort for a feature
When NOT to Use This Skill
- Internal technical tasks with clear scope
- Bug fixes (the bug IS the requirement)
- When requirements are already validated and approved
SMART Criteria
Score each requirement 1-5 on:
- Specific — Is it clear what exactly needs to be built? (Not "improve performance" but "reduce P95 latency to <200ms")
- Measurable — Can you objectively verify it's done? (Not "users like it" but "NPS score >40")
- Achievable — Can it be built with available resources and constraints?
- Relevant — Does it align with project goals and user needs?
- Time-bound — Is there a clear scope boundary? (Not "eventually" but "in v1.0")
Steps
List all requirements from the document
Score each on SMART (1-5 per dimension)
Flag issues:
- Score < 3 on any dimension → needs revision
- Measurability < 3 → most common failure, flag prominently
- Near-duplicates → consolidate
- Positioning statements masquerading as requirements → remove
Report:
Output Format
Requirements Validation: [Document Name]
Total Requirements: X Passing (avg >= 3.5): Y (Z%) Flagged: W
| ID | Requirement | S | M | A | R | T | Avg | Issue |
|---|---|---|---|---|---|---|---|---|
| FR-1 | "..." | 4 | 2 | 5 | 4 | 3 | 3.6 | Low measurability |
Top Issues
- Measurability crisis — X requirements have M < 3
- Near-duplicates — [list pairs]
- Not requirements — [positioning statements]
Recommended Revisions
| ID | Current | Suggested |
|---|---|---|
| FR-3 | "Improve load time" | "Reduce initial page load to <2s on 3G" |