galihcitta/dotclaudeskills/interviewing-plans

Interviewing Plans

Overview

Plans fail because of hidden assumptions, not missing features. This skill systematically interviews stakeholders to surface ambiguities before they become bugs.

Core principle: Every vague term is a bug waiting to happen. "Make it faster" means nothing until someone says "reduce P95 latency from 800ms to 200ms."

When to Use

Trigger conditions:

• User invokes /interview-plan <file>
• Plan contains undefined qualitative terms ("better", "faster", "modern", "relevant")
• Requirements reference external artifacts without links ("design has mockups")
• Technical approach lacks specifics ("add caching", "use React")
• Timeline exists without milestone breakdown
• User complaints mentioned without specific pain points

Do NOT use for:

• Already-detailed specs with concrete acceptance criteria
• Simple bug fixes with clear reproduction steps
• Tasks where user explicitly wants implementation, not planning

Required Categories

Interview is NOT complete until ALL categories are covered:

Interview Protocol

1. Read and Analyze

Read the plan file. For each section, identify:

• Undefined terms: Words that mean different things to different people
• Missing specifics: Numbers, formats, thresholds not specified
• Assumed context: References to things not in the document
• Hidden dependencies: Things that must be true for the plan to work

2. Ask in Batches by Topic

Use AskUserQuestion with 2-4 related questions per batch. Group by category.

Before each batch, state your reasoning:

I notice the plan says "[quote]" but doesn't specify [gap].
This matters because [consequence if undefined].

3. Challenge Vague Answers

When user gives a deflecting or vague answer:

Never accept:

• Qualitative terms without quantitative definitions
• Future tense without owners and dates
• References to artifacts without links or locations
• "Someone" instead of a specific name/team

4. Probe for Non-Obvious Gaps

Obvious questions (avoid these as primary questions):

• "What are the requirements?"
• "What's the timeline?"
• "Who's the user?"

Non-obvious questions (these surface real gaps):

• "What happens to in-flight requests during deployment?"
• "If this succeeds beyond expectations, what breaks first?"
• "What's the most expensive assumption we're making?"
• "Which part of this plan are you least confident about?"
• "What would make you cancel this project tomorrow?"
• "Who will be upset when this ships, and why?"
• "What's the first thing users will try that we haven't designed for?"

5. Track Coverage

Maintain mental checklist. After each batch, assess:

• [ ] Technical architecture clear?
• [ ] UX states defined?
• [ ] Tradeoffs explicit?
• [ ] Edge cases identified?
• [ ] Security considered?
• [ ] Testing strategy exists?
• [ ] Rollback plan defined?
• [ ] Dependencies confirmed?

Handling Time Pressure

When stakeholder is impatient:

Compress, don't skip. Combine remaining categories into 1-2 dense batches. Never skip a category entirely.

Make risk explicit. If they insist on skipping: "I'll document [Security: TBD, Owner: @you] in the spec. You're accepting this risk."

Name the tradeoff. "5 more minutes now, or 2 days of rework when we discover [gap] in production. Your call."

Never rationalize:

• "They know their business" - They don't know what they haven't thought about
• "I can figure it out" - Your assumptions are bugs waiting to happen
• "They seem confident" - Confidence is not evidence of completeness
• "I'm being annoying" - Surfacing gaps IS the job

Completion Criteria

Interview is complete when:

1. All vague terms operationalized - Every qualitative word has a number or concrete definition
2. All categories covered - Checklist above is complete
3. No deflections remaining - All "we'll figure it out" answers have been challenged and resolved
4. Dependencies confirmed - External people/teams/artifacts are named and accessible
5. You cannot find more gaps - Genuinely exhausted questioning, not just tired of asking

Output Format

When interview is complete, write structured spec:

# [Project Name] - Implementation Spec
 
## Overview
[1-2 sentences: what this is and why it matters]
 
## Success Criteria
-[ ] [Measurable criterion with number]
-[ ] [Measurable criterion with number]
 
## Technical Decisions
| Decision | Choice | Rationale |
|----------|--------|-----------|
| [Area] | [What we're doing] | [Why, including rejected alternatives] |
 
## User Experience
### Happy Path
[Step by step flow]
 
### Edge Cases
| Scenario | Behavior |
|----------|----------|
| [Case] | [What happens] |
 
### Error States
| Error | User Sees | Recovery |
|-------|-----------|----------|
| [Type] | [Message/UI] | [How to fix] |
 
## Security Considerations
-[Item with mitigation]
 
## Testing Strategy
-**Unit**: [What's covered]
-**Integration**: [What's covered]
-**E2E**: [Critical paths]
 
## Rollback Plan
[How we undo this if it fails]
 
## Open Questions
-[ ] [Anything still unresolved, with owner]
 
## Dependencies
| Dependency | Owner | Status |
|------------|-------|--------|
| [Thing] | [Person/team] | [Confirmed/Pending/Blocked] |

Red Flags - Dig Deeper

When you hear these, the interview is NOT done:

• "That's a good question, we should think about that"
• "I'm not sure, but probably..."
• "The other team handles that"
• "We've always done it this way"
• "That won't happen" (about edge cases)
• "We'll add that later"
• "It's just like [other project]" (without specifics)

Common Mistakes