Spec Interviewer
When to Use
- Any new feature, project, or significant refactor
- Before writing ANY code on a complex task
- When requirements are ambiguous or multi-stakeholder
Process
Phase 1: Context Discovery
Ask the user these questions (adapt based on answers):
- What are we building? — One sentence. What does it do?
- Who is it for? — End user, internal tool, API consumer, another agent?
- Why now? — What triggered this? Revenue, tech debt, user request, competitive?
- What exists today? — Current state. What works, what doesn't?
- What's the scope boundary? — What is explicitly NOT in scope?
Phase 2: Technical Requirements
Based on Phase 1 answers, ask 2-3 of these:
- Tech stack constraints? — Must use X framework? Must integrate with Y?
- Data model? — What entities, relationships, storage needs?
- External dependencies? — APIs, services, auth providers, payments?
- Performance requirements? — Latency, throughput, data volume?
- Security requirements? — Auth, RBAC, data sensitivity, compliance?
Phase 3: Success Criteria
- How do we know it works? — 3-5 concrete acceptance criteria
- What does "done" look like? — Ship to prod? PR merged? Demo to Kevin?
Output Format
Write to tasks/spec-YYYYMMDD-{slug}.md:
# Spec: {Feature Name}
**Date:** YYYY-MM-DD
**Author:** Claude Code (spec-interviewer)
**Status:** Draft → Approved → In Progress → Done
## Summary
One paragraph describing what we're building and why.
## Requirements
### Must Have (P0)
- [ ] Requirement 1
- [ ] Requirement 2
### Should Have (P1)
- [ ] Requirement 3
### Nice to Have (P2)
- [ ] Requirement 4
## Technical Design
- Stack: ...
- Data model: ...
- Key integrations: ...
## Acceptance Criteria
1. [ ] Criterion 1 — testable, specific
2. [ ] Criterion 2
3. [ ] Criterion 3
## Out of Scope
- Explicitly excluded items
## Open Questions
- Any unresolved items from the interview
Critical Rule
Execute the spec in a NEW session. The interview session pollutes context with back-and-forth. The execution session starts clean with only the spec file loaded, which means perfect prompt cache hits on the system prompt + CLAUDE.md prefix.
Gotchas
- Don't ask all 12 questions — adapt based on complexity. Simple feature = 5 questions.
- If the user says "just build it" — push back once. Specs save more time than they cost.
- For OpenClaw agent features: always ask about model routing and cost tier.
- For UI features: always ask about responsive behavior and design system compliance.