Menu
Write a detailed feature spec with requirements, edge cases, and technical constraints. Use when a feature needs formal documentation before engineering begins.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
Build a complete business case for a product investment — strategic rationale, financial model, risk assessment, and recommendation. Use when you need executive approval for a major initiative.
Run ROI, IRR, NPV, payback period, and cost-benefit analysis for product investments. Use when you need to quantify the financial case for building something.
Decompose a large problem, epic, or initiative into independently shippable slices. Use when work is too big to build in one sprint and you need to find the seams.
Deep dive into product analytics — investigate a question, surface insights, build a data narrative. Use when you need to go beyond dashboards to understand what's happening.
Define an epic with strategic context, feature breakdown, milestones, and success metrics. Use when scoping a large body of work for planning and tracking.
Write a complete PRD from problem statement to builder-ready spec. Use when you need a formal product requirements document for a new initiative.
| name | feature-specification |
| description | Write a detailed feature spec with requirements, edge cases, and technical constraints. Use when a feature needs formal documentation before engineering begins. |
Detail a feature from concept to builder-ready spec in 30-60 minutes. Claude enumerates the requirements, edge cases, error states, and integration points that humans typically miss. You provide the user context and make the trade-off calls on complexity vs. value.
| Step | Time | Claude Does | You Do |
|---|---|---|---|
| Define the feature | 10 min | Structure the feature description, user value, and context | Confirm the framing matches intent |
| Detail requirements | 15 min | Draft functional and non-functional requirements | Validate with engineering, flag unknowns |
| Enumerate edge cases | 10 min | Systematically identify edge cases and error states | Decide which to handle in v1 vs. defer |
| Define acceptance criteria | 10 min | Write testable acceptance criteria for each requirement | Confirm they match what "done" means |
| Document integration points | 10 min | Map API contracts, data flows, and system dependencies | Verify with engineering leads |
I need to spec out a feature: [feature name]
Context:
- Epic it belongs to: [epic name/link]
- User segment: [who uses this]
- User value: [what job it does for the user — in their words]
- Business value: [why the business cares]
Current state:
- What exists today: [current experience or workaround]
- What changes: [what's new or different]
Constraints known upfront:
- [Technical constraints, platform limitations, compliance requirements]
- [Timeline constraints — when does this need to ship?]
Draft the requirements for this feature:
Functional requirements (what it must do):
- [Requirement 1] — [why]
- [Requirement 2] — [why]
- [Requirement 3] — [why]
For each requirement, specify:
- Input: what triggers this behavior
- Output: what the user sees or what the system does
- Rules: business logic, validation, calculations
Non-functional requirements:
- Performance: [latency, throughput targets]
- Scale: [expected usage volume, growth projections]
- Security: [authentication, authorization, data handling]
- Accessibility: [WCAG level, specific accommodations]
- Compatibility: [browsers, devices, OS versions, screen sizes]
This is where AI adds disproportionate value. Humans tend to spec the happy path. Claude catches the rest.
For each functional requirement, enumerate edge cases:
- Empty states: what does the user see before any data exists?
- Error states: what happens when the request fails, times out, or returns unexpected data?
- Boundary conditions: what happens at the minimum, maximum, and zero values?
- Permission states: what happens when the user doesn't have access?
- Concurrent states: what happens when two users modify the same data?
- Interruption states: what happens when the user abandons mid-flow, loses connection, or navigates away?
- Migration states: what happens for existing users vs. new users?
- Degraded states: what happens when a dependency is slow or unavailable?
For each edge case: what should the user see, and what should the system do?
Write acceptance criteria for each requirement and key edge case:
Format:
Given [precondition]
When [action]
Then [expected result]
Rules:
- Every criterion must be testable — if you can't write a manual or automated test, rewrite it
- Include both positive cases (it works) and negative cases (it handles failure)
- Specify exact values where possible, not "appropriate" or "reasonable"
- Include performance criteria where relevant (e.g., "responds within 200ms")
Map the integration points for this feature:
For each system this feature touches:
- System: [name]
- Integration type: [API call, event, webhook, database query, file transfer]
- Direction: [reads from / writes to / both]
- Contract: [endpoint, payload format, authentication]
- Failure mode: [what happens when this integration fails]
- Owner: [team responsible for the other side]
Data flow:
- What data does this feature create, read, update, or delete?
- Where does it come from and where does it go?
- What's the source of truth?
- Any data retention or privacy implications?