evanflow-executing-plans

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

EvanFlow: Executing Plans

EvanFlow：计划执行

Vocabulary

术语说明

See

evanflow

meta-skill. Key terms: vertical slice, behavior through public interface.

参见

evanflow

元技能。关键术语：vertical slice、behavior through public interface。

When to Use

适用场景

A plan file exists (
```
docs/plans/...
```
or wherever the user put it)
Ready to start implementation

存在计划文件（
```
docs/plans/...
```
或用户存放的其他位置）
准备好开始实施

The Flow

执行流程

0. Parallelization Check (offer coder-overseer if applicable)

0. 并行化检查（若适用则提供coder-overseer选项）

Before doing anything else, scan the plan: does it have 3+ truly independent units that share a common interface contract?

If YES — offer

evanflow-coder-overseer

to the user before starting sequential execution:

"This plan has [N] independent units. We can execute sequentially or via
evanflow-coder-overseer
(parallel coders + per-coder overseers + integration overseer + executable cohesion contract via named integration tests). Parallel is faster and adds independent QA. Which path?"

If the user picks coder-overseer, hand off there and stop this skill. If the user picks sequential — or if the plan doesn't qualify (tightly sequential dependencies, fewer than 3 units, no shared contract) — proceed to step 1.

在开始任何工作前，先扫描计划：是否包含3个及以上真正独立、且共享公共接口契约的单元？

如果是——在开始顺序执行前，向用户提供

evanflow-coder-overseer

选项：

"该计划包含[N]个独立单元。我们可以选择顺序执行，或通过
evanflow-coder-overseer
（并行编码者 + 编码者专属监督者 + 集成监督者 + 基于命名集成测试的可执行内聚契约）执行。并行执行速度更快，且能提供独立的QA环节。选择哪种方式？"

如果用户选择coder-overseer，则移交至该流程并终止当前技能。如果用户选择顺序执行——或计划不符合并行条件（依赖关系紧密、单元数量少于3个、无共享契约）——则进入步骤1。

1. Load and Critically Review

1. 加载并严谨评审

Read the plan in full
Identify ambiguities, gaps, or assumptions you'd make differently
If anything is unclear or wrong, raise it with the user before starting
Set up TaskCreate items mirroring the plan's tasks

完整阅读计划
识别模糊点、漏洞或与你预期不同的假设
若存在不明确或错误的内容，请在开始前向用户提出
创建与计划任务对应的TaskCreate条目

2. Execute Task-by-Task

2. 逐任务执行

For each task:

Mark the task
```
in_progress
```
Follow the plan's bite-sized steps exactly
For code steps, default to TDD via
```
evanflow-tdd
```
(skip only when plan flags an exception)
Run the inline verifications the plan specifies
Run the project-wide quality checks before claiming done. The exact commands are project-specific — find them in CLAUDE.md or the project's README. Typically:
- typecheck (e.g.,
```
tsc --noEmit
```
  ,
```
pnpm typecheck
```
  ,
```
cargo check
```
  ,
```
go vet ./...
```
  )
- lint (e.g.,
```
eslint .
```
  ,
```
pnpm lint
```
  ,
```
cargo clippy
```
  ,
```
ruff check .
```
  )
- test for affected workspaces (e.g.,
```
pnpm test
```
  ,
```
pytest
```
  ,
```
cargo test
```
  ,
```
go test ./...
```
  )
Mark the task
```
completed
```

针对每个任务：

将任务标记为
```
in_progress
```
严格遵循计划中的小步步骤
对于代码步骤，默认通过
```
evanflow-tdd
```
进行测试驱动开发（仅当计划标记例外时跳过）
执行计划指定的内联验证
在声称完成前，运行项目级质量检查。具体命令因项目而异——请在CLAUDE.md或项目README中查找。通常包括：
- 类型检查（例如：
```
tsc --noEmit
```
  、
```
pnpm typecheck
```
  、
```
cargo check
```
  、
```
go vet ./...
```
  ）
- 代码检查（例如：
```
eslint .
```
  、
```
pnpm lint
```
  、
```
cargo clippy
```
  、
```
ruff check .
```
  ）
- 受影响工作区的测试（例如：
```
pnpm test
```
  、
```
pytest
```
  、
```
cargo test
```
  、
```
go test ./...
```
  ）
将任务标记为
```
completed
```

3. Handle Blockers

3. 处理阻塞问题

Stop immediately when:

Missing dependency or environment problem
Plan instruction is ambiguous or contradicts the code
Verification fails repeatedly
Discover the plan's assumption was wrong

Don't force through. Surface the blocker and ask. If the plan needs revision, return to

evanflow-writing-plans

立即停止的情况：

缺少依赖项或环境问题
计划指令模糊或与代码冲突
验证反复失败
发现计划的假设错误

不要强行推进。 提出阻塞问题并询问用户。若计划需要修订，则返回至

evanflow-writing-plans

。

4. Iterate, Then Stop

4. 迭代，然后停止

After all tasks pass quality checks, hand off to

evanflow-iterate

for the self-review loop. Iterate finds issues a single pass missed (dead code, naming, scope creep, missing tests). For UI changes, iterate also views the rendered page.

When iterate converges: report what was done and STOP. Do NOT stage files (

git add

), do NOT commit, do NOT push, do NOT propose integration. The user decides every step from here.

A good "done" report includes: what files changed (one line each), what behaviors were added/changed, what verifications passed. Then await user direction.

所有任务通过质量检查后，移交至

evanflow-iterate

进行自评审循环。迭代环节会发现单次执行遗漏的问题（死代码、命名问题、范围蔓延、缺失测试）。对于UI变更，迭代环节还会查看渲染后的页面。

当迭代收敛后：报告完成的工作并停止。不要进行文件暂存（

git add

）、提交（commit）、推送（push）或提议集成操作。后续的每一步都由用户决定。

一份优质的“完成”报告应包含：变更的文件（每行一个）、新增/修改的行为、通过的验证内容。然后等待用户指示。

Hard Rules

硬性规则

Never auto-commit, never auto-stage, never auto-finish. Period. After all tasks pass and iterate converges, report and stop. The user decides what comes next.
No forced sub-skill chain. Subagent-driven execution and git-worktree isolation are escape hatches for huge plans, not requirements.
Verify before claiming done. Run the project's quality checks and confirm output before marking a task complete or reporting success.
Match scope. Don't add features or refactor beyond what the plan calls for.

绝不自动提交、绝不自动暂存、绝不自动完成。 所有任务通过且迭代收敛后，必须报告并停止。后续操作由用户决定。
不强制使用子技能链。 子代理驱动的执行和git-worktree隔离是针对大型计划的应急方案，而非强制要求。
完成前先验证。 在标记任务完成或报告成功前，运行项目的质量检查并确认输出结果。
匹配范围。 不要添加计划之外的功能或进行重构。

Hand-offs

流程移交

All tasks complete →
```
evanflow-iterate
```
(self-review loop) → report and STOP
Plan needs revision → back to
```
evanflow-writing-plans
```
Plan has 3+ truly independent parallel tasks with a shared contract → switch to
```
evanflow-coder-overseer
```
(parallel coders + per-coder overseers + integration overseer)
Working in a shared codebase, want isolation → consider a git-worktrees workflow if your environment provides one

所有任务完成 →
```
evanflow-iterate
```
（自评审循环）→ 报告并停止
计划需要修订 → 返回至
```
evanflow-writing-plans
```
计划包含3个及以上真正独立且共享契约的并行任务 → 切换至
```
evanflow-coder-overseer
```
（并行编码者 + 编码者专属监督者 + 集成监督者）
在共享代码库中工作，需要隔离环境 → 若你的环境支持，可考虑使用git-worktrees工作流