plan-interview

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan Interview Skill

规划访谈技能

Purpose

目标

Run a structured requirements interview before planning implementation. This ensures alignment between you and the user by gathering explicit requirements rather than making assumptions.

在规划实现前开展结构化需求访谈。通过收集明确的需求而非主观假设，确保你与用户保持目标一致。

When Invoked

触发时机

User calls

/plan-interview <task description>

Skip this skill if the task is purely research/exploration (not implementation).

用户调用

/plan-interview <任务描述>

时触发。

如果任务仅为研究/探索（非开发类任务），跳过此技能。

Interview Process

访谈流程

Phase 1: Upfront Interview (Before Exploration)

阶段1：前置访谈（探索前）

Interview the user using

AskUserQuestion

in thematic batches of 2-3 questions when the provider supports it. For providers like GitHub Copilot without an AskUser tool, ask the same questions directly in chat and pause for responses before continuing.

当平台支持时，以2-3个问题为主题批次，使用

AskUserQuestion

向用户提问。对于GitHub Copilot等无AskUser工具的平台，直接在聊天中提出相同问题，并等待用户回复后再继续。

Required Question Domains

必填问题领域

Cover ALL four domains before proceeding:

Technical Constraints
- Performance requirements
- Compatibility needs
- Existing patterns to follow
- Architecture understanding (if codebase is unfamiliar)
Scope Boundaries
- What's explicitly OUT of scope
- MVP vs full vision
- Dependencies on other work
Risk Tolerance
- Acceptable tradeoffs (speed vs quality)
- Tech debt tolerance
- Breaking change acceptance
Success Criteria
- How will we know it's done?
- What defines "working correctly"?
- Testing/validation requirements

在推进前必须覆盖以下全部四个领域：

技术约束
- 性能要求
- 兼容性需求
- 需遵循的现有模式
- 架构理解（若代码库不熟悉）
范围边界
- 明确排除在范围外的内容
- 最小可行产品（MVP）与完整愿景的差异
- 对其他工作的依赖关系
风险容忍度
- 可接受的权衡方案（速度vs质量）
- 技术债务容忍度
- 是否接受破坏性变更
成功标准
- 如何判断任务完成？
- 怎样定义“功能正常”？
- 测试/验证要求

Question Generation

问题生成规则

Generate questions dynamically based on the task - no fixed template
Group related questions into thematic batches
2-3 questions per batch (do not exceed)
Continue until you have actionable specificity (can describe concrete implementation steps)

根据任务动态生成问题，无固定模板
将相关问题分组为主题批次
每批次2-3个问题（请勿超出）
持续提问直到获得可落地的明确信息（能够描述具体开发步骤）

Handling Edge Cases

边缘场景处理

Scenario	Action
Contradictory requirements	Make a recommendation with rationale, ask for confirmation
User pivots requirements	Restart interview fresh with new direction
Interrupted session	Ask user: continue where we left off or restart?

场景	操作
需求矛盾	给出带理由的建议，并请求用户确认
用户变更需求	针对新方向重新启动访谈
会话中断	询问用户：是从中断处继续还是重新开始？

Anti-Patterns to Avoid

需避免的反模式

Do NOT ask variations of the same question
Do NOT make major assumptions without asking
Do NOT over-engineer plans for simple tasks

请勿重复提问同类问题
请勿在未询问的情况下做出重大假设
请勿为简单任务过度设计规划

Phase 2: Codebase Exploration

阶段2：代码库探索

After interview completes, explore the codebase to understand:

Existing patterns relevant to the task
Files that will be affected
Integration points
Potential risks

访谈完成后，探索代码库以了解：

与任务相关的现有模式
会受影响的文件
集成点
潜在风险

Phase 3: Plan Generation

阶段3：生成规划

Write plan to

docs/plans/plan-NNN-<slug>.md

where NNN is sequential.

将规划写入

docs/plans/plan-NNN-<slug>.md

，其中NNN为序号。

Required Elements

必填内容

Every plan MUST include:

markdown

undefined

每份规划必须包含以下部分：

markdown

undefined

Success Criteria

[Clear definition of done from interview]

Risk Assessment

[What could go wrong + mitigations]

Affected Files/Areas

[Which parts of codebase will be touched]

Open Questions

[Uncertainties to resolve during implementation]

Question 1 - [Blocks implementation / Can proceed]
Question 2 - [Blocks implementation / Can proceed]

[Uncertainties to resolve during implementation]

Question 1 - [Blocks implementation / Can proceed]
Question 2 - [Blocks implementation / Can proceed]

Implementation Checklist

Step 1
Step 2 ...

undefined

Step 1
Step 2 ...

undefined

Optional Elements

可选内容

Include when relevant:

Rejected Alternatives: Only for major architectural decisions
Decision Tree: Only when multiple valid approaches exist
Visual Diagrams: ASCII or Mermaid when helpful for understanding

Constraints

约束条件

No time estimates - describe what needs doing, not how long
No length limits - plan should match task complexity
Freeform structure beyond required elements

不提供时间估算：描述需要完成的内容，而非所需时长
无长度限制：规划应与任务复杂度匹配
除必填内容外，结构可自由调整

Phase 4: Post-Approval

阶段4：审批后操作

When user approves the plan:

Auto-start implementation immediately (no "proceed" confirmation needed)
Populate
```
TodoWrite
```
with checklist items
At natural breakpoints (significant decisions), compare progress to plan

当用户批准规划后：

立即自动启动开发（无需等待“继续”确认）
将检查项导入
```
TodoWrite
```
在自然断点（重大决策节点）处，对比进度与规划的一致性

Fast Mode

快速模式

If user wants quick planning, use draft + refine:

Perform task-focused codebase search
Generate draft plan
Run abbreviated interview to refine

如果用户需要快速规划，使用草稿+优化流程：

针对任务进行代码库搜索
生成规划草稿
通过简化访谈优化规划

Resume Support

续会话支持

If a partial plan exists in

docs/plans/

AskUserQuestion: "I found an existing partial plan. Would you like to:"
- "Continue from where we left off"
- "Start fresh with a new plan"

如果

docs/plans/

中存在未完成的规划：

AskUserQuestion: "I found an existing partial plan. Would you like to:"
- "Continue from where we left off"
- "Start fresh with a new plan"

Example

示例

User: /plan-interview Add OAuth authentication to the API

Claude: I'll help you plan the OAuth authentication feature. Let me gather
        requirements first.

[AskUserQuestion - Scope batch]
1. Which OAuth providers need to be supported (Google, GitHub, etc.)?
2. Is this replacing existing auth or adding alongside it?

[Copilot guidance: ask the same two questions in chat and wait for responses]

User: Google and GitHub. Adding alongside existing JWT auth.

[AskUserQuestion - Technical batch]
1. Should OAuth tokens be stored in the existing session table or separately?
2. Any specific callback URL constraints from your hosting setup?

User: Separate table. We're on Vercel so callback URLs need to be configured per environment.

[AskUserQuestion - Risk/Success batch]
1. What's the acceptable degradation if an OAuth provider is down?
2. How should we handle users who already exist with the same email?

User: Fall back to standard login. Link accounts by email if user confirms.

Claude: [Explores codebase for auth patterns, session handling, database schema]

Claude: [Writes docs/plans/plan-003-oauth-authentication.md]

        Plan created. The main decision point is whether to use Passport.js
        or implement OAuth flows directly - I've documented both approaches
        with tradeoffs. Ready to review?

User: Looks good, go with Passport.js

Claude: [Auto-starts implementation with TodoWrite tracking]

User: /plan-interview Add OAuth authentication to the API

Claude: I'll help you plan the OAuth authentication feature. Let me gather
        requirements first.

[AskUserQuestion - Scope batch]
1. Which OAuth providers need to be supported (Google, GitHub, etc.)?
2. Is this replacing existing auth or adding alongside it?

[Copilot guidance: ask the same two questions in chat and wait for responses]

User: Google and GitHub. Adding alongside existing JWT auth.

[AskUserQuestion - Technical batch]
1. Should OAuth tokens be stored in the existing session table or separately?
2. Any specific callback URL constraints from your hosting setup?

User: Separate table. We're on Vercel so callback URLs need to be configured per environment.

[AskUserQuestion - Risk/Success batch]
1. What's the acceptable degradation if an OAuth provider is down?
2. How should we handle users who already exist with the same email?

User: Fall back to standard login. Link accounts by email if user confirms.

Claude: [Explores codebase for auth patterns, session handling, database schema]

Claude: [Writes docs/plans/plan-003-oauth-authentication.md]

        Plan created. The main decision point is whether to use Passport.js
        or implement OAuth flows directly - I've documented both approaches
        with tradeoffs. Ready to review?

User: Looks good, go with Passport.js

Claude: [Auto-starts implementation with TodoWrite tracking]