Requirements Clarity
Run a focused clarification dialogue on vague feature asks so you ship a scored, actionable PRD instead of guessing scope during implementation.
Overview
Requirements Clarity is an agent skill most often used in Validate (scope) (also Build PM) that clarifies ambiguous requirements into scored PRDs via YAGNI and KISS questioning.
Install
npx skills add https://github.com/softaworks/agent-toolkit --skill requirements-clarityWhat is this skill?
- Detects vague requests like 'add login' or 'create dashboard' missing stack, constraints, and acceptance criteria
- Two core probes: Why? (YAGNI) and Simpler? (KISS) plus systematic category questioning
- Transforms ambiguity into actionable PRD output with a 100-point scoring system
- Skips activation when paths, snippets, or clear bug repro steps already anchor the work
- Explicit do-not-use cases: specific file:line fixes and fully specified implementation tasks
- 100-point scoring system for requirement clarity
- Two core clarification questions: Why? (YAGNI) and Simpler? (KISS)
Adoption & trust: 562 installs on skills.sh; 2k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
Someone asked for 'user management' or 'payments' without stack, boundaries, or acceptance criteria—and you are one prompt away from building the wrong thing for days.
Who is it for?
Feature ideas estimated over two days, cross-team coordination, or any ask missing acceptance criteria and explicit non-goals.
Skip if: File-specific bug fixes, edits with code snippets attached, or tasks where reproduction steps and targets are already unambiguous.
When should I use this skill?
Requirements are unclear, features are complex (>2 days), or involve cross-team coordination—ask Why? and Simpler? before implementation; skip when specific paths, snippets, or clear bug steps are provided.
What do I get? / Deliverables
You end with a clarified, actionable PRD and clarity score so implementation can start with explicit scope, metrics, and documented exclusions.
- Actionable PRD with boundaries, acceptance criteria, and clarity score
- Documented exclusions and simpler MVP alternative where applicable
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Validate → scope is the canonical shelf because the skill exists to stop ambiguous asks before they become expensive build churn. Scope subphase is where YAGNI/KISS questioning, acceptance criteria, and explicit in/out boundaries belong—before tickets and code.
Where it fits
Pressure-test a 'payments' ask for stack, compliance boundaries, and MVP vs later before estimating build time.
Clarify which monetization capabilities are in v1 when the idea bundles billing, trials, and usage limits in one sentence.
Re-run clarification when a cross-team epic lands without acceptance criteria mid-sprint.
How it compares
Use instead of jumping straight from a one-line feature request to codegen without a YAGNI/KISS pass and scored requirements doc.
Common Questions / FAQ
Who is requirements-clarity for?
Solo and indie builders and tiny teams who need PRD-level clarity before agent-assisted implementation on non-trivial features.
When should I use requirements-clarity?
In Validate when scoping MVPs or pricing/features, and in Build PM when a new epic is complex or cross-cutting—especially if the ask is vague and lacks acceptance criteria.
Is requirements-clarity safe to install?
Review the Security Audits panel on this Prism page; the skill is conversational clarification and document structuring, not shell or network automation.
SKILL.md
READMESKILL.md - Requirements Clarity
# 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 pts ``` **Initial Response Format**: ```markdown 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.