Requirements Clarification
- 47 installs
- 4 repo stars
- Updated June 18, 2026
- doubleslashse/claude-marketplace
Clarify requirements before the TDD RED phase by asking targeted questions to uncover ambiguities, edge cases, and acceptance criteria.
About
Guides asking targeted questions before writing tests to know what behavior to test. A developer uses it before the RED phase to surface ambiguities and acceptance criteria.
- Runs before RED to define what to test
- Uncovers edge cases and acceptance criteria
Requirements Clarification by the numbers
- 47 all-time installs (skills.sh)
- Ranked #1,237 of 2,153 Testing & QA skills by installs in the Skillselion catalog
- Data as of Jul 29, 2026 (Skillselion catalog sync)
npx skills add https://github.com/doubleslashse/claude-marketplace --skill requirements-clarificationAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 47 |
|---|---|
| repo stars | ★ 4 |
| Last updated | June 18, 2026 |
| Repository | doubleslashse/claude-marketplace ↗ |
What it does
Clarify requirements before the TDD RED phase by asking targeted questions to uncover ambiguities, edge cases, and acceptance criteria.
Files
Requirements Clarification for TDD
Purpose
Before writing tests (RED phase), ensure requirements are understood well enough to: 1. Know WHAT behavior to test 2. Identify edge cases and boundaries 3. Understand acceptance criteria 4. Avoid rework from misunderstood requirements
When to Use
Initiate clarification when:
- Feature description is less than 2 sentences
- No acceptance criteria provided
- Ambiguous terms like "should handle errors appropriately"
- Business logic without specific rules defined
- No example inputs/outputs given
When to Skip
Skip clarification when:
- Requirements explicitly define acceptance criteria
- User provides detailed test scenarios
- Simple CRUD with clear schema
- Bug fix with clear reproduction steps
- User requests "skip clarification" or "proceed directly"
Question Categories
1. Functional Requirements
| Question | Purpose |
|---|---|
| What is the primary happy path behavior? | Establish main test scenario |
| What inputs does this feature accept? | Define parameter validation tests |
| What outputs/results are expected? | Define assertion expectations |
| What side effects should occur? | Identify integration points |
| Are there any business rules or constraints? | Identify validation logic |
2. Edge Cases and Boundaries
| Question | Purpose |
|---|---|
| What happens with null/empty input? | Null handling tests |
| What are the boundary values (min/max)? | Boundary condition tests |
| What if required dependencies are unavailable? | Error handling tests |
| Are there concurrency or timing concerns? | Thread safety tests |
3. Error Handling
| Question | Purpose |
|---|---|
| What exceptions should be thrown and when? | Exception tests |
| How should invalid input be handled? | Validation tests |
| What error messages should users see? | User feedback tests |
4. Technical Clarification
| Question | Purpose |
|---|---|
| What interfaces/abstractions already exist? | Understand dependencies |
| What existing patterns should be followed? | Consistency with codebase |
| Are there existing tests to follow as examples? | Test style consistency |
| What is the target test scope (unit/integration)? | Test organization |
Clarification Workflow
┌─────────────────────────────────────────────────────────────────┐
│ CLARIFICATION PHASE │
├─────────────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ Analyze │───▶│ Identify │───▶│ Present │ │
│ │ Requirements │ │ Gaps │ │ Questions │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │ │
│ │ Collect │◀──────────┘ │
│ │ Answers │ │
│ └──────────────┘ │
│ │ │
│ ┌──────────────┐ │
│ │ Sufficient? │ │
│ └──────────────┘ │
│ │ │ │
│ YES NO │
│ │ │ │
│ ▼ └──────▶ Ask Follow-up │
│ ┌──────────────┐ │
│ │ Proceed to │ │
│ │ RED Phase │ │
│ └──────────────┘ │
│ │
│ EXIT: Requirements clear enough to define test scenarios │
└─────────────────────────────────────────────────────────────────┘Output Template
After clarification, document understanding:
## Clarified Requirements for {Feature}
### Understanding Summary
{Brief summary of what the feature should do}
### Inputs and Outputs
- **Inputs**: {List with types}
- **Outputs**: {Expected results}
- **Validation Rules**: {Business rules}
### Identified Test Scenarios
| Scenario Type | Description | Priority |
|---------------|-------------|----------|
| Happy Path | {description} | High |
| Edge Case | {description} | Medium |
| Error Case | {description} | Medium |
| Boundary | {description} | Medium |
### Ready for RED PhaseMinimum Questions (Always Consider)
1. What is the expected behavior for the happy path? 2. What inputs does this accept and what outputs does it produce? 3. How should errors/invalid input be handled?
Related skills
TddFollow test-driven development with a strict red-green-refactor loop when creating reliable features or fixing bugs.544k196k
Test Driven DevelopmentEnforce writing failing tests before any production implementation code.181k264kQaRun conversational QA sessions that turn user-reported bugs into well-written, domain-aware GitHub issues without manual ticket writing.179k196kMigrate To ShoehornAutomatically update TypeScript test files that rely on unsafe `as` type assertions by replacing them with type-safe partial objects from @total-typescript/shoehorn.164k196k
Webapp TestingVerify frontend behavior, debug UI issues, capture screenshots, and inspect logs of a running local web application using Playwright.123k165k
Playwright CliRun browser automation, generate element snapshots, inspect DOM attributes, and execute Playwright tests from the terminal.102k12.3k