Free SKILL.md scraped from GitHub. Clone the repo or copy the file directly into your Claude Code skills directory.
npx versuz@latest install kevinzai-commander-skills-spec-interviewergit clone https://github.com/KevinZai/commander.gitcp commander/SKILL.MD ~/.claude/skills/kevinzai-commander-skills-spec-interviewer/SKILL.md---
name: spec-interviewer
description: |
Structured spec interview for new features and projects. Asks 5-7 targeted questions
using AskUserQuestion, then generates a formatted spec document. Use for ANY feature
that will take more than 1 day of work. Always run in a SEPARATE session from execution.
Based on Thariq Shihipar's (Claude Code lead) highest-leverage workflow.
allowed-tools:
- AskUserQuestion
- Read
- Write
- Bash
---
# 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):
1. **What are we building?** — One sentence. What does it do?
2. **Who is it for?** — End user, internal tool, API consumer, another agent?
3. **Why now?** — What triggered this? Revenue, tech debt, user request, competitive?
4. **What exists today?** — Current state. What works, what doesn't?
5. **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:
6. **Tech stack constraints?** — Must use X framework? Must integrate with Y?
7. **Data model?** — What entities, relationships, storage needs?
8. **External dependencies?** — APIs, services, auth providers, payments?
9. **Performance requirements?** — Latency, throughput, data volume?
10. **Security requirements?** — Auth, RBAC, data sensitivity, compliance?
### Phase 3: Success Criteria
11. **How do we know it works?** — 3-5 concrete acceptance criteria
12. **What does "done" look like?** — Ship to prod? PR merged? Demo to Kevin?
## Output Format
Write to `tasks/spec-YYYYMMDD-{slug}.md`:
```markdown
# 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.