
Requirements Clarity
- 712 installs
- 2.2k repo stars
- Updated March 5, 2026
- softaworks/agent-toolkit
requirements-clarity is a Claude Code skill that turns vague feature requests into scoped PRDs through structured dialogue for developers who need clarity before writing code on complex or cross-team features.
About
requirements-clarity is an Agent Skill from softaworks/agent-toolkit that detects ambiguous requirements such as "add login" or "implement payment" and transforms them into actionable PRDs through systematic clarification. The skill applies two core questions—Why for YAGNI and Simpler for KISS—and scores requirement quality on a 100-point system before any implementation starts. Developers reach for requirements-clarity when features are complex enough to exceed two days of work or involve cross-team coordination. The workflow surfaces missing how, scope, and acceptance criteria that otherwise cause rework after coding begins.
- Detects vague feature requests, missing technical context, incomplete specifications and ambiguous scope
- Applies systematic questioning using two core questions - Why? (YAGNI check) and Simpler? (KISS check)
- Transforms ambiguous requirements into actionable PRDs with a 100-point scoring system
- Prevents activation on specific file paths, code snippets, existing functions or clear bug reproductions
- Hard gate before implementation for features estimated >2 days or involving cross-team coordination
Requirements Clarity by the numbers
- 712 all-time installs (skills.sh)
- +17 installs in the week ending Jul 27, 2026 (Skillselion tracking)
- Ranked #597 of 3,301 Productivity & Planning skills by installs in the Skillselion catalog
- Security screen: MEDIUM risk (skills.sh audit)
- Data as of Jul 28, 2026 (Skillselion catalog sync)
npx skills add https://github.com/softaworks/agent-toolkit --skill requirements-clarityAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 712 |
|---|---|
| repo stars | ★ 2.2k |
| Security audit | 3 / 3 scanners passed |
| Last updated | March 5, 2026 |
| Repository | softaworks/agent-toolkit ↗ |
How do you clarify vague feature requirements?
Turn vague feature requests into clear, scoped PRDs before writing any code.
Who is it for?
Developers or tech leads receiving underspecified feature requests for multi-day work or cross-team features who want a PRD before coding.
Skip if: One-line bug fixes, already-written specs, or tasks with complete acceptance criteria and fixed scope.
When should I use this skill?
The user describes a feature vaguely—"add login", "create dashboard", "implement payment"—without how, scope, or acceptance criteria.
What you get
Scoped PRD document, 100-point requirement score, YAGNI and KISS validation notes, and clarified acceptance criteria.
- Scoped PRD
- Requirement clarity score
- YAGNI and KISS validation
By the numbers
- Uses a 100-point scoring system for requirement clarity
- Applies two core clarification questions: Why and Simpler
- Targets features estimated at more than 2 days of work
Files
Requirements Clarity Skill
Description
Automatically transforms vague requirements into actionable PRDs through systematic clarification with a 100-point scoring system.
Instructions
When invoked, detect vague requirements:
1. Vague Feature Requests
- User says: "add login feature", "implement payment", "create dashboard"
- Missing: How, with what technology, what constraints?
2. Missing Technical Context
- No technology stack mentioned
- No integration points identified
- No performance/security constraints
3. Incomplete Specifications
- No acceptance criteria
- No success metrics
- No edge cases considered
- No error handling mentioned
4. Ambiguous Scope
- Unclear boundaries ("user management" - what exactly?)
- No distinction between MVP and future enhancements
- Missing "what's NOT included"
Do NOT activate when:
- Specific file paths mentioned (e.g., "auth.go:45")
- Code snippets included
- Existing functions/classes referenced
- Bug fixes with clear reproduction steps
Core Principles
1. Systematic Questioning
- Ask focused, specific questions
- One category at a time (2-3 questions per round)
- Build on previous answers
- Avoid overwhelming users
2. Quality-Driven Iteration
- Continuously assess clarity score (0-100)
- Identify gaps systematically
- Iterate until ≥ 90 points
- Document all clarification rounds
3. Actionable Output
- Generate concrete specifications
- Include measurable acceptance criteria
- Provide executable phases
- Enable direct implementation
Clarification Process
Step 1: Initial Requirement Analysis
Input: User's requirement description
Tasks: 1. Parse and understand core requirement 2. Generate feature name (kebab-case format) 3. Determine document version (default 1.0 unless user specifies otherwise) 4. Ensure ./docs/prds/ exists for PRD output 5. Perform initial clarity assessment (0-100)
Assessment Rubric:
Functional Clarity: /30 points
- Clear inputs/outputs: 10 pts
- User interaction defined: 10 pts
- Success criteria stated: 10 pts
Technical Specificity: /25 points
- Technology stack mentioned: 8 pts
- Integration points identified: 8 pts
- Constraints specified: 9 pts
Implementation Completeness: /25 points
- Edge cases considered: 8 pts
- Error handling mentioned: 9 pts
- Data validation specified: 8 pts
Business Context: /20 points
- Problem statement clear: 7 pts
- Target users identified: 7 pts
- Success metrics defined: 6 ptsInitial Response Format:
I understand your requirement. Let me help you refine this specification.
**Current Clarity Score**: X/100
**Clear Aspects**:
- [List what's clear]
**Needs Clarification**:
- [List gaps]
Let me systematically clarify these points...Step 2: Gap Analysis
Identify missing information across four dimensions:
1. Functional Scope
- What is the core functionality?
- What are the boundaries?
- What is out of scope?
- What are edge cases?
2. User Interaction
- How do users interact?
- What are the inputs?
- What are the outputs?
- What are success/failure scenarios?
3. Technical Constraints
- Performance requirements?
- Compatibility requirements?
- Security considerations?
- Scalability needs?
4. Business Value
- What problem does this solve?
- Who are the target users?
- What are success metrics?
- What is the priority?
Step 3: Interactive Clarification
Question Strategy: 1. Start with highest-impact gaps 2. Ask 2-3 questions per round 3. Build context progressively 4. Use user's language 5. Provide examples when helpful
Question Format:
I need to clarify the following points to complete the requirements document:
1. **[Category]**: [Specific question]?
- For example: [Example if helpful]
2. **[Category]**: [Specific question]?
3. **[Category]**: [Specific question]?
Please provide your answers, and I'll continue refining the PRD.After Each User Response: 1. Update clarity score 2. Capture new information in the working PRD outline 3. Identify remaining gaps 4. If score < 90: Continue with next round of questions 5. If score ≥ 90: Proceed to PRD generation
Score Update Format:
Thank you for the additional information!
**Clarity Score Update**: X/100 → Y/100
**New Clarified Content**:
- [Summarize new information]
**Remaining Points to Clarify**:
- [List remaining gaps if score < 90]
[If score < 90: Continue with next round of questions]
[If score ≥ 90: "Perfect! I will now generate the complete PRD document..."]Step 4: PRD Generation
Once clarity score ≥ 90, generate comprehensive PRD.
Output File:
1. Final PRD: ./docs/prds/{feature_name}-v{version}-prd.md
Use the Write tool to create or update this file. Derive {version} from the document version recorded in the PRD (default 1.0).
PRD Document Structure
# {Feature Name} - Product Requirements Document (PRD)
## Requirements Description
### Background
- **Business Problem**: [Describe the business problem to solve]
- **Target Users**: [Target user groups]
- **Value Proposition**: [Value this feature brings]
### Feature Overview
- **Core Features**: [List of main features]
- **Feature Boundaries**: [What is and isn't included]
- **User Scenarios**: [Typical usage scenarios]
### Detailed Requirements
- **Input/Output**: [Specific input/output specifications]
- **User Interaction**: [User operation flow]
- **Data Requirements**: [Data structures and validation rules]
- **Edge Cases**: [Edge case handling]
## Design Decisions
### Technical Approach
- **Architecture Choice**: [Technical architecture decisions and rationale]
- **Key Components**: [List of main technical components]
- **Data Storage**: [Data models and storage solutions]
- **Interface Design**: [API/interface specifications]
### Constraints
- **Performance Requirements**: [Response time, throughput, etc.]
- **Compatibility**: [System compatibility requirements]
- **Security**: [Security considerations]
- **Scalability**: [Future expansion considerations]
### Risk Assessment
- **Technical Risks**: [Potential technical risks and mitigation plans]
- **Dependency Risks**: [External dependencies and alternatives]
- **Schedule Risks**: [Timeline risks and response strategies]
## Acceptance Criteria
### Functional Acceptance
- [ ] Feature 1: [Specific acceptance conditions]
- [ ] Feature 2: [Specific acceptance conditions]
- [ ] Feature 3: [Specific acceptance conditions]
### Quality Standards
- [ ] Code Quality: [Code standards and review requirements]
- [ ] Test Coverage: [Testing requirements and coverage]
- [ ] Performance Metrics: [Performance test pass criteria]
- [ ] Security Review: [Security review requirements]
### User Acceptance
- [ ] User Experience: [UX acceptance criteria]
- [ ] Documentation: [Documentation delivery requirements]
- [ ] Training Materials: [If needed, training material requirements]
## Execution Phases
### Phase 1: Preparation
**Goal**: Environment preparation and technical validation
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]
### Phase 2: Core Development
**Goal**: Implement core functionality
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]
### Phase 3: Integration & Testing
**Goal**: Integration and quality assurance
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]
### Phase 4: Deployment
**Goal**: Release and monitoring
- [ ] Task 1: [Specific task description]
- [ ] Task 2: [Specific task description]
- **Deliverables**: [Phase deliverables]
- **Time**: [Estimated time]
---
**Document Version**: 1.0
**Created**: {timestamp}
**Clarification Rounds**: {clarification_rounds}
**Quality Score**: {quality_score}/100Behavioral Guidelines
DO
- Ask specific, targeted questions
- Build on previous answers
- Provide examples to guide users
- Maintain conversational tone
- Summarize clarification rounds within the PRD
- Use clear, professional English
- Generate concrete specifications
- Stay in clarification mode until score ≥ 90
DON'T
- Ask all questions at once
- Make assumptions without confirmation
- Generate PRD before 90+ score
- Skip any required sections
- Use vague or abstract language
- Proceed without user responses
- Exit skill mode prematurely
Success Criteria
- Clarity score ≥ 90/100
- All PRD sections complete with substance
- Acceptance criteria checklistable (using
- [ ]format) - Execution phases actionable with concrete tasks
- User approves final PRD
- Ready for development handoff
Requirements Clarity
A systematic skill for transforming vague requirements into actionable Product Requirements Documents (PRDs) through focused dialogue and iterative clarification.
Purpose
This skill helps you avoid costly misunderstandings and rework by ensuring requirements are crystal clear before implementation begins. It uses a 100-point scoring system to systematically identify gaps and guide you through targeted questions until your requirements are development-ready.
When to Use This Skill
Use When
- Requirements are vague or ambiguous (e.g., "add login feature", "implement payment")
- Features are complex and estimated to take more than 2 days
- Cross-team coordination is required
- Missing technical context (no tech stack, integration points, or constraints mentioned)
- Incomplete specifications (no acceptance criteria, success metrics, edge cases)
- Unclear scope boundaries ("what exactly does 'user management' include?")
Don't Use When
- Specific file paths are mentioned (e.g., "fix auth.go:45")
- Code snippets are already included in the request
- Working with existing functions/classes (use code review instead)
- Bug fixes with clear reproduction steps
How It Works
The Clarification Process
1. Initial Analysis (Step 1)
- Parses your requirement description
- Generates a clarity score (0-100) using a detailed rubric
- Identifies what's clear and what needs clarification
- Creates a feature name and prepares for PRD generation
2. Gap Analysis (Step 2)
- Systematically identifies missing information across four dimensions:
- Functional Scope: Core functionality, boundaries, edge cases
- User Interaction: Inputs, outputs, success/failure scenarios
- Technical Constraints: Performance, compatibility, security, scalability
- Business Value: Problem statement, target users, success metrics
3. Interactive Clarification (Step 3)
- Asks 2-3 focused questions per round (avoids overwhelming you)
- Builds context progressively
- Updates clarity score after each response
- Continues until score reaches ≥ 90/100
4. PRD Generation (Step 4)
- Once clarity score ≥ 90, generates comprehensive PRD
- Saves to
./docs/prds/{feature-name}-v{version}-prd.md - Includes all clarified information in structured format
Clarity Scoring Rubric
The 100-point scoring system evaluates:
- Functional Clarity (30 points): Clear inputs/outputs, user interaction, success criteria
- Technical Specificity (25 points): Technology stack, integration points, constraints
- Implementation Completeness (25 points): Edge cases, error handling, data validation
- Business Context (20 points): Problem statement, target users, success metrics
Key Features
Systematic Questioning
- Focused, specific questions (not overwhelming)
- One category at a time
- Builds on previous answers
- Uses your language and provides examples
Quality-Driven Iteration
- Continuous clarity assessment
- Transparent score updates
- Iterates until ≥ 90 points achieved
- Documents all clarification rounds
Actionable Output
- Concrete specifications ready for development
- Measurable acceptance criteria (checklistable format)
- Executable implementation phases with specific tasks
- Complete PRD with all necessary sections
Core Principles
- Why? (YAGNI check) - Ensures features are truly needed
- Simpler? (KISS check) - Explores simpler alternatives before complex solutions
Usage Examples
Example 1: Vague Feature Request
User Input:
I need a login feature for my app.Skill Response:
I understand your requirement. Let me help you refine this specification.
Current Clarity Score: 25/100
Clear Aspects:
- Need authentication functionality
Needs Clarification:
- Authentication method (email/password, OAuth, SSO?)
- User types and permissions
- Security requirements
- Integration with existing systems
- Success metrics
Let me systematically clarify these points...
1. Authentication Method: What authentication method do you prefer?
- For example: Email/password, social login (Google/GitHub),
magic links, or SSO?
2. User Management: Do you need different user roles or permissions?
- For example: Admin vs. regular users, or all users have same access?
3. Technology Stack: What's your current tech stack?
- For example: React frontend, Node.js backend, PostgreSQL database?Example 2: After Clarification Round
After User Response:
Thank you for the additional information!
Clarity Score Update: 25/100 → 65/100
New Clarified Content:
- Authentication: Email/password with optional Google OAuth
- User roles: Admin and regular users with different permissions
- Tech stack: Next.js 14, PostgreSQL, using NextAuth.js
Remaining Points to Clarify:
- Password requirements and security constraints
- Session management (duration, refresh tokens?)
- Edge cases (account lockout, password reset)
- Success metrics (MAU, conversion rate?)
Let me continue with the next round of questions...
1. Security Requirements: What are your password requirements?
- For example: Minimum length, special characters, 2FA?
2. Session Management: How long should user sessions last?
- For example: 24 hours, 7 days, remember me option?
3. Edge Cases: How should we handle failed login attempts?
- For example: Rate limiting, account lockout after X attempts?Example 3: Final PRD Generation
When Clarity Score ≥ 90:
Perfect! I will now generate the complete PRD document...
[Generates PRD at ./docs/prds/user-authentication-v1.0-prd.md]
Your Product Requirements Document is ready!
File: ./docs/prds/user-authentication-v1.0-prd.md
Quality Score: 92/100
Clarification Rounds: 3
The PRD includes:
✓ Complete requirements description with background and value proposition
✓ Technical approach with architecture decisions
✓ Measurable acceptance criteria (functional, quality, user acceptance)
✓ 4 execution phases with specific tasks and deliverables
✓ Risk assessment and mitigation strategies
You can now hand this off to your development team for implementation.Generated PRD Structure
The final PRD includes:
1. Requirements Description
- Background (business problem, target users, value proposition)
- Feature overview (core features, boundaries, user scenarios)
- Detailed requirements (I/O, user interaction, data, edge cases)
2. Design Decisions
- Technical approach (architecture, components, data storage, interfaces)
- Constraints (performance, compatibility, security, scalability)
- Risk assessment (technical, dependency, schedule risks)
3. Acceptance Criteria
- Functional acceptance (feature-specific conditions)
- Quality standards (code quality, test coverage, performance, security)
- User acceptance (UX, documentation, training)
4. Execution Phases
- Phase 1: Preparation (environment setup, technical validation)
- Phase 2: Core Development (implement core functionality)
- Phase 3: Integration & Testing (quality assurance)
- Phase 4: Deployment (release and monitoring)
Each phase includes specific tasks, deliverables, and time estimates.
Output Location
PRDs are saved to:
./docs/prds/{feature-name}-v{version}-prd.mdWhere:
{feature-name}: Auto-generated in kebab-case format{version}: Document version (default 1.0, or user-specified)
Best Practices
DO
- Answer questions thoroughly but concisely
- Provide examples when you have specific preferences
- Ask for clarification if questions aren't clear
- Review the final PRD and provide feedback
- Share constraints and non-negotiables upfront
DON'T
- Rush through clarification rounds
- Assume the skill knows your technical context
- Skip questions that seem "obvious"
- Approve PRD before reviewing thoroughly
- Provide contradictory information across rounds
Success Criteria
A successful requirements clarification session results in:
- Clarity score ≥ 90/100
- All PRD sections complete with substantial content
- Acceptance criteria in checklistable format
- Execution phases with actionable, concrete tasks
- Development team can start implementation immediately
- No major questions or ambiguities remain
Tips for Better Results
1. Be Specific: Instead of "fast", say "< 200ms response time" 2. Think End-to-End: Consider the full user journey 3. Share Constraints Early: Technical limitations, budget, timeline 4. Provide Context: Explain the "why" behind your requirement 5. Reference Examples: "Like Stripe's payment flow" is clearer than abstract descriptions
Related Skills
- feature-planning: For breaking down features after PRD is complete
- implementation-blueprint: For detailed implementation planning
- dev-spec: For complete design and planning sessions
- critical-brainstorm: For exploring and stress-testing ideas before clarification
---
Need help clarifying requirements? Invoke this skill and provide your initial requirement description. The skill will guide you through systematic clarification until you have a development-ready PRD.
Related skills
How it compares
Pick requirements-clarity over coding-first skills when the input is an ambiguous feature request and a scored PRD must exist before implementation.
FAQ
What questions does requirements-clarity ask?
requirements-clarity asks two core questions before implementation: Why to apply a YAGNI check on necessity, and Simpler to apply a KISS check on scope. These questions expose missing motivation, over-engineering, and unclear acceptance criteria in vague requests.
When should requirements-clarity run?
requirements-clarity should run when requirements are unclear, features are complex enough to exceed two days of work, or cross-team coordination is involved. The skill produces a scored PRD before any code is written.
Is Requirements Clarity safe to install?
skills.sh reports 3 of 3 security scanners passed. Review the Security Audits panel on this page before installing in production.