drill

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

First, size the ask. If it has no real decision tree (one obvious change, a small diff, a criterion statable in one sentence), say so and route straight to

implement

with that sentence as the plan; a spec for an obvious change is ceremony. The fast path still drills its sentence: state it, then test it. A sentence that cannot be stated, or that surfaces a fork or a second decision, was not obvious: run the interview. A genuine fork discovered mid-task is never guessed: stop, name it, let the user answer or switch to deep. If

verify

fails twice on a task judged obvious, the task was lying about its size: stop and drill it properly.

Deep mode (the

deep

skill is active): no sizing, no routing past the interview; the full session runs and the spec is always written.

Run the

core-interview

skill against the plan or design under discussion.

Shape of the session:

Explore the project context before the first question: code, docs, recent commits.
If the ask bundles several independent pieces, say so and drill the first piece; the rest queue up.
Before settling a direction, put 2 or 3 genuinely different approaches on the table with trade-offs, leading with a recommendation. When a fork turns on look, feel, or flow that prose can't settle, build a throwaway mockup with fake data to react to instead, and discard it once the direction is picked.
Cut ruthlessly: anything the stated constraints don't demand leaves the design.

首先，评估需求规模。如果需求没有真正的决策树（仅需一个明显的改动、一处小差异、能用一句话表述的标准），则直接说明情况，并将该句子作为计划导向

implement

环节；针对明显改动的规格说明属于冗余流程。快速路径仍需对该句子进行追问：先明确表述，再进行验证。若无法用一句话表述，或是出现分支或二次决策，则说明需求并不明确：此时需启动访谈。在任务进行中发现的真实分支绝不能猜测：应暂停，明确指出该分支，让用户作答或切换至深度模式。如果针对被判定为明确的任务，

verify

环节连续两次失败，则说明该任务的规模判断有误：需暂停并正式开展追问。

深度模式（

deep

技能激活）：无需评估规模，访谈环节后不进行其他路由；全程执行完整会话并始终编写规格说明。

针对讨论中的计划或设计，调用

core-interview

技能。

会话流程：

在提出第一个问题前，先探索项目背景：代码、文档、近期提交记录。
如果需求包含多个独立部分，需明确说明并先深入探讨第一部分；其余部分排入队列。
在确定方向前，提出2到3种真正不同的方案并说明权衡利弊，同时给出推荐方案。当分支涉及外观、触感或流程等无法用文字确定的内容时，可使用虚假数据构建一次性原型供用户反馈，确定方向后即可丢弃该原型。
严格筛选：任何不符合既定约束的内容都需从设计中剔除。

Domain awareness

领域感知

The interview also challenges the plan against the project's existing domain model. During exploration, look for existing documentation:

```
CONTEXT.md
```
at the root (or
```
CONTEXT-MAP.md
```
+ per-context
```
CONTEXT.md
```
files in a multi-context repo)
ADRs in
```
docs/adr/
```
(and any context-scoped
```
docs/adr/
```
directories)

Create files lazily: only when you have something to write. If no

CONTEXT.md

exists, create one when the first term is resolved. If no

docs/adr/

exists, create it when the first ADR is needed.

First contact. When no

CONTEXT.md

exists and the codebase is nontrivial, offer a one-time seeding pass: distill candidate terms from the code and any existing docs, then confirm each through the interview. Only confirmed terms enter the glossary; a term nobody vouched for is not written.

During the session:

Challenge against the glossary. When the user uses a term that conflicts with the existing language in
```
CONTEXT.md
```
, call it out immediately. "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
Sharpen fuzzy language. When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account'. Do you mean the Customer or the User? Those are different things."
Discuss concrete scenarios. When domain relationships are being discussed, stress-test them with specific scenarios that probe edge cases and force precision about the boundaries between concepts.
Cross-reference with code. When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
Update
CONTEXT.md
inline. When a term is resolved, update
```
CONTEXT.md
```
right there; don't batch. It is a glossary and nothing else: not a spec, not a scratchpad, not a home for implementation decisions. Format: CONTEXT-FORMAT.md.
Offer ADRs sparingly. Only offer an ADR when all three are true: hard to reverse, surprising without context, the result of a real trade-off. If any is missing, skip it. Format: ADR-FORMAT.md.

The session ends when every branch of the decision tree is resolved: state the settled design in a short summary and get explicit agreement before any implementation starts.

When the settled design is implementation work, write the spec to

docs/specs/<slug>.md

in the target project using SPEC-FORMAT.md: goal, non-goals, checkable acceptance criteria, verification commands. The spec steers the loop:

implement

builds from it,

verify

gates against it,

land

closes it out and asks whether to keep or delete the file.

访谈过程中还需结合项目现有领域模型对计划进行验证。探索阶段需查找现有文档：

根目录下的
```
CONTEXT.md
```
（或多上下文仓库中的
```
CONTEXT-MAP.md
```
+ 各上下文对应的
```
CONTEXT.md
```
文件）
```
docs/adr/
```
目录下的ADR（以及任何上下文专属的
```
docs/adr/
```
目录）

按需创建文件：仅当有内容可写时才创建。如果不存在

CONTEXT.md

，则在第一个术语明确后创建该文件。如果不存在

docs/adr/

目录，则在需要创建首个ADR时创建该目录。

首次接触。当不存在

CONTEXT.md

且代码库较为复杂时，可提供一次性初始化服务：从代码和现有文档中提取候选术语，然后通过访谈逐一确认。只有经过确认的术语才能加入术语表；无人认可的术语不得写入。

会话期间：

对照术语表验证。当用户使用的术语与
```
CONTEXT.md
```
中的现有术语冲突时，需立即指出：“你的术语表将‘cancellation’定义为X，但你此处似乎指的是Y。以哪个为准？”
明确模糊表述。当用户使用模糊或多义术语时，建议使用精确的标准术语：“你提到了‘account’。你指的是Customer还是User？这两者是不同的概念。”
讨论具体场景。当讨论领域关系时，需通过特定场景进行压力测试，探查边缘情况，明确概念间的边界。
与代码交叉验证。当用户说明某功能的工作方式时，需检查代码是否一致。若发现矛盾，需指出：“你的代码会取消整个Orders，但你刚才说支持部分取消。哪个是正确的？”
实时更新
CONTEXT.md
。当术语明确后，立即更新
```
CONTEXT.md
```
；不得批量处理。该文件仅作为术语表，不用于存储规格说明、草稿或实现决策。格式参考：CONTEXT-FORMAT.md。
谨慎创建ADR。仅当满足以下三个条件时才创建ADR：难以撤销、无背景信息时会令人困惑、是真实权衡后的结果。若缺少任一条件，则无需创建。格式参考：ADR-FORMAT.md。

当决策树的每个分支都理清后，会话结束：用简短总结说明已确定的设计，并在开始任何实现工作前获得用户的明确认可。

当已确定的设计涉及实现工作时，需使用SPEC-FORMAT.md格式将规格说明写入目标项目的

docs/specs/<slug>.md

文件：包含目标、非目标、可验证的验收标准、验证命令。该规格说明将指导后续流程：

implement

环节基于它开发，

verify

环节依据它验证，

land

环节完成收尾并询问是否保留或删除该文件。

The tree does not fit this session: write the draft

决策树无法在本次会话中理清：编写草稿

When the decision tree cannot resolve here (decisions await research beyond this context, or the tree is simply too large for one session), do not force a settled spec out of an unsettled design. Write the spec as a draft instead:

Destination

Decisions so far

(empty),

Open decisions

Not yet specified

(fog),

Out of scope

. Each open decision carries a Mode:

AFK: a
```
/research
```
subagent can resolve it alone. Fire one subagent per AFK decision, in parallel, in this session, each writing its findings to
```
docs/research/<slug>-<decision-slug>.md
```
.
HITL: only a live exchange with the user resolves it. Never answer your own HITL question.

Writing the draft is one session's work: name the destination, sketch the frontier, write the draft, fire the AFK subagents, stop. It resolves nothing itself.

Later sessions work the draft. When a session opens a spec that still has an

## Open decisions

section:

Load the whole spec: the low-res view, not one decision's deep dive.
Pick the next open decision; if the user named one, use that. Claim it before working it.
Resolve it: AFK decisions read the findings the subagent left at
```
docs/research/<slug>-<decision-slug>.md
```
; HITL decisions are worked with the user through the
```
core-interview
```
skill.
Record the resolution in
```
Decisions so far
```
, and remove the decision from
```
Open decisions
```
. Graduate anything now sharp from
```
Not yet specified
```
into fresh open decisions. A decision revealed to sit beyond the destination is ruled out of scope instead of resolved.
When the last open decision closes, delete the
```
## Open decisions
```
section: the spec is settled and the loop takes over.

One decision per session, except AFK decisions already dispatched. If no fog surfaces at all (the way is clear and the journey fits one session), there is no draft; settle normally.

当决策树无法在此处理清（决策需依赖超出当前上下文的研究，或决策树规模过大无法在一次会话中处理），请勿强行从未确定的设计中生成已敲定的规格说明。而是将规格说明写成草稿：包含

Destination

、

Decisions so far

（空）、

Open decisions

、

Not yet specified

（未明确部分）、

Out of scope

。每个未解决的决策需标注模式：

AFK：可由
```
/research
```
子Agent独立解决。在本次会话中为每个AFK决策并行启动一个子Agent，每个子Agent需将研究结果写入
```
docs/research/<slug>-<decision-slug>.md
```
。
HITL：仅能通过与用户实时交互解决。绝不能自行回答HITL问题。

编写草稿为单次会话的任务：明确目标、勾勒边界、撰写草稿、启动AFK子Agent，然后停止。草稿本身不解决任何问题。

后续会话处理草稿。当会话打开仍包含

## Open decisions

章节的规格说明时：

加载完整规格说明：查看整体概览，而非单个决策的深入细节。
选择下一个未解决的决策；如果用户指定了某个决策，则优先处理该决策。开始处理前需标记该决策为已认领。
解决该决策：AFK决策需读取子Agent留在
```
docs/research/<slug>-<decision-slug>.md
```
中的研究结果；HITL决策需通过
```
core-interview
```
技能与用户协作解决。
将解决方案记录在
```
Decisions so far
```
中，并从
```
Open decisions
```
中移除该决策。将当前已明确的内容从
```
Not yet specified
```
升级为新的未解决决策。若发现某决策超出目标范围，则将其列为超出范围而非解决它。
当最后一个未解决决策被处理后，删除
```
## Open decisions
```
章节：此时规格说明已敲定，后续流程将基于它执行。

每次会话处理一个决策，已分派的AFK决策除外。如果完全没有未明确内容（路径清晰且可在一次会话内完成），则无需编写草稿；按正常流程敲定即可。