Agent skill
requirement-patterns
This skill should be used when writing requirements, specifications, or user stories. Triggers on phrases like "write requirements", "create spec", "define user stories", "document feature", "specify behavior", "what should the system do", or when reviewing specification quality. Provides patterns for clear, testable, unambiguous requirements.
Install this agent skill to your Project
npx add-skill https://github.com/ddunnock/claude-plugins/tree/main/skills/speckit-generator/skills/requirement-patterns
SKILL.md
Requirement Writing Patterns
Write requirements that are clear, testable, and unambiguous. Good requirements prevent implementation confusion and reduce clarification cycles.
Quick Reference
The INVEST Criteria for User Stories
| Letter | Criterion | Test |
|---|---|---|
| I | Independent | Can be implemented without other stories |
| N | Negotiable | Details can be discussed, not locked |
| V | Valuable | Delivers user/business value |
| E | Estimable | Team can estimate effort |
| S | Small | Fits in one sprint/iteration |
| T | Testable | Has clear acceptance criteria |
Requirement Levels
| Level | Format | Use When |
|---|---|---|
| Epic | High-level capability | Planning roadmaps |
| Feature | User-facing functionality | Release planning |
| User Story | As a [role], I want [goal], so that [benefit] | Sprint planning |
| Acceptance Criterion | Given/When/Then | Implementation guidance |
Writing Testable Requirements
The "Shall" Pattern
For formal requirements, use "shall" for mandatory and "should" for recommended:
REQ-001: The system shall authenticate users via OAuth 2.0.
REQ-002: The system shall reject requests without valid tokens with HTTP 401.
REQ-003: The system should cache tokens for up to 1 hour.
The User Story Pattern
For agile contexts, use the standard format:
As a [specific role],
I want [concrete action],
So that [measurable benefit].
Good example:
As a registered user,
I want to reset my password via email link,
So that I can regain access within 5 minutes without contacting support.
Bad example:
As a user,
I want better security,
So that things work properly.
Acceptance Criteria (Given/When/Then)
Every requirement needs testable acceptance criteria:
**Given** a registered user with a valid email
**When** they request a password reset
**Then** they receive an email within 30 seconds
**And** the link expires after 24 hours
**And** clicking the link allows setting a new password
Ambiguity Markers to Avoid
These words indicate vague requirements that need refinement:
| Marker | Problem | Fix |
|---|---|---|
| "properly" | Undefined correctness | Specify exact behavior |
| "quickly" | No metric | Add time constraint (e.g., "<200ms") |
| "user-friendly" | Subjective | Define specific UX criteria |
| "secure" | Vague | List specific security controls |
| "etc." | Incomplete list | Enumerate all items or state "including but not limited to" |
| "appropriate" | Undefined standard | Specify the standard |
| "as needed" | Undefined trigger | Define when/what triggers |
| "may/might" | Uncertain scope | Decide: is it in scope or not? |
Requirement Identifiers
Use consistent ID schemes for traceability:
REQ-001 # Simple sequential
FR-001 # Functional requirement
NFR-001 # Non-functional requirement
SEC-001 # Security requirement
PERF-001 # Performance requirement
Constraints vs Requirements
Requirements = What the system must DO Constraints = Limits on HOW it's built
## Requirements
- REQ-001: System shall support 1000 concurrent users
## Constraints
- CON-001: Must use PostgreSQL 14+
- CON-002: Must deploy to AWS
- CON-003: Budget limit $500/month infrastructure
Common Anti-Patterns
| Anti-Pattern | Example | Fix |
|---|---|---|
| Solution masquerading as requirement | "Use Redis for caching" | "Response time < 100ms for cached data" |
| Compound requirement | "System shall authenticate and authorize" | Split into REQ-001 (auth) and REQ-002 (authz) |
| Unmeasurable quality | "System shall be fast" | "95th percentile latency < 200ms" |
| Missing actor | "Data shall be validated" | "System shall validate user input before storage" |
| Assumed knowledge | "Standard security practices" | List specific practices or reference standard |
Integration with SpecKit
When writing specs for /speckit.plan:
- Use REQ-XXX identifiers - Enables traceability to tasks
- Include acceptance criteria - Becomes task verification
- Mark unknowns as [TBD] -
/speckit.clarifywill find them - Group by domain - Enables domain-specific plans
Additional Resources
For detailed patterns and examples, see:
references/anti-patterns.md- Common mistakes with fixesreferences/examples.md- Complete requirement examples by domain
Verification Checklist
Before finalizing requirements:
- Every requirement has a unique identifier
- No vague adjectives (properly, quickly, appropriately)
- Each requirement is testable with clear criteria
- Requirements are independent (no hidden dependencies)
- Constraints are separated from requirements
- Unknowns are marked [TBD] for clarification
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
ddunnock/claude-plugins
streaming-output
Stream long-form content to markdown files with resume capability. Writes content incrementally with section markers, enabling recovery if context limits are hit. Use when generating long documents (over 1000 lines), B-SPEC or specification writing, multi-section reports, any task where context compaction may occur mid-generation, or when user explicitly requests streaming output. Commands: init, write, status, resume, finalize, repair.
ddunnock/claude-plugins
fishbone-diagram
Create comprehensive Fishbone (Ishikawa/Cause-and-Effect) diagrams for structured root cause brainstorming. Guides teams through problem definition, category selection (6Ms, 8Ps, 4Ss, or custom), cause identification, sub-cause drilling, prioritization via multi-voting, and 5 Whys integration. Generates visual SVG diagrams and professional HTML reports. Use when brainstorming potential causes, conducting root cause analysis, facilitating quality improvement sessions, analyzing defects or failures, structuring team problem-solving, or when user mentions "fishbone", "Ishikawa", "cause and effect diagram", "6Ms", "cause analysis", or "brainstorming causes".
ddunnock/claude-plugins
streaming-output-mcp
Stream structured content to persistent SQLite storage with automatic session break recovery. Core principle: The content IS the state. Every stream_write is automatically persistent. Supports multi-format export (Markdown, HTML, JSON, YAML, CSV, Text) and 7 document templates. Commands: /stream-init, /stream-status, /stream-read, /stream-write, /stream-export. ALWAYS call stream_status after session breaks to check for resume_from and preserved_context.
ddunnock/claude-plugins
fmea-analysis
Conduct Failure Mode and Effects Analysis (FMEA) for systematic identification and risk assessment of potential failures in designs, processes, or systems. Supports DFMEA (Design), PFMEA (Process), and FMEA-MSR (Monitoring & System Response). Uses AIAG-VDA 7-step methodology with Action Priority (AP) risk assessment replacing traditional RPN. Use when analyzing product designs for potential failures, evaluating manufacturing process risks, conducting proactive risk assessment, preparing for APQP/PPAP submissions, investigating field failures, or when user mentions "FMEA", "failure mode", "DFMEA", "PFMEA", "severity occurrence detection", "RPN", "Action Priority", "design risk analysis", or needs to identify and prioritize potential failure modes with their causes and effects.
ddunnock/claude-plugins
problem-definition
Guide RCCA/8D problem definition using 5W2H and IS/IS NOT analysis. Transforms scattered failure data into precise, measurable problem statements that bound investigation scope without embedding cause or solution. Use when defining problems for root cause analysis, writing D2 sections of 8D reports, analyzing nonconformances, investigating failures, or when user mentions problem definition, problem statement, RCCA, 8D, failure analysis, or corrective action.
ddunnock/claude-plugins
kepner-tregoe-analysis
Conduct Kepner-Tregoe (KT) Problem Solving and Decision Making (PSDM) analysis using the four rational processes - Situation Appraisal, Problem Analysis, Decision Analysis, and Potential Problem Analysis. Use when performing structured root cause analysis, making complex decisions, evaluating alternatives with weighted criteria, conducting IS/IS NOT specification analysis, anticipating implementation risks, troubleshooting complex issues, or when user mentions "Kepner-Tregoe", "KT method", "IS/IS NOT", "situation appraisal", "decision analysis", "MUSTS and WANTS", "potential problem analysis", or needs systematic problem-solving methodology. Includes specification matrices, decision scoring, quality rubrics, and professional report generation.
Didn't find tool you were looking for?