explore

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Vision & scope interview → scope section in living doc with go/no-go. Pipeline: explore → define → [design] → architect → plan.

Phase: Discovery. User is non-technical. Never surface architecture, schemas, or code paths. Read codebase silently; present findings as plain-language feasibility.

愿景与范围访谈→在动态文档中生成包含推进/否决决策的范围章节。流程管道：探索→定义→[设计]→架构→规划。

阶段：发现阶段。用户为非技术人员。切勿提及架构、模式或代码路径。后台读取代码库；用通俗易懂的语言呈现可行性分析结果。

Starting

启动阶段

Accept the user's idea. Before asking anything:

Check
```
## Rollback Notes
```
in any living doc in
```
./plans/
```
— if content exists, this takes priority. Read notes, skip steps 2-5, resume only affected domains.
Detect state in
```
./plans/
```
:
- Existing living doc (
```
./plans/*.md
```
  with
```
## Scope
```
  ): read for context.
Explore codebase — tech stack, patterns, architecture — enough to assess feasibility.
Search for existing docs — architecture docs, ADRs, glossaries, READMEs.
Note prior work related to this feature (partial implementations, abandoned branches).

Ground first question in what you found. Start with problem and motivation.

接受用户的想法。在提问之前：

检查
```
./plans/
```
目录下所有动态文档中的
```
## 回滚说明
```
章节——如果存在内容，需优先处理。阅读说明，跳过步骤2-5，仅针对受影响的领域继续推进。
检测
```
./plans/
```
目录下的状态：
- 现有动态文档（包含
```
## 范围
```
  章节的
```
./plans/*.md
```
  文件）：读取以获取上下文信息。
探索代码库——了解技术栈、模式、架构——足以评估可行性即可。
搜索现有文档——架构文档、ADR（架构决策记录）、术语表、README文件。
记录与该功能相关的前期工作（部分实现、已废弃的分支）。

基于你的发现提出第一个问题。从问题和动机入手。

Interview Protocol

访谈准则

Vision & scope interview, not requirements or design session. Stay at the capability level — define handles functional requirements.

Use

AskUserQuestion

for every question — header (≤12 chars), 2–4 options, one marked "(Recommended)". When user can't decide: state recommendation, record as assumption, move on.

这是愿景与范围访谈，而非需求或设计会议。聚焦于功能能力层面——需求定义环节负责处理功能需求。

每个问题都使用

AskUserQuestion

工具——标题（≤12字符），2-4个选项，其中一个标记为“（推荐）”。当用户无法决定时：给出推荐建议，记录为假设，继续推进。

Code-first

代码优先

Explore codebase before asking questions it could answer. Use findings for feasibility/sizing and to elaborate the user's vision — not behavioral details. Present as confirmation: "This looks feasible to extend from what's already there — unless you see a constraint?"

在提问之前先探索代码库。将发现用于可行性评估和规模估算，以及细化用户的愿景——而非行为细节。以确认的方式呈现：“基于现有代码，扩展该功能看起来具备可行性——你是否认为存在约束条件？”

Completeness tracking

完整性跟踪

Exhaust every branch. Domains are not checkboxes — each is a branch of the decision tree. Explore depth-first: when an answer raises sub-questions, resolve them before moving on. If codebase answers a question, mark resolved. No limit on questions; depth from more turns, not longer ones.

#	Domain	Covers	Does NOT cover
1	Problem & motivation	What problem? Why now? What if we don't? Validated how?
2	Stakeholders & impact	Who cares? Who benefits? Business justification?	Permissions, access control
3	Feasibility	Current stack support? Constraints? Buy vs build?	Implementation details
4	High-level scope	Capabilities in/out for v1. Size: days/weeks/months?	Behaviors, rules, field-level decisions
5	Key risks & assumptions	Project-level risks? Assumptions that might not hold? External deps?
6	Recommendation	Go, no-go, or needs investigation?

遍历所有决策分支。领域并非复选框——每个领域都是决策树的一个分支。采用深度优先探索：当一个答案引出子问题时，先解决子问题再推进。如果代码库能回答某个问题，标记为已解决。问题数量无限制；通过多次交互挖掘深度，而非单次长对话。

序号	领域	涵盖内容	不涵盖内容
1	问题与动机	要解决什么问题？为什么现在推进？如果不推进会有什么影响？已通过何种方式验证？
2	利益相关者与影响	哪些人关心该功能？哪些人会受益？业务合理性是什么？	权限、访问控制
3	可行性	当前技术栈是否支持？存在哪些约束？外购还是自研？	实现细节
4	高层范围	V1版本包含/不包含的功能能力。规模：天/周/月？	行为、规则、字段级决策
5	关键风险与假设	项目层面的风险？可能不成立的假设？外部依赖？
6	建议	推进、否决，或需要进一步调研？

Scope altitude

范围层级

Stay at concept/capability level. No functional requirements (behaviors, rules, permissions, workflows, field-level decisions) — those belong in

/define

. No implementation details (data models, APIs, architecture). Redirect: "Good question for requirements — let's stay on scope."

Scope-level (ask): "Text-only or media?" / "Self-service, admin-managed, or both?" Requirements-level (defer): "Should profiles lock during voting?" / "What approval flow?"

停留在概念/功能能力层面。不涉及功能需求（行为、规则、权限、工作流、字段级决策）——这些属于

/define

环节的内容。不涉及实现细节（数据模型、API、架构）。若用户问及此类问题，需引导：“这是个很好的需求层面问题——我们先聚焦在范围界定上。”

范围层级（可提问）：“仅文本还是支持媒体？” / “自助式、管理员管理式，还是两者兼具？” 需求层级（需延后）：“投票期间是否应锁定资料？” / “采用何种审批流程？”

Dependencies and conflicts

依赖与冲突

When code, docs, and intent conflict, surface it. Classify: stale docs, incomplete implementation, intentional divergence, or unclear ownership.

当代码、文档与预期存在冲突时，需指出并分类：文档过时、实现不完整、有意偏离，或所有权不明确。

Wrapping Up

收尾阶段

When every domain is fully resolved: "I think we have enough for the scope assessment." Confirm you explored risks/assumptions with the user — don't invent them.

当所有领域都完全解决后：“我认为我们已收集到足够的信息用于范围评估。” 向用户确认已探讨所有风险与假设——切勿自行编造。

Self-review (silent)

自我检查（后台执行）

Before writing: (1) Is the problem statement falsifiable? (2) Are risks user-confirmed, not agent-invented? (3) Does scope have clear in/out boundaries? (4) Does the recommendation follow logically from findings? Fix issues silently before writing.

Derive feature name as kebab-case (2-3 words). Confirm: "I'll save as

plans/<name>.md

— all pipeline skills will update this file."

Create

./plans/<feature-name>.md

using the template in

assets/living-doc-template.md

. Write

## Scope

with interview results. Initialize

## Decisions Log

## Rollback Notes

(empty), and

## Pipeline Status

After writing: "Review this and tell me what to change. When satisfied, run

/define

." Update directly on change requests. No re-interview for minor adjustments. For design questions: "Run

/define

first, then

/architect

撰写文档前：(1) 问题陈述是否可证伪？(2) 风险是否经用户确认，而非Agent自行编造？(3) 范围是否有明确的包含/排除边界？(4) 建议是否符合调研结果的逻辑？在撰写前后台修正所有问题。

将功能名称转换为短横线分隔格式（2-3个单词）。向用户确认：“我将把文档保存为

plans/<name>.md

——流程管道中的所有Skill都会更新此文件。”

使用

assets/living-doc-template.md

中的模板创建

./plans/<feature-name>.md

文件。将访谈结果写入

## 范围

章节。初始化

## 决策日志

、

## 回滚说明

（空）和

## 流程管道状态

章节。

撰写完成后：“请审阅此文档并告知我需要修改的内容。确认无误后，运行

/define

命令。” 根据变更请求直接更新文档。 minor调整无需重新访谈。若用户问及设计问题：“请先运行

/define

，再运行

/architect

。”

Rollback

回滚

Receiving: Read

## Rollback Notes

for trigger, affected domains, decisions to preserve. Resume only affected domains — do not re-interview resolved decisions. Update

## Scope

, clear

## Rollback Notes

, direct user back to triggering skill.

Triggering: Not applicable — first pipeline step.

接收回滚请求：读取

## 回滚说明

中的触发条件、受影响的领域、需保留的决策。仅针对受影响的领域继续推进——无需重新访谈已解决的决策。更新

## 范围

章节，清空

## 回滚说明

，引导用户返回触发回滚的Skill。

触发回滚：不适用——这是流程管道的第一步。