| name | spec |
| description | Write a comprehensive product or engineering specification before implementation. Use when the user asks for `/spec`, PRDs, feature specs, API specs, refactor specs, acceptance criteria, user stories, edge cases, or open decision tracking before code is written. |
Spec
Overview
Use this skill to turn a feature, API, refactor, or product idea into a clear specification that can feed planning and implementation. The output should reduce ambiguity before code is written.
Workflow
- Identify the problem, goal, users, constraints, and non-goals.
- Capture the current behavior or system context when relevant.
- Define user stories or use cases with acceptance criteria.
- Specify functional requirements, edge cases, error states, permissions, and data handling.
- Include API, UI, migration, observability, performance, or rollout requirements when applicable.
- List open decisions and assumptions explicitly.
- Keep the spec implementation-aware but avoid over-prescribing internal code structure unless required.
Output Pattern
Use this structure by default:
- Summary.
- Problem statement.
- Goals and non-goals.
- Users and use cases.
- Requirements.
- Acceptance criteria.
- Edge cases and risks.
- Observability, rollout, and rollback notes.
- Open questions.
Example Prompts
/spec - Build a CSV export feature for our analytics dashboard. Users need to export filtered data with custom date ranges. Support up to 100k rows.
/spec - Design a public webhooks API for our platform. Third-party apps need to subscribe to user events and receive payloads reliably with retry logic.
/spec - Refactor our authentication flow to support SSO. We need to keep existing email/password working and add Google and GitHub OAuth without breaking current sessions.