plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Plan the execution — read spec artifacts, review from multiple perspectives, then generate tasks.md.

<decision_boundary>

Use for:

Breaking down spec artifacts into implementation tasks (tasks.md)
Multi-role review of an execution plan before implementation
Re-generating or updating tasks for an existing change

NOT for:

Creating spec artifacts like proposal, gherkin, or design.md (use
```
/beat:design
```
)
Exploring ideas or investigating a problem (use
```
/beat:explore
```
)
Implementing code (use
```
/beat:apply
```
)
Verifying implementation (use
```
/beat:verify
```
)

Trigger examples:

"Break down the tasks" / "Create execution plan" / "Plan the implementation" / "Review and generate tasks"
Should NOT trigger: "design a new feature" / "write gherkin for X" / "implement the change"

</decision_boundary>

<HARD-GATE> Before writing any files: you MUST invoke superpowers:using-git-worktrees. You MUST invoke superpowers:writing-plans to generate tasks. Do NOT write tasks inline. writing-plans IS the task creation process. This applies regardless of change complexity or time pressure.

You MUST have at least one spec artifact done (gherkin or proposal) before proceeding. Do NOT create tasks from a description alone — spec artifacts are the input.

When the multi-role review rejects an alternative with a load-bearing reason that would otherwise have to be re-litigated by future reviewers: you MUST run the three-condition ADR gate (see

references/adr-format.md

) and offer to record an ADR. User may decline.

If a prerequisite skill is unavailable (not installed), continue with fallback — but NEVER skip because you judged it unnecessary. </HARD-GATE>

Prerequisites (invoke before proceeding)

Superpower	When	Priority
using-git-worktrees	Before first file write	MUST
writing-plans	When creating tasks	MUST

If a superpower is unavailable (skill not installed), skip and continue.

规划执行流程——阅读规范工件，从多视角进行评审，然后生成tasks.md文件。

<decision_boundary>

适用场景：

将规范工件拆解为可执行的任务（生成tasks.md）
代码实现前对执行计划进行多角色评审
为已有变更重新生成或更新任务

不适用场景：

创建proposal、gherkin或design.md等规范工件（请使用
```
/beat:design
```
）
探索想法或调查问题（请使用
```
/beat:explore
```
）
代码实现（请使用
```
/beat:apply
```
）
验证实现结果（请使用
```
/beat:verify
```
）

触发示例：

"拆解任务" / "创建执行计划" / "规划实现方案" / "评审并生成任务"
不应触发的场景："设计新功能" / "为X编写gherkin" / "实现变更"

</decision_boundary>

<HARD-GATE> 在编写任何文件之前：你必须调用superpowers:using-git-worktrees。你必须调用superpowers:writing-plans来生成任务。禁止直接编写任务内容。 writing-plans是任务创建的核心流程，无论变更复杂度或时间压力如何，都必须执行此步骤。

在开始前，你必须至少完成一个规范工件（gherkin或proposal）。禁止仅根据描述创建任务——规范工件是唯一的输入依据。

当多角色评审以“影响后续决策”的理由否决某个方案时（即该理由能避免未来评审者重复讨论同一问题）：你必须执行ADR三道校验（详见

references/adr-format.md

），并询问用户是否需要记录为ADR。用户可选择拒绝。

如果某个必备技能未安装（不可用），请使用 fallback 方案继续——但绝不能因你认为“不必要”而跳过该步骤。 </HARD-GATE>

前置条件（执行前需调用）

超能力（Superpower）	调用时机	优先级
using-git-worktrees	首次写入文件前	必须（MUST）
writing-plans	创建任务时	必须（MUST）

若某个超能力不可用（技能未安装），可跳过并继续执行。

Rationalization Prevention

避免合理化借口

Thought	Reality
"I don't need a worktree, design already committed the artifacts"	Design may not have run, or the worktree may not exist yet. using-git-worktrees is idempotent — if already isolated, it detects and continues.
"This change is simple enough to write tasks inline"	Simple changes finish writing-plans quickly. Complex changes need it most. There is no middle ground where skipping helps.
"I already understand the scope from the proposal/gherkin"	Understanding scope ≠ properly decomposed tasks. writing-plans catches scope gaps you haven't noticed.
"The user wants speed, invoking superpowers will slow us down"	Skipping prerequisites produces lower-quality tasks that cause rework during apply.
"The spec artifacts are clear enough, review is overkill"	Review catches blind spots that the spec author can't see. The more obvious the spec seems, the more likely assumptions are hiding.
"I'll skip review for this small change"	Small changes still benefit from a test coverage check. Review scales with complexity — it's fast for simple changes.
"The review rejected option X — let's just note it in tasks.md"	If the rejection reason is load-bearing for future reviewers, it'll be re-litigated. Run the ADR gate; if all three conditions hold, write the ADR.

错误想法	实际情况
"我不需要工作树，设计阶段已经提交了工件"	设计流程可能未执行，或者工作树尚未创建。using-git-worktrees是幂等操作——如果已处于隔离状态，它会自动检测并继续执行。
"这个变更很简单，可以直接编写任务"	简单变更执行writing-plans的速度很快，而复杂变更最需要该流程。不存在跳过该步骤反而有益的情况。
"我已经从proposal/gherkin中了解了范围"	了解范围 ≠ 合理拆解任务。writing-plans能发现你未注意到的范围漏洞。
"用户想要速度，调用超能力会拖慢进度"	跳过前置条件会生成低质量任务，导致在apply阶段需要返工。
"规范工件已经足够清晰，评审是多余的"	评审能发现规范作者看不到的盲区。规范看起来越明显，就越可能隐藏着未明确的假设。
"这个小变更可以跳过评审"	小变更仍能从测试覆盖检查中获益。评审的深度会随复杂度调整——简单变更的评审速度很快。
"评审否决了方案X——我们只需在tasks.md中注明即可"	如果否决理由对未来评审者至关重要，他们仍会重复讨论该问题。请执行ADR校验；若满足全部三个条件，则需编写ADR。

Red Flags — STOP if you catch yourself:

危险信号——若出现以下情况请立即停止：

Writing any file before invoking using-git-worktrees
Writing
```
- [ ]
```
task checkboxes without having invoked writing-plans
Creating tasks without reading spec artifacts first
Thinking "review isn't needed for this particular change"
Skipping a MUST prerequisite and planning to "compensate" later
Proceeding without at least one spec artifact (gherkin or proposal) being done
Merging a review rejection into tasks.md without checking whether it qualifies as an ADR

在调用using-git-worktrees之前编写任何文件
未调用writing-plans就编写
```
- [ ]
```
任务复选框
未先阅读规范工件就创建任务
认为“这个特定变更不需要评审”
跳过必须的前置条件并计划“后续弥补”
未完成至少一个规范工件（gherkin或proposal）就继续执行
未检查是否符合ADR条件就将评审否决内容合并到tasks.md中

Process Flow

流程示意图

dot

digraph plan {
    "Select change" [shape=box];
    "Invoke using-git-worktrees" [shape=box, style=bold];
    "Read spec artifacts" [shape=box];
    "Check readiness" [shape=diamond];
    "STOP: need spec first" [shape=box, style=dashed];
    "Assess complexity" [shape=box];
    "Suggest review roles" [shape=box];
    "User confirms roles" [shape=box];
    "Invoke writing-plans" [shape=box, style=bold];
    "Generate initial tasks.md" [shape=box];
    "Role count?" [shape=diamond];
    "Single review agent\n(all roles)" [shape=box, style=bold];
    "Parallel review agents\n(1 per role)" [shape=box, style=bold];
    "Merge findings +\nupdate tasks.md" [shape=box];
    "Advance to implement" [shape=box];
    "Show summary" [shape=doublecircle];

    "Select change" -> "Invoke using-git-worktrees";
    "Invoke using-git-worktrees" -> "Read spec artifacts";
    "Read spec artifacts" -> "Check readiness";
    "Check readiness" -> "STOP: need spec first" [label="no spec done"];
    "Check readiness" -> "Assess complexity" [label="spec ready"];
    "Assess complexity" -> "Suggest review roles";
    "Suggest review roles" -> "User confirms roles";
    "User confirms roles" -> "Invoke writing-plans";
    "Invoke writing-plans" -> "Generate initial tasks.md";
    "Generate initial tasks.md" -> "Role count?";
    "Role count?" -> "Single review agent\n(all roles)" [label="1-2 roles"];
    "Role count?" -> "Parallel review agents\n(1 per role)" [label="3+ roles"];
    "Single review agent\n(all roles)" -> "Merge findings +\nupdate tasks.md";
    "Parallel review agents\n(1 per role)" -> "Merge findings +\nupdate tasks.md";
    "Merge findings +\nupdate tasks.md" -> "Commit tasks";
    "Commit tasks" [shape=box];
    "Commit tasks" -> "Advance to implement";
    "Advance to implement" -> "Show summary";
}

Input: Optionally specify a change name. If omitted, infer from context or prompt.

Steps

Select the change

If no name provided:
- Look for
```
beat/changes/
```
  directories (excluding
```
archive/
```
  )
- If only one exists, use it (announce: "Using change: <name>")
- If multiple exist, use AskUserQuestion tool to let user select
Ensure worktree isolation
Invoke
```
using-git-worktrees
```
before reading or writing any files. If already in a worktree (e.g., from design), it detects and continues.
Read spec artifacts and verify readiness
Read
```
status.yaml
```
(schema:
```
references/status-schema.md
```
).
Check that either:
- ```
gherkin
```
  has
```
status: done
```
  → Gherkin-driven
- ```
gherkin
```
  has
```
status: skipped
```
  AND
```
proposal
```
  has
```
status: done
```
  → Proposal-driven
If neither condition is met: "Spec artifacts are required before task breakdown. Run
```
/beat:design
```
first." STOP.
If
```
tasks
```
already has
```
status: done
```
: "Tasks already exist. Re-running will regenerate tasks.md." Confirm with user before proceeding.
Read all available artifacts:
- ```
proposal.md
```
  (if exists)
- ```
features/*.feature
```
  (all files, if gherkin is done)
- ```
design.md
```
  (if exists)
Read
```
beat/config.yaml
```
if it exists (schema:
```
references/config-schema.md
```
). Use
```
language
```
for output language, inject
```
context
```
, and apply
```
rules.tasks
```
as additional constraints.

Assess change complexity and suggest review roles

Evaluate complexity based on:

Number of feature files and scenarios
Number of components/services mentioned in design.md
Whether
```
@e2e
```
scenarios exist (implies integration surface)
Whether design.md mentions external dependencies, DB changes, or API changes

Suggest review roles based on complexity:

Use AskUserQuestion tool:

"Based on the spec artifacts, I suggest the following review perspectives: [dynamically selected roles with rationale]

Adjust, add, remove, or confirm?"

Role selection guidance:

Signal	Suggested role
Always included	Test coverage: Are all scenarios covered? Any gaps?
`@e2e` scenarios present	Integration: Are integration boundaries identified?
design.md mentions API/DB changes	Architecture: Is the design consistent with existing patterns?
proposal.md mentions user-facing changes	User experience: Does the plan match user expectations?
design.md mentions auth/data/external APIs	Security: Are there security considerations?
High scenario count (>5) or multiple features	Scope: Is the decomposition granular enough?

Test coverage is always included. Other roles are suggested dynamically. The user can add custom roles (e.g., "performance", "accessibility") or remove suggested ones.

Generate initial tasks via writing-plans
Invoke
```
superpowers:writing-plans
```
. Pass the completed artifacts (proposal, gherkin, design) as context.
The output of writing-plans becomes the initial tasks.md — do NOT generate tasks.md yourself.
If writing-plans is unavailable (not installed), create tasks.md as fallback with notice:
```

```
Task Decomposition Principles — if writing-plans output violates any principle, decompose further before saving tasks.md:
- Single concern: one component, service, or API endpoint per task. "Build X and integrate into Y" = two tasks.
- ~200 LOC cap: each task produces ~200 lines of new code (excluding tests). More = too many responsibilities.
- 2-3 files max: each task touches at most 2-3 source files. More = crossing concern boundaries.
- Independently verifiable: can run tests after completing without depending on later tasks.
- "And then" test: if a task description needs "and then", split it.
- Exception: project initialization/scaffolding tasks may exceed file limits while maintaining single concern.
Quality Principles header — insert the following block between the tasks.md header and the first
```
### Task
```
:
```
## Quality Principles

**Testing:** Tests verify behavior (return values, state changes, responses), not wiring.
If the main assertion is `toHaveBeenCalledWith`, rewrite to assert on the function's output.

**Code:** No single new file exceeds ~300 lines. If it grows past that, split into focused sub-modules.
```
Save the initial tasks.md to
```
beat/changes/<name>/tasks.md
```
.
Dispatch review agents
Read
```
review-subagent-prompt.md
```
for the subagent prompt template.
Dispatch strategy based on confirmed role count:
- 1–2 roles: Single Agent (subagent_type:
```
Explore
```
  ) with all confirmed roles. Build one prompt containing all roles and their focus areas.
- 3+ roles: One Agent (subagent_type:
```
Explore
```
  ) per role, dispatched in parallel. Each agent receives ONLY its own role and focus area — no knowledge of other roles.
Every agent receives:
- All spec artifacts (proposal, gherkin, design)
- The initial tasks.md
Do NOT pass conversation history or session context to any agent.

Why parallel at 3+: A single agent reviewing from many perspectives simultaneously loses depth and independence — findings from one role bias another. Independent agents give genuine blind-spot coverage. At 1–2 roles the overhead isn't worth the split.
Fallback: If any agent fails or returns empty, proceed with findings from the others. If ALL fail, use initial tasks.md as-is. Show notice: "Review could not be completed — tasks.md was not reviewed. Consider re-running
```
/beat:plan
```
."
Merge findings and update tasks.md

Collect findings from all review agents. If parallel agents were used:
- Deduplicate findings that identify the same issue from different roles
- When findings conflict, prefer the more conservative recommendation
ADR gate on rejected alternatives — scan the review output for cases where an alternative approach was considered and rejected with a load-bearing reason (i.e. a reason a future reviewer would want to know about to avoid re-suggesting the same thing). For each, run the three conditions from
```
references/adr-format.md
```
:
1. Hard to reverse?
2. Surprising without context?
3. Result of a real trade-off?
If all three hold, use AskUserQuestion tool: "Review rejected '<alt>' because '<reason>' — record as ADR?" On Yes, write the ADR under
```
docs/adr/
```
, increment numbering, cross-reference from
```
tasks.md
```
or
```
design.md
```
as appropriate. On No, continue.
Read
```
beat/changes/<name>/tasks.md
```
, then use the Edit tool to apply:
- Add missing tasks or steps identified by the review
- Split tasks that the review flagged as too broad
- Add test coverage notes where the review found gaps
- Reorder tasks if the review identified dependency issues
Show the user a brief summary of what changed:
```
## Review Applied

- [Role]: <what was changed>
- [Role]: <what was changed>
...
```
Update
```
status.yaml
```
: set
```
tasks
```
to
```
{ status: done }
```
and phase to
```
tasks
```
.

Commit and advance phase

Commit tasks.md and updated status.yaml:

git add beat/changes/<name>/ && git commit

Update phase to

implement

status.yaml

(advancing from

tasks

→

implement

## Plan Complete: <change-name>

Tasks: N tasks in tasks.md
Review: [list of roles that reviewed]
Changes from review: [count of modifications]

Ready for implementation! Run `/beat:apply` to start.

Guardrails

NEVER proceed without at least one spec artifact (gherkin or proposal) being done
NEVER write tasks inline — always use writing-plans (or fallback with notice)
Review is part of the process, not optional — but depth scales with complexity
Test coverage review is always included regardless of complexity
Apply review findings directly to tasks.md, not as a separate report
If review reveals spec-level issues (missing scenarios, design gaps), surface them to the user rather than silently compensating in tasks

dot

digraph plan {
    "Select change" [shape=box];
    "Invoke using-git-worktrees" [shape=box, style=bold];
    "Read spec artifacts" [shape=box];
    "Check readiness" [shape=diamond];
    "STOP: need spec first" [shape=box, style=dashed];
    "Assess complexity" [shape=box];
    "Suggest review roles" [shape=box];
    "User confirms roles" [shape=box];
    "Invoke writing-plans" [shape=box, style=bold];
    "Generate initial tasks.md" [shape=box];
    "Role count?" [shape=diamond];
    "Single review agent\n(all roles)" [shape=box, style=bold];
    "Parallel review agents\n(1 per role)" [shape=box, style=bold];
    "Merge findings +\nupdate tasks.md" [shape=box];
    "Advance to implement" [shape=box];
    "Show summary" [shape=doublecircle];

    "Select change" -> "Invoke using-git-worktrees";
    "Invoke using-git-worktrees" -> "Read spec artifacts";
    "Read spec artifacts" -> "Check readiness";
    "Check readiness" -> "STOP: need spec first" [label="no spec done"];
    "Check readiness" -> "Assess complexity" [label="spec ready"];
    "Assess complexity" -> "Suggest review roles";
    "Suggest review roles" -> "User confirms roles";
    "User confirms roles" -> "Invoke writing-plans";
    "Invoke writing-plans" -> "Generate initial tasks.md";
    "Generate initial tasks.md" -> "Role count?";
    "Role count?" -> "Single review agent\n(all roles)" [label="1-2 roles"];
    "Role count?" -> "Parallel review agents\n(1 per role)" [label="3+ roles"];
    "Single review agent\n(all roles)" -> "Merge findings +\nupdate tasks.md";
    "Parallel review agents\n(1 per role)" -> "Merge findings +\nupdate tasks.md";
    "Merge findings +\nupdate tasks.md" -> "Commit tasks";
    "Commit tasks" [shape=box];
    "Commit tasks" -> "Advance to implement";
    "Advance to implement" -> "Show summary";
}

输入：可选择性指定变更名称。若未指定，则从上下文或提示中推断。

步骤

选择变更

若未提供变更名称：
- 查找
```
beat/changes/
```
  目录（排除
```
archive/
```
  ）
- 若仅存在一个目录，则使用该目录（告知用户："使用变更：<名称>"）
- 若存在多个目录，则使用AskUserQuestion工具让用户选择
确保工作树隔离
在读取或写入任何文件之前，调用
```
using-git-worktrees
```
。若已处于工作树中（例如来自设计阶段），它会自动检测并继续执行。
读取规范工件并验证就绪状态
读取
```
status.yaml
```
（ schema：
```
references/status-schema.md
```
）。
需满足以下任一条件：
- ```
gherkin
```
  的状态为
```
done
```
  → Gherkin驱动
- ```
gherkin
```
  的状态为
```
skipped
```
  且
```
proposal
```
  的状态为
```
done
```
  → Proposal驱动
若两个条件都不满足："任务拆解前需要规范工件。请先运行
```
/beat:design
```
。" 停止执行。
若
```
tasks
```
的状态已为
```
done
```
："任务已存在。重新运行将重新生成tasks.md。" 继续执行前需确认用户同意。
读取所有可用的工件：
- ```
proposal.md
```
  （若存在）
- ```
features/*.feature
```
  （若gherkin已完成，读取所有文件）
- ```
design.md
```
  （若存在）
若
```
beat/config.yaml
```
存在则读取该文件（schema：
```
references/config-schema.md
```
）。使用
```
language
```
字段指定输出语言，注入
```
context
```
上下文，并应用
```
rules.tasks
```
作为额外约束。

评估变更复杂度并建议评审角色

基于以下维度评估复杂度：

功能文件和场景的数量
design.md中提及的组件/服务数量
是否存在
```
@e2e
```
场景（意味着需要集成）
design.md是否提及外部依赖、数据库变更或API变更

基于复杂度建议评审角色：

使用AskUserQuestion工具：

"根据规范工件，我建议从以下视角进行评审： [动态选择的角色及理由]

是否需要调整、添加、移除角色，或确认当前建议？"

角色选择指南：

信号	建议角色
必选	测试覆盖: 是否覆盖所有场景？是否存在遗漏？
存在 `@e2e` 场景	集成: 是否明确了集成边界？
design.md提及API/数据库变更	架构: 设计是否符合现有模式？
proposal.md提及面向用户的变更	用户体验: 计划是否符合用户预期？
design.md提及认证/数据/外部API	安全: 是否存在安全考量？
场景数量较多（>5）或包含多个功能	范围: 任务拆解的粒度是否足够？

测试覆盖是必选角色。其他角色根据实际情况动态建议。用户可添加自定义角色（如"性能"、"可访问性"）或移除建议的角色。

通过writing-plans生成初始任务
调用
```
superpowers:writing-plans
```
。将已完成的工件（proposal、gherkin、design）作为上下文传入。
writing-plans的输出即为初始的tasks.md——禁止自行生成tasks.md。
若writing-plans不可用（未安装），则创建tasks.md作为备用方案，并添加以下说明：
```

```
任务拆解原则——若writing-plans的输出违反以下任一原则，需进一步拆解后再保存tasks.md：
- 单一职责: 每个任务对应一个组件、服务或API端点。"构建X并集成到Y"应拆分为两个任务。
- 约200行代码上限: 每个任务新增代码约200行（不含测试代码）。超过该数量意味着职责过多。
- 最多修改2-3个文件: 每个任务最多涉及2-3个源文件。超过该数量意味着跨越了职责边界。
- 可独立验证: 完成任务后可独立运行测试，无需依赖后续任务。
- "然后"测试: 若任务描述中需要使用"然后"，则需拆分该任务。
- 例外情况：项目初始化/脚手架任务在保持单一职责的前提下，可突破文件数量限制。
质量原则头部——在tasks.md的标题与第一个
```
### Task
```
之间插入以下内容：
```
## Quality Principles

**Testing:** Tests verify behavior (return values, state changes, responses), not wiring.
If the main assertion is `toHaveBeenCalledWith`, rewrite to assert on the function's output.

**Code:** No single new file exceeds ~300 lines. If it grows past that, split into focused sub-modules.
```
将初始tasks.md保存至
```
beat/changes/<name>/tasks.md
```
。
调度评审Agent
读取
```
review-subagent-prompt.md
```
获取子Agent的提示模板。
基于确认的角色数量选择调度策略：
- 1–2个角色: 单个Agent（subagent_type:
```
Explore
```
  ）承担所有确认的角色。构建包含所有角色及其关注点的提示词。
- 3个及以上角色: 每个角色对应一个Agent（subagent_type:
```
Explore
```
  ），并行调度。每个Agent仅接收自身角色及关注点——不了解其他角色的信息。
每个Agent都会收到：
- 所有规范工件（proposal、gherkin、design）
- 初始的tasks.md
禁止将对话历史或会话上下文传递给任何Agent。

为何3个及以上角色采用并行调度：单个Agent同时从多个视角评审会失去深度和独立性——一个角色的发现会影响另一个角色的判断。独立的Agent能真正覆盖盲区。对于1–2个角色，拆分带来的开销得不偿失。
备用方案: 若某个Agent执行失败或返回空结果，可基于其他Agent的发现继续执行。若所有Agent都失败，则直接使用初始的tasks.md。并显示提示："评审无法完成——tasks.md未经过评审。建议重新运行
```
/beat:plan
```
。"
合并评审结果并更新tasks.md

收集所有评审Agent的结果。若使用了并行Agent：
- 去重不同角色发现的同一问题
- 若结果冲突，优先选择更保守的建议
被否决方案的ADR校验——扫描评审输出，查找以下情况：某个备选方案被考虑但以“影响后续决策”的理由否决（即该理由能让未来评审者了解背景，避免重复提出同一方案）。对每个符合情况的案例，执行
```
references/adr-format.md
```
中的三个条件：
1. 是否难以逆转？
2. 无上下文时是否会令人惊讶？
3. 是否是真实权衡的结果？
若全部三个条件都满足，使用AskUserQuestion工具询问："评审否决了'<方案>'，理由是'<原因>'——是否记录为ADR？" 若用户同意，在
```
docs/adr/
```
下编写ADR，递增编号，并在
```
tasks.md
```
或
```
design.md
```
中添加交叉引用。若用户拒绝，则继续执行。
读取
```
beat/changes/<name>/tasks.md
```
，然后使用Edit工具应用以下修改：
- 添加评审发现的缺失任务或步骤
- 拆分评审标记为范围过宽的任务
- 在评审发现测试覆盖缺口的位置添加备注
- 若评审发现依赖问题，重新排序任务
向用户展示修改内容的简要总结：
```
## 评审结果已应用

- [角色]: <修改内容>
- [角色]: <修改内容>
...
```
更新
```
status.yaml
```
：将
```
tasks
```
设置为
```
{ status: done }
```
，并将阶段设置为
```
tasks
```
。

提交并推进阶段

提交tasks.md和更新后的status.yaml：

git add beat/changes/<name>/ && git commit

在

status.yaml

中将阶段更新为

implement

（从

tasks

阶段推进到

implement

阶段）。

## 规划完成：<变更名称>

任务：tasks.md中包含N个任务
评审：[参与评审的角色列表]
评审带来的修改：[修改次数]

已准备好进入实现阶段！运行`/beat:apply`开始执行。

防护规则

绝不能在未完成至少一个规范工件（gherkin或proposal）的情况下继续执行
绝不能直接编写任务内容——必须使用writing-plans（或带说明的备用方案）
评审是流程的一部分，而非可选步骤——但评审深度会随复杂度调整
无论复杂度如何，测试覆盖评审都是必选环节
评审结果需直接应用到tasks.md中，而非作为单独报告
若评审发现规范层面的问题（缺失场景、设计漏洞），需告知用户，而非在任务中默默弥补