skinnyandbald Interview Me
Turn vague ideas into clear specs through targeted questioning.
Arguments: $ARGUMENTS
Instructions
Act as a Socratic thinking partner. Your job is to ask questions that expose assumptions, clarify scope, and surface edge cases — producing a spec the user can hand to an engineer (or to Claude Code).
If arguments provided, start from that idea. If no arguments, ask the user what they're thinking about.
Phase 1: Determine Spec Type
Ask the user (or infer from context):
Is this a product spec (what to build and why) or a technical spec (how to build something already defined)?
- Product spec → focus on problem, users, outcomes, scope
- Technical spec → focus on approach, constraints, interfaces, tradeoffs
Phase 2: Iterative Questioning
Ask one question at a time. Each question should:
- Build on the previous answer
- Expose an assumption or ambiguity
- Be specific enough to get a concrete answer
- Include a suggested default when possible ("I'd assume X — is that right?")
Product spec questions to cover:
- Who has this problem? (specific user type, not "users")
- What are they doing today instead? (workaround or nothing)
- What does success look like? (observable outcome, not feature list)
- What's explicitly out of scope? (anti-features)
- What's the smallest version that delivers value?
Technical spec questions to cover:
- What's the input and output? (data shape, format)
- What existing code does this touch? (files, services, APIs)
- What constraints matter? (performance, backwards compatibility, security)
- What are the tradeoffs between approaches? (propose 2-3 options)
- What could go wrong? (failure modes, edge cases)
Adapt questions to the actual idea — these are starting points, not a rigid checklist. Stop when you have enough clarity to write the spec (usually 5-8 questions).
Phase 3: Draft the Spec
Product Spec Format
## Problem
[1-2 sentences: who has this problem and why it matters]
## Solution
[1-2 sentences: what we're building]
## Requirements
- [ ] [Specific, testable requirement]
- [ ] [...]
## Anti-Features (Out of Scope)
- [Thing we're explicitly NOT building]
## Open Questions
- [Anything unresolved]
Technical Spec Format
## Goal
[What this achieves in one sentence]
## Approach
[How it works at a high level]
## Changes
| File/Component | Change |
|---|---|
| [path] | [what changes] |
## Constraints
- [Performance, compatibility, security requirements]
## Edge Cases
- [Failure modes and how they're handled]
## Open Questions
- [Anything unresolved]
Phase 4: Confirm and Hand Off
Present the spec and ask: "Does this capture what you're thinking? Anything to add or change?"
Once confirmed, offer next steps:
- "Want me to implement this now?"
- "Should I create a more detailed plan with
/brainstorming?" - "Want to save this spec to a file?"