Plan Interview Skill
Install
CODEBLOCK0
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).
Interview Process
Phase 1: Upfront Interview (Before Exploration)
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.
Required Question Domains
Cover ALL four domains before proceeding:
- 1. Technical Constraints
- Performance requirements
- Compatibility needs
- Existing patterns to follow
- Architecture understanding (if codebase is unfamiliar)
- 2. Scope Boundaries
- What's explicitly OUT of scope
- MVP vs full vision
- Dependencies on other work
- 3. Risk Tolerance
- Acceptable tradeoffs (speed vs quality)
- Tech debt tolerance
- Breaking change acceptance
- 4. Success Criteria
- How will we know it's done?
- What defines "working correctly"?
- Testing/validation requirements
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)
Planning Depth Calibration
Before leaving the interview phase, classify the task and choose a planning depth:
- - Simple/trivial (small bug fix, isolated change): minimal plan, at most 1 refinement pass
- Moderate (feature work in known area): standard plan, usually 1-2 refinement passes
- Complex/high-risk (multi-file, new architecture, unfamiliar codebase, migrations, auth, concurrency): deep plan with iterative refinement until improvements flatten
Let the user override this (fast vs deep) if they have a clear preference.
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
After interview completes, explore the codebase to understand:
- - Existing patterns relevant to the task
- Files that will be affected
- Integration points
- Potential risks
For complex or unfamiliar projects, do a brief context refresh before deep planning:
- - Re-read
AGENTS.md and README.md if present and relevant - Identify the current architecture boundaries and conventions before refining the plan
- If the session was interrupted or context drifted, refresh these again before another refinement round
Phase 3: Plan Generation
Write plan to docs/plans/plan-NNN-<slug>.md where NNN is sequential.
Use a draft -> refine workflow. Stay in plan space while you are still finding material improvements. Planning tokens are usually much cheaper than implementation tokens for non-trivial work.
Draft First, Then Refine
- 1. Create a draft plan from the interview + exploration results.
- Run iterative refinement passes before asking for approval (depth based on task complexity).
- Present the refined plan for user review.
Iterative Plan Refinement Loop (Before User Review)
Run 1..N refinement passes depending on complexity. For each pass:
- 1. Fresh-eyes start (mandatory): Re-read the interview answers, constraints, success criteria, and the current draft plan with "fresh eyes" before revising anything.
- Check for contradictions, missing edge cases, integration risks, and vague implementation steps.
- Improve architecture, sequencing, and reliability where it clearly helps users.
- Strengthen the testing and validation plan (unit + integration/e2e where applicable, plus useful diagnostics/logging).
- Verify feature preservation:
-
Do NOT oversimplify
-
Do NOT remove agreed features or functionality unless the user explicitly approves a scope reduction
- 6. Record a short per-pass summary: what changed and why.
Stop iterating when any of the following is true:
- - Two consecutive passes produce no material improvements
- Changes are only wording/style with no effect on execution quality
- The task is simple and the plan is already actionable
- The user asks to stop and proceed
Optional: Multi-Plan Synthesis ("Best of All Worlds")
If the user provides multiple competing plans (from different models or prior iterations):
- - Compare them honestly against the current plan
- Extract the best ideas, tradeoffs, and risk mitigations
- Merge them into a single canonical plan that preserves agreed scope
- Prefer showing git-diff style changes to the existing plan when the user asks for revision output
Reusable prompt templates for the refinement loop and multi-plan synthesis live in references/iterative-plan-refinement-prompts.md.
Required Elements
Every plan MUST include:
CODEBLOCK1
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
- No silent scope reduction - do not drop agreed features to make the plan "cleaner"
- Don't over-iterate simple work - use the planning depth calibration above
- Freeform structure beyond required elements
Phase 4: Post-Approval
When user approves the plan:
- 1. Auto-start implementation immediately (no "proceed" confirmation needed)
- Populate
TodoWrite with checklist items - At natural breakpoints (significant decisions), compare progress to plan
Fast Mode
If user wants quick planning, use draft + refine:
- 1. Perform task-focused codebase search
- Generate draft plan
- Run abbreviated interview to refine
- Run exactly one fresh-eyes refinement pass (preserve functionality, tighten steps, add test/validation coverage)
Resume Support
If a partial plan exists in docs/plans/:
CODEBLOCK2
If resuming refinement, first summarize the current plan state and the most recent refinement changes, then continue with the fresh-eyes refinement loop.
Example
CODEBLOCK3
计划访谈技能
安装
bash
npx skills add pskoett/pskoett-ai-skills/plan-interview
目的
在规划实施之前,进行结构化的需求访谈。通过收集明确的需求而非做出假设,确保你与用户之间达成一致。
何时调用
用户调用 /plan-interview <任务描述>。
如果任务纯粹是研究/探索(而非实施),则跳过此技能。
访谈流程
阶段1:前置访谈(探索之前)
当提供商支持时,使用 AskUserQuestion 按主题分批(每批2-3个问题) 对用户进行访谈。对于像GitHub Copilot这样没有AskUser工具的提供商,直接在聊天中提出相同的问题,并在继续之前暂停等待回复。
必问问题领域
在继续之前,覆盖所有四个领域:
- 1. 技术约束
- 性能要求
- 兼容性需求
- 需遵循的现有模式
- 架构理解(如果代码库不熟悉)
- 2. 范围边界
- 明确
不在范围内的内容
- MVP与完整愿景
- 对其他工作的依赖
- 3. 风险承受能力
- 可接受的权衡(速度与质量)
- 技术债务容忍度
- 破坏性变更的接受程度
- 4. 成功标准
- 如何知道完成了?
- 什么定义了正确运行?
- 测试/验证要求
问题生成
- - 根据任务动态生成问题——无固定模板
- 将相关问题分组为按主题分批
- 每批2-3个问题(不要超过)
- 持续提问直到获得可操作的具体性(能够描述具体的实施步骤)
规划深度校准
在离开访谈阶段之前,对任务进行分类并选择规划深度:
- - 简单/琐碎(小bug修复、孤立变更):最小化计划,最多1次优化迭代
- 中等(熟悉区域内的功能开发):标准计划,通常1-2次优化迭代
- 复杂/高风险(多文件、新架构、不熟悉的代码库、迁移、认证、并发):深度计划,迭代优化直到改进趋于平稳
如果用户有明确偏好,允许其覆盖此设置(快速 vs 深度)。
处理边缘情况
| 场景 | 操作 |
|---|
| 矛盾的需求 | 提出建议并附上理由,请求确认 |
| 用户改变需求 |
以新方向重新开始访谈 |
| 会话中断 | 询问用户:从中断处继续还是重新开始? |
需避免的反模式
- - 不要问同一问题的不同变体
- 未经询问不要做出重大假设
- 不要为简单任务过度设计计划
阶段2:代码库探索
访谈完成后,探索代码库以了解:
- - 与任务相关的现有模式
- 将受影响的文件
- 集成点
- 潜在风险
对于复杂或不熟悉的项目,在深入规划之前先进行简要的上下文刷新:
- - 重新阅读 AGENTS.md 和 README.md(如果存在且相关)
- 在优化计划之前,识别当前的架构边界和约定
- 如果会话中断或上下文漂移,在另一轮优化之前再次刷新这些内容
阶段3:计划生成
将计划写入 docs/plans/plan-NNN-.md,其中NNN为顺序编号。
使用草稿 -> 优化的工作流程。在仍能发现实质性改进时,保持在计划空间内。对于非琐碎的工作,规划token通常比实施token便宜得多。
先草稿,后优化
- 1. 根据访谈+探索结果创建草稿计划。
- 在请求批准之前,运行迭代优化迭代(深度基于任务复杂度)。
- 提交优化后的计划供用户审查。
迭代计划优化循环(用户审查之前)
根据复杂度运行1..N次优化迭代。每次迭代:
- 1. (必须)以全新视角开始: 在修改任何内容之前,以全新视角重新阅读访谈答案、约束条件、成功标准和当前草稿计划。
- 检查矛盾、遗漏的边缘情况、集成风险和模糊的实施步骤。
- 在明确对用户有帮助的地方改进架构、顺序和可靠性。
- 加强测试和验证计划(单元测试+集成测试/端到端测试(如适用),以及有用的诊断/日志记录)。
- 验证功能保留:
-
不要过度简化
-
不要删除已商定的功能或特性,除非用户明确批准范围缩减
- 6. 记录每次迭代的简短摘要:更改了什么以及原因。
当以下任一条件成立时停止迭代:
- - 连续两次迭代未产生实质性改进
- 更改仅为措辞/风格,对执行质量无影响
- 任务简单且计划已可操作
- 用户要求停止并继续
可选:多计划综合(集各家所长)
如果用户提供了多个竞争性计划(来自不同模型或之前的迭代):
- - 诚实地将其与当前计划进行比较
- 提取最佳想法、权衡和风险缓解措施
- 将它们合并为一个保留商定范围的规范计划
- 当用户要求修订输出时,优先展示对现有计划的git-diff风格更改
优化循环和多计划综合的可重用提示模板位于 references/iterative-plan-refinement-prompts.md。
必需元素
每个计划必须包含:
markdown
成功标准
[来自访谈的明确的完成定义]
风险评估
[可能出错的地方 + 缓解措施]
受影响的文件/区域
[将触及代码库的哪些部分]
测试策略
[单元测试、集成测试和端到端测试/脚本(如适用);包括关键场景、失败模式和测试夹具/模拟]
验证与诊断
[实施后如何验证功能是否正常工作;在测试/脚本中包含详细的日志记录/诊断预期,以便于调试]
未解决问题
[实施过程中需要解决的不确定事项]
- - [ ] 问题1 - [阻碍实施 / 可以继续]
- [ ] 问题2 - [阻碍实施 / 可以继续]
实施清单
...
可选元素
在相关时包含:
- - 被拒绝的备选方案:仅针对重大架构决策
- 决策树:仅当存在多个有效方法时
- 可视化图表:当有助于理解时使用ASCII或Mermaid图表
约束条件
- - 无时间估算 - 描述需要做什么,而非需要多长时间
- 无长度限制 - 计划应与任务复杂度匹配
- 无静默范围缩减 - 不要为了更干净的计划而删除已商定的功能
- 不要过度迭代简单工作 - 使用上述的规划深度校准
- 除必需元素外,结构自由
阶段4:批准后
当用户批准计划时:
- 1. 立即自动开始实施(无需继续确认)
- 使用清单项填充 TodoWrite
- 在自然断点(重大决策)处,将进度与计划进行比较
快速模式
如果用户希望快速规划,使用草稿 + 优化:
- 1. 执行以任务为中心的代码库搜索
- 生成草稿计划
- 运行简化的访谈以优化
- 精确运行一次全新视角优化迭代(保留功能、收紧步骤、增加测试/验证覆盖)
恢复支持
如果 docs/plans/ 中存在部分计划:
AskUserQuestion: 我找到了一个现有的部分计划。您想要:
- - 继续访谈
- 恢复计划起草/优化
- 审查当前计划并定稿
- 用新计划重新开始
如果恢复优化,首先总结当前计划状态和最近的优化更改,然后继续使用全新视角优化循环。
示例
用户: /plan-interview 为API添加OAuth认证
Claude: 我将帮助您规划OAuth认证功能。让我先收集需求。
[AskUserQuestion - 范围批次]
- 1. 需要支持哪些OAuth提供商(Google、GitHub等)?
- 这是替换现有认证还是在其基础上添加?
[Copilot指导:在聊天中提出相同的两个问题并等待回复]
用户: Google和GitHub。在现有JWT认证基础上添加。
[AskUserQuestion - 技术批次]
- 1. OAuth令牌应存储在现有会话表中还是单独存储?
- 您的托管设置是否有特定的回调URL约束?
用户: 单独存储。我们使用Vercel,因此回调URL需要按环境配置。
[AskUserQuestion - 风险/成功批次]
- 1. 如果OAuth提供商宕机,可接受的降级方案是什么?
- 对于已存在相同邮箱的用户,应如何处理?
用户: 回退到标准登录。如果用户确认,通过邮箱关联账户。
Claude: [探索代码库中的认证模式、会话处理、数据库架构]
Claude: [编写 docs/plans/plan-003-oauth-authentication.md]
计划已创建。主要