v1-interview-me - SKILL.md Agent Skill

name: v1-interview-me description: Use when the user provides an idea, feature request, Linear ticket, or concept that needs fleshing out, product validation, or office-hours-style questioning. Triggers on "interview me about X", "help me spec out Y", "I have an idea for Z", "flesh out this idea", "office hours", "is this worth building". allowed-tools: - Bash - Read - Grep - Glob - AskUserQuestion - Skill

Interview Me

Collaboratively refine ideas through structured questioning, helping the agent understand the idea and the user crystallize their thinking. The interview process itself is valuable, not just the final deliverable.

Usage

Typical invocations:

Claude Code: /v1-interview-me [LINEAR_TICKET_ID or idea]
Codex: invoke v1-interview-me from the skills menu or use $v1-interview-me [LINEAR_TICKET_ID or idea]

Examples:

/v1-interview-me
/v1-interview-me <LINEAR_TICKET_ID>
/v1-interview-me <paste idea or feature description>

In Codex, the slash examples below map directly to $v1-interview-me ....

Can also be triggered conversationally: "I have an idea for X", "help me spec out Y", "flesh out this concept".

Interview Workflow

1. Understand the Starting Point

Read any provided context (Linear ticket, feature description, rough idea). Identify:

What's explicitly stated vs. what's assumed
The domain and technical context
Who the stakeholders are

2. Gather Existing Context

Before interviewing, explore what already exists using available tools:

Linear/Jira: Fetch project descriptions, related issues, initiative context
Codebase: Search for related code, existing implementations, architectural patterns
Documents: Read related specs, PRDs, or design docs

Hard rule: if a question can be answered by exploring the codebase, Linear, or documents -- explore instead of asking. Only interview for things that require the user's judgment, intent, or domain knowledge. Don't waste interview rounds on things you can look up.

2.5 Choose the Interview Posture

Classify the session before asking the first question:

Posture	Use When	Interview Bias
Startup diagnostic	Customer, revenue, fundraising, market, internal sponsor, adoption, or "worth building" language appears	Clarify the learning decision; switch to `v1-learning-from-customers` for discovery planning, question audits, notes synthesis, or demand review
Builder exploration	Side project, learning, hackathon, open source, creative tool, or "cool thing" language appears	Delight, fastest demo, who to show, surprising combinations, next build step
Implementation spec	User already knows this should be built	Decisions, constraints, edge cases, integration, validation
Socratic operational diagnostic	Bottleneck, queue, WIP, throughput, "everything is urgent", process failure, handoff delay, or stuck team language appears	Clarify the system boundary; switch to `v1-diagnosing-constraints` for constraint diagnosis

Default to Startup diagnostic when the user asks whether something is worth building. Default to Builder exploration when the user wants to riff before committing. Switch postures mid-interview if the user's answers reveal a different job.

For startup-diagnostic sessions, ask only enough to identify the learning decision, target customer slice, and current evidence gap. If the user wants a discovery plan, question audit, interview synthesis, demand assessment, or JTBD job spec, switch to v1-learning-from-customers.

Builder exploration prompts:

What's the version you would be excited to show someone this week?
What would make the first demo feel surprisingly good?
What's the fastest path to something usable?
What existing thing is closest, and what should be different?
What would the 10x version include if time were free?

For operational-diagnostic sessions, ask only enough to identify the system goal, boundary, and visible symptom. If the user wants the diagnosis rather than interview notes, switch to v1-diagnosing-constraints.

End every posture with one concrete assignment: the next thing the user or agent should do.

3. Map the Decision Tree

After gathering context, identify the major decisions and branches in the design. List them explicitly:

"I see these key decisions that need resolving: A, B, C..."

Walk dependencies in order -- resolve upstream decisions before probing downstream ones. A decision is "resolved" when it reaches one of these states:

State	Example
Decided	"We'll use webhooks, not polling"
Intentionally deferred	"We'll decide the retry strategy after load testing"
Blocked on external input	"Need pricing info from the vendor before choosing"

Branch closure rule: don't move on from a decision until it reaches one of these states. This prevents the interview from producing a spec full of implicit assumptions.

4. Open with the Right First Question

The first question shapes the entire interview. Choose based on what the user provided:

Starting Input	First Question Strategy
Vague idea ("I want to build X")	"What's the problem you're solving, and who has it worst right now?"
Feature request with some detail	"What workaround are people using today, and what breaks about it?"
Linear ticket / spec	"What's the most uncertain part of this spec?"
Technical concept	"What's the simplest version of this that would be useful?"
Operational bottleneck or process failure	"Where does work pile up or wait before the outcome is delivered?"

Avoid generic openers like "tell me more" or "what's the goal." The first question should demonstrate you understood the input and are already thinking ahead.

In the same opening round, calibrate depth:

"Are you looking for a full spec, or more of an initial analysis to decide if this is worth pursuing?"

Then adjust the rest of the interview:

Full design: Probe until implementation-ready. Cover all relevant question categories.
Analysis/exploration: Stop when problem is well-characterized, solutions can be TBD. Focus on Current State, Constraints, Risk & Priority.
Mixed: Go deep on core areas, lighter on peripheral ones.

5. Conduct the Interview

Use AskUserQuestion repeatedly. Interview until sufficient understanding is reached.

Question Strategy:

Ask 2-4 questions per round maximum
Each question should unlock new understanding, not confirm obvious facts
Progress from foundational to detailed to edge cases
When an answer reveals complexity, drill deeper before moving on
Use multiSelect: true when choices aren't mutually exclusive

Progressive Synthesis:

After every 2-3 rounds, share a brief summary of your current understanding:

"Here's what I'm hearing so far: [2-4 sentence synthesis]. Before I go deeper on X, does this track?"

Frame as a checkpoint, not a conclusion
If the user corrects the summary, acknowledge and adjust before continuing
Keep these lightweight -- conversational, not a slide deck
This catches drift early instead of discovering misalignment at the end

Handling Uncertainty:

Response Type	Meaning	Action
"I don't know"	Needs research	Record as Open Question (research needed), move on
"I haven't decided"	Decision pending	Record as Open Question (decision needed), note tradeoffs discussed
"It depends"	Conditional answer	Drill into conditions -- "What does it depend on?" Get the conditions enumerated.
"I don't care" / "Either way"	Low priority for user	Make a reasonable default recommendation and note it
"We should ask [person]"	Blocked on stakeholder	Record as Open Question (blocked: [person]), move on

Don't keep pushing when user signals uncertainty. Document it with the right label and move on.

Adapt to Communication Style:

Terse answers: User is busy or decisive. Ask fewer, more targeted questions. Don't re-ask in different words.
Long, exploratory answers: User is thinking out loud. Let them finish, then synthesize back before next question.
"I don't know" frequently: Shift from probing to proposing. Offer options instead of open questions.
Technical depth: Match their level. Don't oversimplify for an engineer or get technical with a PM.

Constructive Challenge:

Actively probe for weak spots in the plan:

Expose weak defaults, conflicting assumptions, and irreversible choices
Surface flawed assumptions as questions: "I notice X assumes Y, but earlier you said Z -- how do those fit together?"
Name obvious gaps once, clearly: "One thing worth addressing: [gap]. Intentional or something to work through?"
Push on "it depends" -- get the conditions enumerated rather than leaving them vague
Don't repeatedly challenge the same point. State once, record the user's response, move on.

Recognizing Pivots:

If answers consistently point away from the original idea (the real problem is different, the assumed user is wrong, a simpler solution exists), pause and name it:

"Based on what you've described, it sounds like the core problem might actually be X rather than Y. Should we shift the interview in that direction?"

Don't silently drift. Explicitly acknowledge the pivot so the user can agree or disagree. If they agree, restart progressive synthesis from the new framing. If they disagree, note the alternative framing as an open question.

Question Categories (cycle through as needed):

Category	Focus	Example Non-Obvious Questions
Current State	What exists today	"What workaround exists now?" / "How is this problem currently handled?"
Demand & Wedge	Whether the idea has real pull and a narrow entry point	"What evidence do we already have?" / "Which uncertainty should customer learning resolve next?"
Throughput & Constraint	Whether this should become a constraint diagnosis	"What system is stuck?" / "What symptom makes you suspect a bottleneck?"
Constraints	What limits the solution space	"What's the recovery story if this fails mid-operation?" / "What existing system invariants must we preserve?"
Users & Actors	Who interacts and how	"Who has to clean up when this goes wrong?" / "What's the worst thing a confused user could do here?"
State & Data	What changes and persists	"What happens to in-flight data if this is deployed mid-operation?" / "What's the source of truth when systems disagree?"
Boundaries	Where responsibility ends	"What's explicitly NOT in scope that someone might assume is?" / "At what scale does this approach break down?"
Failure Modes	What breaks and how	"What's the blast radius if the dependency is down for an hour?" / "How do we know this is broken before users tell us?"
Risk & Priority	What matters most	"If this work isn't done, what breaks first?" / "Rank these concerns by impact"
Validation	How to verify	"What's the smallest experiment to test this hypothesis?" / "How would we know this worked?"
Evolution	How it changes over time	"What's the migration path when requirements change?" / "What decision here will be hardest to reverse?"
Integration	How it connects	"What existing workflows does this interrupt or complicate?" / "Who needs to know when this happens?"

Category Coverage Tracker:

Current State
Demand & Wedge
Throughput & Constraint
Constraints
Users & Actors
State & Data
Boundaries
Failure Modes
Risk & Priority
Validation
Evolution
Integration

Not all categories apply -- depth calibration from step 4 determines which matter. For analysis scope, focus on Current State, Constraints, Risk & Priority. For full design, cover all relevant categories. When the interview turns into customer discovery, prototype testing, constraint diagnosis, or PRD writing, switch skills instead of embedding that specialist workflow here.

6. Avoid These Question Patterns

Don't ask what's already stated in the input
Don't ask "what's the goal" if the goal is clear
Don't ask binary yes/no when the interesting answer is "it depends"
Don't ask about implementation details before understanding constraints
Don't confirm assumptions--challenge them

7. Recognize Completion

Stop interviewing when:

Core user journeys are mapped
Error handling and edge cases are addressed (or marked TBD appropriately)
Integration points and dependencies are identified
Success criteria and metrics are defined
Scope boundaries are explicit
All decisions in the decision tree are resolved (decided, deferred, or blocked)

Alternative Completion Signals:

User says "I think that's enough" or "this is helpful"
User's answers become consistently confident (uncertainty resolved)
Conversation is circling without new insights
Enough captured for user's stated purpose (even if spec isn't "complete")

8. Synthesize Before Committing

Before writing final output:

Summarize the full picture, incorporating any corrections from earlier progressive check-ins
Highlight the most important insights and open questions
Confirm this matches their understanding
Ask if anything was missed before committing to artifact

This catches misunderstandings before they're written into permanent artifacts.

9. Determine Output Format

Select based on context:

Condition	Format	Action
User provided a Linear ticket or existing doc	Update existing artifact	Integrate findings, mark new sections with "NEW:" prefix, preserve existing structure
User needs implementation-ready spec	Standalone specification	Use spec template in step 10
Idea is early-stage or exploratory	Summary for discussion	Synthesize key insights, list open questions, skip formal structure
User asked "is this worth building"	Diagnostic memo	Lead with demand evidence, status quo, narrow wedge, risks, and assignment
User is diagnosing a stuck operation, queue, or bottleneck	Constraint interview notes	Summarize system goal, suspected constraint, evidence, local-optimum traps, next measurement, and assignment
User says "this is helpful" / "that's enough"	No output needed	The interview itself achieved the goal

10. Produce the Specification (when appropriate)

For standalone specs, use this structure:

# [Feature/Concept Name] Specification

## Overview
[1-2 paragraph summary of what this is and why it matters]

## Goals & Non-Goals
**Goals:**
- [Explicit objectives]

**Non-Goals:**
- [What this explicitly does NOT do]

## User Stories / Use Cases
[Primary flows with actor, action, outcome]

## Demand Evidence
[Specific behaviors, status quo, and narrowest wedge]

## Technical Design
[Architecture, data flow, key decisions]

## Edge Cases & Error Handling
[What happens when things go wrong]

## Dependencies & Integration Points
[What this touches and relies on]

## Open Questions
[Anything that still needs resolution - including intentional TBDs]

## Success Criteria
[How we know this works]

11. Chain to Next Steps

After producing output, suggest relevant next actions:

Implementation ready? -> "Want me to start building this?" (chains to relevant implementation skills)
Needs broader input? -> "Should I write this up for team review?" (chains to v1-stickify for persuasive framing)
Linear ticket? -> "Want me to create/update the Linear ticket?" (chains to whatever Linear tooling the project has wired up)
PRD needed? -> "Should I expand this into a full PRD?" (chains to v1-prd skill)

Reference Files

examples.md -- Sample interview transcript and quick reference