Back to Details

spec-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
<!-- Original "grill me" concept by Matt Pocock (https://x.com/maaboroshi) -->
<!-- Original "grill me" concept by Matt Pocock (https://x.com/maaboroshi) -->

spec-plan

spec-plan

Interview the user relentlessly about every aspect of a plan until reaching shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one.
针对用户方案的各个方面进行全面质询，直至达成共识。逐一梳理设计树的每个分支，逐个解决决策之间的依赖关系。

When to Use

使用场景

  • User wants to stress-test a plan or design
  • User says "grill me" or "poke holes in this"
  • Before running 
    build-prd
    — spec-plan resolves ambiguity, build-prd structures the output
  • Complex feature with many interacting decisions that need to be resolved sequentially
  • 用户希望对方案或设计进行压力测试
  • 用户提出“对我进行质询”或“找出这个方案的漏洞”
  • 在执行
    build-prd
    之前——spec-plan用于消除歧义，build-prd用于整理输出内容
  • 包含多个相互关联决策、需要逐一解决的复杂功能

When NOT to Use

不适用场景

  • Requirements are already clear and documented — go straight to 
    build-prd
  • User just wants a quick opinion, not a deep interview
  • Implementation is already underway
  • 需求已明确且有文档记录——直接使用
    build-prd
    即可
  • 用户仅需要快速意见，而非深度质询
  • 开发工作已在进行中

Workflow

工作流程

1. Read existing context

1. 读取现有上下文

If the plan originates from a GitHub issue:
bash
gh issue view ISSUE_NUMBER --repo ORG/REPO --json body,title,comments
Read all comments too — treat existing questions and answers as already-resolved branches. Do not re-ask anything already answered.
If no issue, read project context:
bash
cat project-instructions.md  # or equivalent project instructions file
cat README.md
如果方案源自GitHub Issue：
bash
gh issue view ISSUE_NUMBER --repo ORG/REPO --json body,title,comments
同时阅读所有评论——将已有的问题和答案视为已解决的分支，不要重复询问已解答的内容。
如果没有Issue，则读取项目上下文：
bash
cat project-instructions.md  # 或其他等效的项目说明文件
cat README.md

2. Interview — one question at a time

2. 质询——一次一个问题

For each branch of the design tree:
  • Ask one question
  • Provide your recommended answer with reasoning
  • Wait for the user's response
  • Incorporate the answer and move to the next branch
Warning: ONE question at a time. This is not build-prd's batched Q1-Qn format. Go deep on each branch before moving to the next.
If a question can be answered by exploring the codebase, explore the codebase instead of asking.
针对设计树的每个分支：
  • 提出一个问题
  • 给出你的推荐答案及理由
  • 等待用户回复
  • 结合回复内容，进入下一个分支
注意： 一次只提一个问题。这不同于build-prd的批量Q1-Qn格式。在进入下一个分支前，要深入挖掘当前分支的所有细节。
如果问题可以通过查阅代码库得到答案，则直接查阅代码库，而非询问用户。

3. Resolve dependencies

3. 解决依赖关系

When decisions depend on each other, resolve the dependency first:
  • Identify which decision blocks others
  • Ask about the blocker first
  • Then proceed to the dependent decisions
当决策之间存在依赖时，先解决依赖问题：
  • 确定哪个决策会阻碍其他决策
  • 先询问阻碍性的决策相关问题
  • 再处理依赖于该决策的其他问题

4. Handoff to build-prd (optional)

4. 移交至build-prd（可选）

When all branches are resolved, offer:
text
All branches resolved. Want me to run /build-prd to structure this into a PRD?
If yes, the shared understanding from this interview becomes the input — build-prd can skip its discussion phase (Steps 1-3) and go straight to drafting.
当所有分支都梳理完成后，可向用户提议：
text
所有分支已梳理完成。是否需要我执行/build-prd将内容整理成PRD？
如果用户同意，本次质询达成的共识将作为输入——build-prd可以跳过其讨论阶段（步骤1-3），直接进入起草环节。

Critical Rules

核心规则

  • One question at a time — depth over breadth
  • Always provide your recommended answer — don't just ask, propose
  • Never re-ask resolved questions — read issue comments first
  • Explore code before asking — if the codebase has the answer, use it
  • Start from where the conversation left off — respect prior discussion
  • 一次一个问题——深度优先，而非广度优先
  • 始终给出推荐答案——不要只提问，要提出建议
  • 绝不重复询问已解决的问题——先阅读Issue评论
  • 先查代码再提问——如果代码库中有答案，直接使用
  • 从对话中断处继续——尊重之前的讨论内容