Requirements quality assessment and improvement. Use when evaluating requirements against INVEST criteria, improving clarity, detecting ambiguity, or ensuring completeness. Provides quality checklists, refinement patterns, and MoSCoW prioritization guidance.
Assesses requirements against INVEST criteria to improve clarity, detect ambiguity, and ensure completeness. Use when refining requirements, validating acceptance criteria, or applying MoSCoW prioritization.
/plugin marketplace add melodic-software/claude-code-plugins/plugin install spec-driven-development@melodic-softwareThis skill is limited to using the following tools:
references/completeness-checklist.mdreferences/invest-criteria.mdreferences/refinement-patterns.mdRequirements 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
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.