plan-one-shot

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan One Shot

单次计划方案

Replicate Antigravity plan-mode behavior using three artifacts and strict review gates.

复制Antigravity计划模式的行为，使用三个工件和严格的审查关卡。

Hard Rules

硬性规则

Before approval: plan only. No code edits, no mutating commands, no commits.

Always produce or update these artifacts together:

```
.exspecso/<plan-name>/task.md
```

.exspecso/<plan-name>/implementation_plan.md

```
.exspecso/<plan-name>/walkthrough.md
```
(stub only during planning)

Match plan depth to scope.
Block execution until user says exactly:
```
Execute Plan
```
.
Do not skip artifact generation even for short tasks.
After approval: execute strictly in
```
task.md
```
order and update statuses continuously.
For existing projects, preserve architecture, naming, folder layout, and dependency choices unless the user asks for a change.
Prefer minimal diff; do not introduce new abstractions/libraries unless justified by at least two concrete reuse points or a clear blocker.

审批前：仅制定计划。不进行代码编辑、不执行变更命令、不提交代码。

始终同步生成或更新以下工件：

```
.exspecso/<plan-name>/task.md
```

.exspecso/<plan-name>/implementation_plan.md

```
.exspecso/<plan-name>/walkthrough.md
```
（规划阶段仅生成占位文件）

计划详细程度与范围匹配。
除非用户明确说出：
```
Execute Plan
```
，否则阻止执行。
即使是短任务也不得跳过工件生成步骤。
审批后：严格按照
```
task.md
```
中的顺序执行，并持续更新状态。
对于现有项目，保留架构、命名规则、文件夹布局和依赖选择，除非用户要求变更。
优先最小化代码差异；除非有至少两个具体的复用场景或明确的阻塞问题，否则不引入新的抽象/库。

Output Control Rules

输出控制规则

Scope-fit depth: small tasks -> short plans; large tasks -> comprehensive plans.
No speculative engineering: avoid unrequested future-proofing.
No vague placeholders like "update logic"; describe exact changes.
Keep verification realistic and runnable in the current repository.
Prefer adapting existing modules over creating new ones.
Keep tool/process notes out of main workstream bullets unless they directly affect implementation steps.

匹配范围的详细程度：小型任务→简短计划；大型任务→全面计划。
不进行投机性工程：避免未被要求的前瞻性设计。
不使用模糊占位符，如“更新逻辑”；需描述确切的变更内容。
验证方案需符合实际，可在当前仓库中运行。
优先适配现有模块而非创建新模块。
除非工具/流程说明直接影响实施步骤，否则不要将其放入主工作流的项目符号中。

Required Plan Structure

计划必填结构

implementation_plan.md

must follow this order:

Title
One-line objective
```
## Proposed Changes
```
Workstreams

File blocks using this format:

#### [MODIFY] [path/to/file.ts](file:///absolute/path/to/file.ts)

#### [CREATE] [path/to/new-file.ts](file:///absolute/path/to/new-file.ts)

```
## Verification Plan
```

Use

---

between major workstreams.

implementation_plan.md

必须遵循以下顺序：

标题
一行式目标
```
## Proposed Changes
```
（建议变更）
工作流

文件块使用以下格式：

#### [MODIFY] [path/to/file.ts](file:///absolute/path/to/file.ts)

#### [CREATE] [path/to/new-file.ts](file:///absolute/path/to/new-file.ts)

```
## Verification Plan
```
（验证计划）

主要工作流之间使用

---

分隔。

Artifact Lifecycle

工件生命周期

All artifacts for one plan must live under a single date-prefixed folder:

```
.exspecso/YYYY-MM-DD-<plan-name>/
```

<plan-name>

rules:

Lowercase.
Keep letters, numbers, and spaces before slug conversion.
Convert spaces/underscores to
```
-
```
.
Remove filler words when possible (
```
the
```
,
```
a
```
,
```
an
```
,
```
for
```
,
```
to
```
,
```
of
```
).
Keep first 3-6 meaningful words.
Max length 36.
Collapse repeated
```
-
```
and trim edges.

单个计划的所有工件必须存放在一个带日期前缀的文件夹下：

```
.exspecso/YYYY-MM-DD-<plan-name>/
```

<plan-name>

命名规则：

小写字母。
转换为短横线连接格式前，可保留字母、数字和空格。
将空格/下划线转换为
```
-
```
。
尽可能去除填充词（
```
the
```
、
```
a
```
、
```
an
```
、
```
for
```
、
```
to
```
、
```
of
```
）。
保留前3-6个有意义的词。
最大长度36个字符。
合并重复的
```
-
```
并修剪首尾。

Replan Decision Gate

重规划决策关卡

For every new request after plan creation, decide first:

```
Decision: Continue Current Plan
```
```
Decision: Create New Plan
```

Provide one short reason.

Create a new plan when objective/success criteria change materially, a new subsystem is introduced, architecture shifts significantly, or planned updates would rewrite roughly more than 40% of the current plan.

在计划创建后收到任何新请求时，首先做出以下决策之一：

```
Decision: Continue Current Plan
```
（决策：继续当前计划）
```
Decision: Create New Plan
```
（决策：创建新计划）

提供简短的理由。

当目标/成功标准发生实质性变化、引入新的子系统、架构发生重大转变，或计划中的更新将重写当前计划约40%以上的内容时，创建新计划。

task.md Template

task.md模板

markdown

undefined

markdown

undefined

<Task Name>

Planning

[/] Explore codebase and identify gaps
[/] Write implementation plan

[/] Explore codebase and identify gaps
[/] Write implementation plan

Execution

<work item>
<work item>

<work item>
<work item>

Verification

<verification item>


Rules:
- During planning, keep Planning items as `[/]`.
- Keep Execution/Verification unchecked until execution starts.
- Keep items concise and action-oriented.

<verification item>


规则：
- 规划阶段，将Planning项标记为`[/]`。
- 在执行开始前，保持Execution/Verification项未勾选。
- 项需简洁且以行动为导向。

walkthrough.md Planning Stub

walkthrough.md规划占位文件

markdown

undefined

markdown

undefined

<Feature Name> Walkthrough

Status

Planning complete. Execution not started.

Planned Scope

<summary bullet>

<summary bullet>

Verification Plan

See
```
implementation_plan.md
```
.

undefined

See
```
implementation_plan.md
```
.

undefined

Execution Tracking

执行跟踪

After receiving

Execute Plan

Mark Planning items
```
[x]
```
.
Mark exactly one in-progress item as
```
[/]
```
.
Move
```
[/]
```
forward one item at a time.
Never leave more than one
```
[/]
```
item.
End with all checklist items marked
```
[x]
```
.

收到

Execute Plan

后：

将Planning项标记为
```
[x]
```
。
将恰好一个进行中的项标记为
```
[/]
```
。
每次将
```
[/]
```
向前移动一个项。
永远不要留下超过一个
```
[/]
```
项。
最终所有检查项均标记为
```
[x]
```
。

Response Contract

响应约定

If approval is missing, end with:

Plan ready for review. Awaiting plan review comments.

If approved, start execution and respond with:

Execute Plan received. Starting execution from task.md Execution section.

若未收到审批，结尾需添加：

Plan ready for review. Awaiting plan review comments.

若已收到审批，开始执行并回复：

Execute Plan received. Starting execution from task.md Execution section.