requirements-clarity
Skill1 starsChanged 59 days agoMITView on GitHub
Clarify ambiguous requirements through focused dialogue...
7 other projects use a version of this, 7 of them edited.
Adopted by
Most recently taken up by
- imMamdouhaboammar/kaku-chatgpt-harnessedited, first seen Oct 25, 2026
- Samueladewole/claude-skillsedited, first seen Oct 13, 2026
- digitalspeed/claude-code-skillsetedited, first seen Jun 17, 2026
- KellyDigitalArmy/ClaudeCodeedited, first seen May 5, 2026
- nbirkner/digital-brainedited, first seen Apr 12, 2026
- FelipeAngeli/skillsedited, first seen Apr 10, 2026
Other versions7 projects use a version of this.
Word for word · 0
None found.
Edited · 7
- pedronauck/skills★ 655100% same
- FelipeAngeli/skills★ 2100% same
- digitalspeed/claude-code-skillset★ 1100% same
- imMamdouhaboammar/kaku-chatgpt-harness★ 0100% same
- KellyDigitalArmy/ClaudeCode★ 0100% same
- nbirkner/digital-brain★ 055% same
- Samueladewole/claude-skills★ 0100% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository67 other files it gives its agents.
- architect-reviewerSkill
- backend-architectSkill
- backend-developerSkill
- code-architectSkill
- codebase-explorerSkill
- code-reviewerSkill
- code-simplifierSkill
- debuggerSkill
- error-detectiveSkill
- fullstack-developerSkill
- git-workflow-managerSkill
- legacy-modernizerSkill
- pragmatic-architectSkill
- prdSkill
- qa-expertSkill
- research-technical-spikeSkill
- sdd-spec-writerSkill
- security-auditorSkill
- supply-chain-securitySkill
- task-decomposition-expertSkill
- technical-debt-managerSkill
- test-engineerSkill
- typescript-proSkill
- architecture-decision-recordsSkill
- hermes-sdd-packagingSkill
- bug-diagnosisSkill
- build-craftSkill
- code-healthSkill
- code-review-checklistSkill
- commit-smartSkill
- context-architectureSkill
- design-explorationSkill
- design-to-htmlSkill
- developer-experience-reviewSkill
- diagram-tripletSkill
- dispatching-parallel-agentsSkill
- document-diataxisSkill
- e2e-testing-patternsSkill
- executing-plansSkill
- module-designSkill
- openspec-apply-changeSkill
- openspec-archive-changeSkill
- openspec-bulk-archive-changeSkill
- openspec-continue-changeSkill
- openspec-exploreSkill
- openspec-ff-changeSkill
- openspec-new-changeSkill
- openspec-onboardSkill
- openspec-proposeSkill
- openspec-sync-specsSkill
- openspec-update-changeSkill
- openspec-verify-changeSkill
- plan-scope-reviewSkill
- project-learningsSkill
- qa-test-plannerSkill
- review-structuralSkill
- security-evidence-firstSkill
- agency-invocationSkill
- hermes-sdd-orchestrationSkill
- openspec-sddSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
21 rules. 19 are common, 0 are distinctive, and 2 are very specific to this project.
19
Common
Most of the 7 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Common: line 17
When invoked, detect vague requirements:
- Common: line 24
No technology stack mentioned
- Common: line 25
No integration points identified
- Common: line 26
No performance/security constraints
- Common: line 31
No edge cases considered
- Common: line 32
No error handling mentioned
- Common: line 36
No distinction between MVP and future enhancements
- Common: line 48
Ask focused, specific questions
- Common: line 57
Document all clarification rounds
- Very specific: line 75
Ensure ./docs/prds/ exists for PRD output
- Common: line 147
Start with highest-impact gaps
- Common: line 148
Ask 2-3 questions per round
- Common: line 150
Use user's language
- Common: line 171
If score < 90: Continue with next round of questions
- Common: line 172
If score ≥ 90: Proceed to PRD generation
- Very specific: line 198
Use the Write tool to create or update this file.
- Common: line 301
Ask specific, targeted questions
- Common: line 306
Use clear, professional English
- Common: line 311
Ask all questions at once
- Common: line 315
Use vague or abstract language
- Common: line 322
All PRD sections complete with substance
“Common” is measured: kept by at least 6 in 10 of the 7 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
<!-- hermes-add-skill: description trimmed from 286 chars to fit Hermes' 60-char index --><!-- original description: Clarify ambiguous requirements through focused dialogue before implementation. Use when requirements are unclear, features are complex (>2 days), or involve cross-team coordination. Ask two core questions - Why? (YAGNI check) and Simpler? (KISS check) - to ensure clarity before coding. -->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:
- Vague Feature Requests
- User says: "add login feature", "implement payment", "create dashboard"
- Missing: How, with what technology, what constraints?
- Missing Technical Context
- No technology stack mentioned
- No integration points identified
- No performance/security constraints
- Incomplete Specifications
- No acceptance criteria
- No success metrics
- No edge cases considered
- No error handling mentioned
- 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
- Systematic Questioning
- Ask focused, specific questions
- One category at a time (2-3 questions per round)
- Build on previous answers
- Avoid overwhelming users
- Quality-Driven Iteration
- Continuously assess clarity score (0-100)
- Identify gaps systematically
- Iterate until ≥ 90 points
- Document all clarification rounds
- 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:
- Parse and understand core requirement
- Generate feature name (kebab-case format)
- Determine document version (default
1.0unless user specifies otherwise) - Ensure
./docs/prds/exists for PRD output - 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:
- Start with highest-impact gaps
- Ask 2-3 questions per round
- Build context progressively
- Use user's language
- 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:
- Update clarity score
- Capture new information in the working PRD outline
- Identify remaining gaps
- If score < 90: Continue with next round of questions
- 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:
- 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
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

