Stats
Actions
Tags
Assesses requirements quality against INVEST criteria, improves clarity, detects ambiguity, ensures completeness, and guides MoSCoW prioritization with checklists and refinement patterns.
How this skill is triggered — by the user, by Claude, or both
Slash command
/spec-driven-development:requirements-qualityThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Requirements quality assessment, INVEST criteria validation, and refinement patterns.
Requirements quality assessment, INVEST criteria validation, and refinement patterns.
Keywords: INVEST, requirements quality, clarity, ambiguity, completeness, testable, estimable, refinement, MoSCoW, prioritization, acceptance criteria, requirement validation, quality assessment
Use this skill when:
The INVEST acronym defines six quality criteria for well-formed requirements:
| Criterion | Question | Red Flag |
|---|---|---|
| Independent | Can this be implemented alone? | "Requires X to be done first" |
| Negotiable | Is there room for discussion? | Over-specified implementation |
| Valuable | Does it deliver user value? | Technical-only benefit |
| Estimable | Can effort be estimated? | Vague or unbounded scope |
| Small | Can it be done in one iteration? | Multi-sprint scope |
| Testable | Can we verify it's done? | Missing acceptance criteria |
For each requirement, score 0-2 on each criterion:
| Score | Meaning |
|---|---|
| 0 | Does not meet criterion |
| 1 | Partially meets criterion |
| 2 | Fully meets criterion |
Interpretation:
| Issue | Symptom | Fix |
|---|---|---|
| Too vague | "Make it user-friendly" | Add measurable criteria |
| Too large | Multi-week estimate | Split into smaller requirements |
| Untestable | No clear success condition | Add acceptance criteria |
| Dependent | "After X is complete" | Decouple or combine |
| Technical | "Refactor database" | Reframe as user value |
| Over-specified | Implementation details | Focus on what, not how |
| Priority | Meaning | Guidance |
|---|---|---|
| Must | Critical for release | Without this, release fails |
| Should | Important but not critical | High value, schedule permitting |
| Could | Nice to have | Include if time allows |
| Won't | Out of scope (this time) | Explicitly deferred |
Ambiguous Words to Avoid:
| Word | Problem | Better Alternative |
|---|---|---|
| "should" | Unclear obligation | "SHALL" (mandatory) or "MAY" (optional) |
| "quickly" | Subjective timing | "within 200ms" |
| "user-friendly" | Subjective quality | Specific usability criteria |
| "etc." | Incomplete list | Exhaustive enumeration |
| "appropriate" | Vague standard | Specific criteria |
| "some" | Undefined quantity | Explicit count or range |
| "easy" | Subjective difficulty | Measurable steps |
Each acceptance criterion should be:
Given [precondition]
When [action]
Then [expected outcome]
Quality Check:
1. Draft Requirement
↓
2. INVEST Assessment (score each criterion)
↓
3. Identify Issues (low-scoring criteria)
↓
4. Apply Fixes (use patterns below)
↓
5. Re-assess (verify improvements)
↓
6. Add Acceptance Criteria
↓
7. Final Validation
When Independent fails:
When Negotiable fails:
When Valuable fails:
When Estimable fails:
When Small fails:
When Testable fails:
A complete requirement includes:
| Element | Description | Required? |
|---|---|---|
| ID | Unique identifier | Yes |
| Title | Brief descriptive title | Yes |
| Description | Full requirement text | Yes |
| Priority | MoSCoW level | Yes |
| Acceptance Criteria | Testable conditions | Yes |
| Dependencies | Related requirements | If any |
| Assumptions | Underlying assumptions | If any |
| Constraints | Limitations | If any |
A complete specification includes:
| Action | Command |
|---|---|
| Assess requirement quality | /spec:validate <path> |
| Refine requirements | /spec:refine <path> |
| Audit specification | /spec:audit <path> |
ears-authoring - EARS pattern authoringgherkin-authoring - Given/When/Then criteriacanonical-spec-format - Canonical specification structurespec-management - Specification workflow hubDetailed Documentation:
Last Updated: 2025-12-24
npx claudepluginhub melodic-software/claude-code-plugins --plugin spec-driven-developmentAuthors, 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.
Enforces requirement quality principles when writing or validating feature specifications — complete scenarios, verifiable ACs, proper scope, and failure coverage.
Guides requirements engineering with INVEST user stories, Given-When-Then acceptance criteria including edge cases, MoSCoW prioritization, vertical slices, story mapping, decomposition patterns, non-functional requirements, and Definition of Done. Use for writing stories, epic breakdowns, and backlog prioritization.