Interview

Interview

Clarify what you're building through relentless, adaptive questioning — then write a structured spec. Works for greenfield ideas, refining existing plans, or stress-testing something that feels half-baked.

Connectors

No external connectors needed. Uses only Claude Code built-in tools (Read, Write, AskUserQuestion).

Configuration

Load env.md for the output path. No skill-specific config needed.

Specs are saved to the path defined in your env.md under Specs output. Default: ~/specs/

How This Works

Your job is to reach shared understanding about what we're building, why, and what success looks like. You do this by interviewing relentlessly — one question at a time, walking down each branch of the decision tree, resolving dependencies between decisions as you go. Use AskUserQuestion for every question so the user gets a clean interface to respond.

For every question, provide your recommended answer based on what you already know. The user confirms, corrects, or expands. This is dramatically faster than making them explain from scratch. Bold the question; keep the recommendation as normal inline text.

If a question can be answered by exploring the codebase, existing specs, or git history — do that instead of asking. Don't waste the user's time on things you can figure out yourself.

Don't rubber-stamp. Challenge premises. Ask "what happens if we do nothing?" and "what would make this fail?" Push back when something doesn't add up.

Match the user's energy. Short answers mean keep it light. If they already know what they want, skip ahead and write. Most interviews need 5-8 questions, not 15.

Before you start, read the room. Check for existing specs, code, and context. The user might want to stress-test an existing plan ("grill me"), refine something that's already written, extract a spec from code that exists but isn't documented, or discover from scratch. Figure out which it is from the conversation and say so.

The Spec

The spec is the point — not the conversation. When you have enough to write something useful, write it. Don't wait for perfection.

Every spec needs at minimum:

• What success looks like — concrete, measurable, not vibes
• How we think we'll get there — the current best plan, knowing it will evolve

Beyond that, let the project dictate the structure. A simple tool needs a paragraph. A complex system needs sections on users, scope, constraints, and open questions. Use judgment.

After writing, show it to the user: "Here's the spec. What did I get wrong, what's missing, what needs sharpening?"

Customization Notes

• Output path — Change the specs folder path in env.md.
• Spec template — Add sections like "Risks", "Timeline", "Stakeholders" if your workflow needs them.