apply

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Implement code based on the change artifacts. Supports two modes:

Gherkin-driven (default): feature files drive implementation and testing
Proposal-driven: when gherkin is skipped (technical changes), proposal drives testing

<decision_boundary>

Use for:

Implementing code for a Beat change that has spec artifacts (gherkin or proposal) done
TDD implementation driven by feature files or proposal risk points
Resuming implementation of a partially completed change

NOT for:

Creating spec artifacts like proposal, gherkin, or design.md (use
```
/beat:design
```
)
Breaking down tasks or creating execution plans (use
```
/beat:plan
```
)
Verifying implementation completeness (use
```
/beat:verify
```
)
Exploring ideas or investigating a problem (use
```
/beat:explore
```
)

Trigger examples:

"Implement the change" / "Start coding" / "Apply the plan" / "TDD the scenarios"
Should NOT trigger: "design a feature" / "break down tasks" / "verify the implementation"

</decision_boundary>

<HARD-GATE> Before any code changes: you MUST invoke superpowers:using-git-worktrees to verify isolation (should already exist from design/plan; creates one if not). In TDD mode: you MUST invoke superpowers:test-driven-development. Invoke in order: worktrees first (verify), then TDD (discipline). If a prerequisite skill is unavailable (not installed), continue without it — but NEVER skip because you judged it unnecessary. </HARD-GATE>

Prerequisites (invoke before proceeding)

Superpower	When	Priority
using-git-worktrees	Verify isolation (should exist from design/plan; creates if not)	MUST
test-driven-development	At start, in TDD mode	MUST
systematic-debugging	When stuck (3 failed attempts)	SHOULD
subagent-driven-development	When tasks.md has multiple independent tasks	SHOULD

Invoke in order: worktrees first (verify isolation), then TDD (discipline). Debugging and subagent are conditional — only invoke when triggered. If a superpower is unavailable (skill not installed), skip and continue.

基于变更工件实现代码。支持两种模式：

Gherkin驱动模式（默认）：功能文件驱动实现与测试
提案驱动模式：当跳过gherkin时（技术变更），由提案驱动测试

<decision_boundary>

适用场景：

为已完成规范工件（gherkin或提案）的Beat变更实现代码
由功能文件或提案风险点驱动的TDD实现
恢复部分完成的变更的实现工作

不适用场景：

创建提案、gherkin或design.md等规范工件（使用
```
/beat:design
```
）
拆分任务或创建执行计划（使用
```
/beat:plan
```
）
验证实现完整性（使用
```
/beat:verify
```
）
探索想法或调查问题（使用
```
/beat:explore
```
）

触发示例：

"实现变更" / "开始编码" / "执行计划" / "对场景进行TDD开发"
不应触发："设计功能" / "拆分任务" / "验证实现"

</decision_boundary>

<HARD-GATE> 在进行任何代码变更之前：必须调用superpowers:using-git-worktrees来验证隔离性（该工作区应已在设计/规划阶段创建；若不存在则创建）。在TDD模式下：必须调用superpowers:test-driven-development。调用顺序：先调用工作区（验证），再调用TDD（遵循规范）。如果某个必备技能不可用（未安装），则跳过该技能继续执行——但绝不能因为你认为不必要而跳过。 </HARD-GATE>

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

超能力	适用时机	优先级
using-git-worktrees	验证隔离性（应已在设计/规划阶段创建；若不存在则创建）	必须
test-driven-development	TDD模式开始时	必须
systematic-debugging	遇到瓶颈时（3次尝试失败）	应该
subagent-driven-development	当tasks.md包含多个独立任务时	应该

调用顺序：先调用工作区（验证隔离性），再调用TDD（遵循规范）。调试和子代理为条件触发——仅在符合触发条件时调用。如果某个超能力不可用（技能未安装），则跳过并继续。

Rationalization Prevention

避免合理化借口

Thought	Reality
"The change is small, I don't need a worktree"	Worktrees protect against contamination. The worktree should already exist from design/plan — verify, don't skip.
"I'll write the test after the implementation, same result"	TDD is about design feedback, not just test coverage. Writing tests after loses the design signal.
"This is a refactor, TDD doesn't apply"	Refactors need tests most — they prove behavior is preserved. If testing.required is false, TDD is already skipped.
"I'll add @covered-by annotations at the end for all scenarios"	Annotations must be added per-scenario immediately after writing the test. Batching them leads to forgetting.
"The e2e test setup is too complex, I'll write a unit test instead"	The scenario is tagged @e2e for a reason. If e2e setup is genuinely blocked, announce the blocker and ask — don't silently downgrade.
"This @behavior test is obvious, a skeleton is enough"	Every test must be executable. A skeleton that doesn't run is not a test.
"These tasks are small, I'll combine them for efficiency"	Each task is bounded for a reason. Merging recreates the oversized-output problem that decomposition solved. One task = one subagent dispatch.
"The existing test is roughly correct, no need to update it"	If scenario steps changed, the test must reflect those changes. An old test passing does not mean the new behavior is correct.
"I'll create a new test file, it's faster"	If @covered-by already points to an existing test, creating a new file breaks traceability. Update the existing test.

想法	实际情况
"变更很小，我不需要工作区"	工作区可防止代码污染。工作区应已在设计/规划阶段创建——请验证，不要跳过。
"我会在实现后再写测试，结果一样"	TDD的核心是获取设计反馈，而不仅仅是测试覆盖率。实现后写测试会丢失设计信号。
"这是重构，TDD不适用"	重构最需要测试——测试能证明行为未被改变。如果testing.required设为false，TDD会自动跳过。
"我会在最后为所有场景添加@covered-by注释"	注释必须在编写测试后立即按场景添加。批量添加会导致遗漏。
"端到端测试设置太复杂，我改用单元测试"	场景标记为@e2e是有原因的。如果端到端设置确实受阻，请告知障碍并请求帮助——不要悄悄降级测试类型。
"这个@behavior测试很明显，写个骨架就行"	每个测试必须可执行。无法运行的骨架不是测试。
"这些任务很小，我合并起来提高效率"	每个任务的边界设定是有原因的。合并任务会重现分解任务所要解决的输出过大问题。一个任务对应一次子代理调度。
"现有测试大致正确，不需要更新"	如果场景步骤发生变化，测试必须反映这些变化。旧测试通过不代表新行为正确。
"我新建一个测试文件，更快"	如果@covered-by已指向现有测试，新建文件会破坏可追溯性。请更新现有测试。

Red Flags — STOP if you catch yourself:

危险信号——如果发现自己有以下行为，请立即停止：

Writing implementation code before invoking using-git-worktrees
Writing implementation code before writing a failing test (in TDD mode)
Thinking "I'll set up the worktree after this first file"
Skipping TDD because "the test would be trivial"
Moving to the next scenario without adding
```
@covered-by
```
to the .feature file
Skipping e2e test creation because "the e2e framework is complex to set up"
Writing a test skeleton instead of an executable test
Thinking "I'll add the annotations at the end after all scenarios are done"
Dispatching a single subagent for multiple tasks to "save time"
Creating a new test file for a scenario that already has
```
@covered-by
```
pointing to an existing test
Modifying scenario steps without updating the corresponding e2e test

在调用using-git-worktrees之前编写实现代码
在TDD模式下，编写实现代码之前未编写失败的测试
想着"我先写完这个文件再设置工作区"
因为"测试很简单"而跳过TDD
未在.feature文件中添加
```
@covered-by
```
就进入下一个场景
因为"端到端框架设置复杂"而跳过端到端测试创建
编写测试骨架而非可执行测试
想着"我会在所有场景完成后再添加注释"
为多个任务调度单个子代理以"节省时间"
为已存在
```
@covered-by
```
指向现有测试的场景创建新测试文件
修改场景步骤但未更新对应的端到端测试

Mid-Implementation Triggers (mandatory)

实现中触发条件（强制）

ADR — hard-to-reverse + surprising + real-trade-off decision not in
```
design.md
```
→ write ADR (
```
references/adr-format.md
```
)
README — module public-interface change → update module README (
```
references/architecture-format.md
```
)

Run inline as conditions arise. Don't batch.

ADR —— 难以回退、出人意料且涉及实际权衡的决策，且未记录在
```
design.md
```
中 → 编写ADR（参考
```
references/adr-format.md
```
）
README —— 模块公共接口变更 → 更新模块README（参考
```
references/architecture-format.md
```
）

当条件满足时立即执行，不要批量处理。

Process Flow

流程

dot

digraph apply {
    "Select change, read artifacts" [shape=box];
    "Invoke using-git-worktrees" [shape=box, style=bold];
    "testing.required false?" [shape=diamond];
    "No-test mode" [shape=box];
    "Invoke test-driven-development" [shape=box, style=bold];
    "Gherkin done?" [shape=diamond];
    "Gherkin-driven" [shape=box];
    "Proposal-driven" [shape=box];
    "tasks.md exists?" [shape=diamond];
    "Has Task N headings?" [shape=diamond];
    "Executor mode\nfollow tasks exactly" [shape=box];
    "Planner mode\nextract scenarios/criteria" [shape=box];
    "Implementation loop" [shape=box];
    "All tasks complete" [shape=doublecircle];

    "Select change, read artifacts" -> "Invoke using-git-worktrees";
    "Invoke using-git-worktrees" -> "testing.required false?";
    "testing.required false?" -> "No-test mode" [label="yes"];
    "testing.required false?" -> "Invoke test-driven-development" [label="no"];
    "No-test mode" -> "Gherkin done?";
    "Invoke test-driven-development" -> "Gherkin done?";
    "Gherkin done?" -> "Gherkin-driven" [label="yes"];
    "Gherkin done?" -> "Proposal-driven" [label="gherkin skipped"];
    "Gherkin-driven" -> "tasks.md exists?";
    "Proposal-driven" -> "tasks.md exists?";
    "tasks.md exists?" -> "Has Task N headings?" [label="yes"];
    "tasks.md exists?" -> "Planner mode\nextract scenarios/criteria" [label="no"];
    "Has Task N headings?" -> "Executor mode\nfollow tasks exactly" [label="yes"];
    "Has Task N headings?" -> "Planner mode\nextract scenarios/criteria" [label="no"];
    "Executor mode\nfollow tasks exactly" -> "Implementation loop";
    "Planner mode\nextract scenarios/criteria" -> "Implementation loop";
    "Implementation loop" -> "All tasks complete";
}

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
Read status.yaml and verify readiness (schema:
```
references/status-schema.md
```
)
Check that either:
- ```
gherkin
```
  has
```
status: done
```
  → Gherkin-driven mode
- ```
gherkin
```
  has
```
status: skipped
```
  AND
```
proposal
```
  has
```
status: done
```
  → Proposal-driven mode
If neither condition is met: "Features or proposal are required before implementation. Run
```
/beat:design
```
first." STOP.
Read all artifacts and determine testing mode

Read in order:
- ```
proposal.md
```
  (if exists) -- business context and risk points
- ```
features/*.feature
```
  (all files, if gherkin is done) -- implementation targets
- ```
design.md
```
  (if exists) -- technical decisions
- ```
tasks.md
```
  (if exists) -- implementation checklist
Read
```
beat/config.yaml
```
(if exists, schema:
```
references/config-schema.md
```
).
Determine testing mode:
- If
```
testing.required: false
```
  → no-test mode: skip TDD cycles for all scenarios, write implementation only
- If
```
testing.behavior
```
  is set → use that framework for
```
@behavior
```
  scenarios (skip auto-detection)
- If
```
testing.e2e
```
  is set → use that framework for
```
@e2e
```
  scenarios (skip auto-detection)
- If
```
testing.framework
```
  is set (legacy) → treat as
```
testing.behavior
```
- If
```
testing
```
  is absent or
```
testing.required: true
```
  → TDD mode (default): require tests for all scenarios
Determine BDD feature paths (for running e2e tests):
- Base:
```
beat/features/
```
  (unchanged features;
```
.feature.orig
```
  files are invisible to BDD runners)
- If
```
status.yaml
```
  has
```
gherkin.modified
```
  : add
```
beat/changes/<name>/features/
```
  (modified + new features)
- Combine both paths when invoking BDD runner (e.g.,
```
npx cucumber-js beat/features beat/changes/<name>/features
```
  )
Determine implementation strategy

If tasks.md exists: Use it as the implementation checklist.
- Detailed format (contains
```
### Task N:
```
  headings with Steps): Enter executor mode — follow each step exactly as written, don't re-plan.
- Simple format (only
```
- [ ]
```
  checkboxes): Enter planner mode — plan each task's implementation yourself (existing behavior).
If no tasks.md and Gherkin-driven: Extract each Scenario from feature files as a unit of work (planner mode).

If no tasks.md and Proposal-driven: Extract success criteria and risk points from proposal.md as units of work (planner mode).

Show implementation overview

## Implementing: <change-name>

### Drive mode: gherkin-driven / proposal-driven
### Execution mode: executor / planner
### Tasks/Scenarios to implement:
1. [source] <name>
2. [source] <name>
...

Implement (loop)

For each task (from tasks.md) or scenario (from features) or risk point (from proposal):

a. Announce: "Working on: <description>"

b. Write automated test first (TDD mode only):
- Skip this step if no-test mode
- The test framework: use
```
testing.behavior
```
  or
```
testing.e2e
```
  from config (depending on scenario tag), or detect from codebase
Generate vs Update (see
```
references/testing-conventions.md
```
for details):
- ```
@covered-by
```
  present + test file exists → Update: modify the existing test to reflect new scenario steps
- ```
@covered-by
```
  present + test file missing → Generate + WARNING (stale annotation)
- ```
@covered-by
```
  absent → Generate: create new test (existing flow)
For
@e2e
scenarios (Gherkin-driven):
- Generate (or update) e2e test or step definitions using
```
testing.e2e
```
  framework from config, or auto-detect from codebase
- If the project uses a BDD runner (Cucumber, pytest-bdd, etc.), generate step definitions that bind to the .feature file
- If no BDD runner, generate a regular e2e test with
```
@feature
```
  /
```
@scenario
```
  annotations (same as
```
@behavior
```
  )
For
@behavior
scenarios (Gherkin-driven):
- Generate a test file (using
```
testing.behavior
```
  from config, or auto-detect) with annotation comments:
```
@feature: <feature-filename>.feature
@scenario: <exact scenario name>
```
  (Use the project language's comment syntax:
```
//
```
  for JS/TS/Java/C#,
```
#
```
  for Python/Ruby, etc.)
- After writing the test, update the .feature file with a
```
@covered-by
```
  annotation (placed between the tag and the scenario line):
  gherkin
```
@behavior @happy-path
# @covered-by: <relative path to test file>
Scenario: <name>
```
For proposal-driven units:
- Generate test files covering the risk point using the project's test framework
- No annotation conventions needed (no features to link to) For pytest-bdd projects: the
```
@scenario
```
  decorator serves as the annotation — no separate
```
# @feature
```
  /
```
# @scenario
```
  comments needed (see
```
references/testing-conventions.md
```
  ).
Follow the conventions in
```
references/testing-conventions.md
```
for annotation format, e2e test style, and Generate vs Update path.
c. Write implementation code:
- Follow design.md decisions if available
- Keep changes minimal and focused on the scenario
- In no-test mode: still write implementation, just without preceding test
d. If using tasks.md: Mark task complete
```
- [ ]
```
->
```
- [x]
```
e. Continue to next

f. Scenario completion checklist (verify before moving to next scenario):
For
@e2e
scenarios (TDD mode):
- E2e test or step definition exists and is executable
- Test references the scenario (
```
@feature
```
  /
```
@scenario
```
  annotations or BDD binding)
- ```
# @covered-by: <path>
```
  annotation added to .feature file (between tag and Scenario line)
For
@behavior
scenarios (TDD mode):
- Test file exists with
```
@feature
```
  and
```
@scenario
```
  comments
- ```
# @covered-by: <path>
```
  annotation added to .feature file (between tag and Scenario line)
- Test is executable (not a skeleton)
For all scenarios:
- Implementation code handles the scenario's behavior
- Task checkbox marked complete (if using tasks.md)
Do NOT move to the next scenario until all applicable items are checked.

Pause if:
- Task/scenario is unclear -> ask for clarification
- Implementation reveals design issue -> suggest updating artifacts
- Error or blocker -> report and wait
E2E regression check (after all scenarios implemented)
If
```
@e2e
```
scenarios exist and
```
testing.e2e
```
is configured (or auto-detected):
- Run the full e2e test suite using the combined BDD feature paths
- If any failures → report and pause. Do NOT advance to verify phase.
- All passing → continue to completion.
Skip if no
```
@e2e
```
scenarios or no-test mode.

On completion or pause, show status

If all done: update

status.yaml

phase to

verify

## Implementation Complete

**Change:** <name>
**Scenarios:** N/N implemented with tests

Suggested next steps:
- `/beat:verify` -- validate implementation against artifacts
- `/beat:archive` -- sync features and archive the change

Testing Rule: Conditional TDD

In TDD mode (default when

testing.required

is true or unset):

For every Scenario in every .feature file: there MUST be a corresponding automated test
```
@e2e
```
scenarios → e2e test or step definitions (using project's e2e framework)
```
@behavior
```
scenarios → test with
```
@feature
```
/
```
@scenario
```
annotations +
```
@covered-by
```
comment in .feature
The test MUST be executable (not just a skeleton)
The test framework:
```
testing.behavior
```
(for @behavior) or
```
testing.e2e
```
(for @e2e) from config, or auto-detect from codebase
If the project has a BDD runner (Cucumber, pytest-bdd, etc.), generate step definitions that bind directly to .feature files

In proposal-driven mode (gherkin skipped):

Tests are driven by proposal.md success criteria and risk points
Each risk point should have corresponding test coverage
No annotation conventions (no features to link to)

In no-test mode (

testing.required: false

Tests are not required. Implementation code is written directly.
Developers may still write tests voluntarily using
```
testing.behavior
```
/
```
testing.e2e
```
if specified.

Guardrails

Never implement without reading artifacts first (features in gherkin-driven, proposal in proposal-driven)
In TDD mode: always write test before implementation
For
```
@behavior
```
scenarios: always add
```
@covered-by
```
annotation to .feature after writing the test
For
```
@behavior
```
scenarios: always add
```
@feature
```
/
```
@scenario
```
annotations in the test file
Keep each change scoped to one scenario/task
Update task checkbox immediately after completing each task
Pause on errors, blockers, or unclear requirements -- don't guess
If implementation reveals issues with features/design, suggest updating artifacts

dot

digraph apply {
    "Select change, read artifacts" [shape=box];
    "Invoke using-git-worktrees" [shape=box, style=bold];
    "testing.required false?" [shape=diamond];
    "No-test mode" [shape=box];
    "Invoke test-driven-development" [shape=box, style=bold];
    "Gherkin done?" [shape=diamond];
    "Gherkin-driven" [shape=box];
    "Proposal-driven" [shape=box];
    "tasks.md exists?" [shape=diamond];
    "Has Task N headings?" [shape=diamond];
    "Executor mode\nfollow tasks exactly" [shape=box];
    "Planner mode\nextract scenarios/criteria" [shape=box];
    "Implementation loop" [shape=box];
    "All tasks complete" [shape=doublecircle];

    "Select change, read artifacts" -> "Invoke using-git-worktrees";
    "Invoke using-git-worktrees" -> "testing.required false?";
    "testing.required false?" -> "No-test mode" [label="yes"];
    "testing.required false?" -> "Invoke test-driven-development" [label="no"];
    "No-test mode" -> "Gherkin done?";
    "Invoke test-driven-development" -> "Gherkin done?";
    "Gherkin done?" -> "Gherkin-driven" [label="yes"];
    "Gherkin done?" -> "Proposal-driven" [label="gherkin skipped"];
    "Gherkin-driven" -> "tasks.md exists?";
    "Proposal-driven" -> "tasks.md exists?";
    "tasks.md exists?" -> "Has Task N headings?" [label="yes"];
    "tasks.md exists?" -> "Planner mode\nextract scenarios/criteria" [label="no"];
    "Has Task N headings?" -> "Executor mode\nfollow tasks exactly" [label="yes"];
    "Has Task N headings?" -> "Planner mode\nextract scenarios/criteria" [label="no"];
    "Executor mode\nfollow tasks exactly" -> "Implementation loop";
    "Planner mode\nextract scenarios/criteria" -> "Implementation loop";
    "Implementation loop" -> "All tasks complete";
}

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

步骤

选择变更

若未提供名称：
- 查找
```
beat/changes/
```
  目录（排除
```
archive/
```
  ）
- 若仅存在一个目录，则使用该目录（告知："使用变更：<名称>"）
- 若存在多个目录，则使用AskUserQuestion工具让用户选择
读取status.yaml并验证就绪状态（ schema参考
```
references/status-schema.md
```
）
需满足以下任一条件：
- ```
gherkin
```
  的
```
status: done
```
  → Gherkin驱动模式
- ```
gherkin
```
  的
```
status: skipped
```
  且
```
proposal
```
  的
```
status: done
```
  → 提案驱动模式
若均不满足："实现前需完成功能或提案。请先运行
```
/beat:design
```
。" 停止执行。
读取所有工件并确定测试模式

读取顺序：
- ```
proposal.md
```
  （若存在）——业务上下文和风险点
- ```
features/*.feature
```
  （所有文件，若gherkin已完成）——实现目标
- ```
design.md
```
  （若存在）——技术决策
- ```
tasks.md
```
  （若存在）——实现检查清单
读取
```
beat/config.yaml
```
（若存在，schema参考
```
references/config-schema.md
```
）。
确定测试模式：
- 若
```
testing.required: false
```
  → 无测试模式：跳过所有场景的TDD循环，仅编写实现代码
- 若设置了
```
testing.behavior
```
  → 为
```
@behavior
```
  场景使用该框架（跳过自动检测）
- 若设置了
```
testing.e2e
```
  → 为
```
@e2e
```
  场景使用该框架（跳过自动检测）
- 若设置了
```
testing.framework
```
  （旧版） → 视为
```
testing.behavior
```
- 若
```
testing
```
  不存在或
```
testing.required: true
```
  → TDD模式（默认）：所有场景都需要测试
确定BDD功能路径（用于运行端到端测试）：
- 基础路径：
```
beat/features/
```
  （未变更的功能；
```
.feature.orig
```
  文件对BDD运行器不可见）
- 若
```
status.yaml
```
  中存在
```
gherkin.modified
```
  ：添加
```
beat/changes/<name>/features/
```
  （已修改和新增的功能）
- 调用BDD运行器时合并两个路径（例如：
```
npx cucumber-js beat/features beat/changes/<name>/features
```
  ）
确定实现策略

若tasks.md存在： 将其作为实现检查清单。
- 详细格式（包含
```
### Task N:
```
  标题及步骤）：进入执行器模式——严格按照编写的每个步骤执行，不要重新规划。
- 简单格式（仅包含
```
- [ ]
```
  复选框）：进入规划器模式——自行规划每个任务的实现（现有行为）。
若无tasks.md且为Gherkin驱动模式： 从功能文件中提取每个Scenario作为工作单元（规划器模式）。

若无tasks.md且为提案驱动模式： 从proposal.md中提取成功标准和风险点作为工作单元（规划器模式）。

展示实现概述

## 正在实现：<变更名称>

### 驱动模式：gherkin驱动 / 提案驱动
### 执行模式：执行器 / 规划器
### 待实现的任务/场景：
1. [来源] <名称>
2. [来源] <名称>
...

实现（循环）

针对每个任务（来自tasks.md）、场景（来自features）或风险点（来自proposal）：

a. 告知："正在处理：<描述>"

b. 先编写自动化测试（仅TDD模式）：
- 若为无测试模式则跳过此步骤
- 测试框架：根据场景标签使用配置中的
```
testing.behavior
```
  或
```
testing.e2e
```
  ，或从代码库自动检测
生成 vs 更新（详细参考
```
references/testing-conventions.md
```
）：
- 存在
```
@covered-by
```
  且测试文件已存在 → 更新：修改现有测试以反映新的场景步骤
- 存在
```
@covered-by
```
  但测试文件缺失 → 生成 + 警告（注释过时）
- 不存在
```
@covered-by
```
  → 生成：创建新测试（现有流程）
针对
@e2e
场景（Gherkin驱动模式）：
- 使用配置中的
```
testing.e2e
```
  框架或从代码库自动检测，生成（或更新）端到端测试或步骤定义
- 如果项目使用BDD运行器（Cucumber、pytest-bdd等），生成绑定到.feature文件的步骤定义
- 如果没有BDD运行器，生成带有
```
@feature
```
  /
```
@scenario
```
  注释的常规端到端测试（与
```
@behavior
```
  相同）
针对
@behavior
场景（Gherkin驱动模式）：
- 使用配置中的
```
testing.behavior
```
  或自动检测，生成带有注释的测试文件：
```
@feature: <功能文件名>.feature
@scenario: <精确场景名称>
```
  （使用项目语言的注释语法：JS/TS/Java/C#使用
```
//
```
  ，Python/Ruby使用
```
#
```
  等）
- 编写测试后，在.feature文件中添加
```
@covered-by
```
  注释（放在标签和场景行之间）：
  gherkin
```
@behavior @happy-path
# @covered-by: <测试文件相对路径>
Scenario: <名称>
```
针对提案驱动模式的单元：
- 使用项目的测试框架生成覆盖风险点的测试文件
- 无需注释约定（无功能文件可关联） 针对pytest-bdd项目：
```
@scenario
```
  装饰器可作为注释——无需单独的
```
# @feature
```
  /
```
# @scenario
```
  注释（参考
```
references/testing-conventions.md
```
  ）。
遵循
```
references/testing-conventions.md
```
中的注释格式、端到端测试风格以及生成/更新流程约定。
c. 编写实现代码:
- 若存在design.md，则遵循其中的决策
- 保持变更最小化，聚焦于当前场景
- 在无测试模式下：仍需编写实现代码，只是无需先写测试
d. 若使用tasks.md： 将任务标记为完成
```
- [ ]
```
->
```
- [x]
```
e. 继续下一个任务/场景

f. 场景完成检查清单（进入下一个场景前需验证）：
针对
@e2e
场景（TDD模式）：
- 端到端测试或步骤定义已存在且可执行
- 测试关联到场景（
```
@feature
```
  /
```
@scenario
```
  注释或BDD绑定）
- .feature文件中已添加
```
# @covered-by: <路径>
```
  注释（放在标签和Scenario行之间）
针对
@behavior
场景（TDD模式）：
- 测试文件已存在且包含
```
@feature
```
  和
```
@scenario
```
  注释
- .feature文件中已添加
```
# @covered-by: <路径>
```
  注释（放在标签和Scenario行之间）
- 测试可执行（非骨架）
针对所有场景：
- 实现代码能处理场景的行为
- 任务复选框已标记为完成（若使用tasks.md）
所有适用项检查完成前，请勿进入下一个场景。

暂停情况：
- 任务/场景不明确 → 请求澄清
- 实现过程中发现设计问题 → 建议更新工件
- 出现错误或障碍 → 报告并等待
端到端回归检查（所有场景实现完成后）
若存在
```
@e2e
```
场景且已配置
```
testing.e2e
```
（或自动检测到）：
- 使用合并后的BDD功能路径运行完整的端到端测试套件
- 若有任何失败 → 报告并暂停。请勿进入验证阶段。
- 全部通过 → 继续完成流程。
若无
```
@e2e
```
场景或处于无测试模式，则跳过此步骤。

完成或暂停时展示状态

若全部完成：将

status.yaml

的阶段更新为

verify

## 实现完成

**变更：** <名称>
**场景：** N/N 已实现并完成测试

建议下一步操作：
- `/beat:verify` -- 根据工件验证实现
- `/beat:archive` -- 同步功能并归档变更

测试规则：条件TDD

TDD模式（默认，当

testing.required

为true或未设置时）：

每个.feature文件中的每个Scenario：必须有对应的自动化测试
```
@e2e
```
场景 → 端到端测试或步骤定义（使用项目的端到端框架）
```
@behavior
```
场景 → 带有
```
@feature
```
/
```
@scenario
```
注释的测试 + .feature文件中的
```
@covered-by
```
注释
测试必须可执行（不能只是骨架）
测试框架：配置中的
```
testing.behavior
```
（针对@behavior）或
```
testing.e2e
```
（针对@e2e），或从代码库自动检测
如果项目使用BDD运行器（Cucumber、pytest-bdd等），生成直接绑定到.feature文件的步骤定义

提案驱动模式（跳过gherkin）：

测试由proposal.md的成功标准和风险点驱动
每个风险点应有对应的测试覆盖
无需注释约定（无功能文件可关联）

无测试模式（

testing.required: false

）：

无需测试。直接编写实现代码。
开发者仍可根据指定的
```
testing.behavior
```
/
```
testing.e2e
```
自愿编写测试。

防护措施

绝不在未读取工件前开始实现（Gherkin驱动模式读取功能文件，提案驱动模式读取提案）
TDD模式下：始终先写测试再实现
针对
```
@behavior
```
场景：编写测试后必须在.feature文件中添加
```
@covered-by
```
注释
针对
```
@behavior
```
场景：必须在测试文件中添加
```
@feature
```
/
```
@scenario
```
注释
每个变更的范围限定为一个场景/任务
完成每个任务后立即更新任务复选框
遇到错误、障碍或不明确需求时暂停——不要猜测
若实现过程中发现功能/设计存在问题，建议更新工件