Requirement Assistant
This skill provides guidance on writing clear, complete, and actionable requirements.
Quick Reference
User Story Format (INVEST)
code
As a [role], I want [feature], So that [benefit].
INVEST Criteria
| Criterion | Description | Question to Ask |
|---|---|---|
| Independent | Can be delivered alone | Does this depend on other stories? |
| Negotiable | Details can be discussed | Is this too prescriptive? |
| Valuable | Provides user value | What problem does this solve? |
| Estimable | Can estimate effort | Do we understand the scope? |
| Small | Fits in one sprint | Can we break this down? |
| Testable | Has clear acceptance criteria | How do we know it's done? |
Requirement Priority Levels
| Priority | Label | Description |
|---|---|---|
| P0 | Must Have | Critical for release |
| P1 | Should Have | Important but not blocking |
| P2 | Could Have | Nice to have |
| P3 | Won't Have | Out of scope (this release) |
Detailed Guidelines
For complete standards, see:
Quick Templates
Simple Issue Template
markdown
## Problem [What problem are we solving?] ## Proposed Solution [How should we solve it?] ## Acceptance Criteria - [ ] [Criterion 1] - [ ] [Criterion 2] - [ ] [Criterion 3]
Feature Request Template
markdown
## Summary [One-line description] ## Motivation [Why is this needed? Who benefits?] ## Detailed Description [Full description of the feature] ## Acceptance Criteria - [ ] [Measurable criterion 1] - [ ] [Measurable criterion 2] ## Out of Scope - [What this feature does NOT include]
Bug Report Template
markdown
## Description [Brief description of the bug] ## Steps to Reproduce 1. [Step 1] 2. [Step 2] 3. [Step 3] ## Expected Behavior [What should happen] ## Actual Behavior [What actually happens] ## Environment - OS: [e.g., Windows 11] - Version: [e.g., v1.2.3]
Acceptance Criteria Guidelines
Good Acceptance Criteria
- •Specific: Clear, unambiguous
- •Measurable: Can verify pass/fail
- •Achievable: Technically feasible
- •Relevant: Related to the requirement
- •Testable: Can write a test for it
Examples
Good:
markdown
- [ ] User can upload files up to 10MB - [ ] System responds within 500ms for 95th percentile - [ ] Error message displays when upload fails
Bad:
markdown
- [ ] System should be fast # Not measurable - [ ] Make it user-friendly # Too vague - [ ] Fix the bug # No specific criteria
Requirement Completeness Checklist
When writing requirements, ensure you cover:
- • What: Clear description of the feature
- • Why: Business value / problem solved
- • Who: Target users / personas
- • When: Priority / timeline
- • How: High-level approach (if known)
- • Acceptance: Criteria for completion
- • Scope: What's NOT included
Configuration Detection
This skill supports project-specific requirement templates.
Detection Order
- •Check
CONTRIBUTING.mdfor "Disabled Skills" section- •If this skill is listed, it is disabled for this project
- •Check
CONTRIBUTING.mdfor "Requirement Language" section - •Check for
.github/ISSUE_TEMPLATE/directory - •Check for
docs/templates/directory - •If not found, default to English and use default templates
First-Time Setup
If no templates found:
- •Ask the user: "This project doesn't have requirement templates. Which language should I use? (English / 中文)"
- •After user selection, suggest documenting in
CONTRIBUTING.md:
markdown
## Requirement Language This project uses **[chosen option]** for requirements and issues. <!-- Options: English | 中文 -->
- •Suggest appropriate template based on project type
Configuration Example
In project's CONTRIBUTING.md:
markdown
## Requirement Language This project uses **English** for requirements and issues. <!-- Options: English | 中文 --> ### Issue Templates Location `.github/ISSUE_TEMPLATE/`
License: CC BY 4.0 | Source: universal-dev-standards