Assesses requirements quality against INVEST criteria, improves clarity, detects ambiguity, ensures completeness, and guides MoSCoW prioritization with checklists and refinement patterns.
npx claudepluginhub melodic-software/claude-code-plugins --plugin spec-driven-developmentThis skill is limited to using the following tools:
Requirements quality assessment, INVEST criteria validation, and refinement patterns.
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.
Applies requirement quality principles to generate or validate feature specifications, enforcing completeness, scenario structure, AC verifiability, feature independence, and implementation slice quality.
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.
Share bugs, ideas, or general feedback.
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