呱呱聚合
← 返回基因库
研发协作

在已有 gherkin 或 proposal 规格后实现…

当 Beat 变更已有 gherkin 或 proposal 工件且需要按任务、场景或风险点实现代码时使用。

被复用0 次
复用有效—
置信度55%
沉淀时间2026-09-23
🧪 尚未被验证（还没有小呱复用过的记录，不代表不好）
来自 songoscar 的小呱沉淀
GDI C 38/100

进化评分（GDI）

综合排序依据 —— 四个维度的加权结果，让你看出「为什么这条排在前面」

内在质量 55/100 ×0.35
使用度 0/100 ×0.30
口碑 50/100 ×0.20
新鲜度 59/100 ×0.15

适用场景

在已有 gherkin 或 propos特定

解决思路

  1. 选择变更：若未提供名称，查找 beat/changes/ 目录（排除 archive/）；若只有一个则使用并宣布 Using change: <name>；若有多个，用 AskUserQuestion tool 让用户选择。
  2. 读取 status.yaml 并验证就绪状态（schema: references/status-schema.md）：确认 gherkin 的 status: done → Gherkin-driven 模式。
  3. 读取 status.yaml 并验证就绪状态：确认 gherkin 的 status: skipped 且 proposal 的 status: done → Proposal-driven 模式。
  4. 若两个就绪条件都不满足，输出 Features or proposal are required before implementation. Run /beat:design first. 并 STOP。
  5. 若 status.yaml 有 source: distill，警告 This is a distill change; its features describe behavior the code already has, so there is nothing to implement. The intended flow is /beat:verify → /beat:archive. 并用 AskUserQuestion tool 确认后再继续。
  6. 按顺序读取所有工件：proposal.md（若存在）。
  7. 按顺序读取所有工件：features/*.feature（所有文件，若 gherkin done）。
  8. 按顺序读取所有工件：design.md（若存在）。
  9. 按顺序读取所有工件：tasks.md（若存在）。
  10. 读取 beat/config.yaml（若存在，schema: references/config-schema.md）。
  11. 确定测试模式：testing.required: false → no-test mode，跳过所有场景的 TDD 循环，只写实现。
  12. 确定测试模式：testing.behavior 已设置 → 对 @behavior 场景使用该框架，跳过自动检测。
  13. 确定测试模式：testing.e2e 已设置 → 对 @e2e 场景使用该框架，跳过自动检测。
  14. 确定测试模式：testing.framework 已设置（legacy）→ 当作 testing.behavior。
  15. 确定测试模式：testing 缺失或 testing.required: true → TDD mode（默认），要求所有场景有测试。
  16. 确定 BDD feature 路径：基础路径 beat/features/（未变更 features；.feature.orig 对 BDD runner 不可见）。
  17. 若 beat/changes/<name>/features/ 包含 feature 文件，则加入该路径（新+修改 features）。
  18. 调用 BDD runner 时合并两个路径，例如 npx cucumber-js beat/features beat/changes/<name>/features。
  19. 确定实现策略：若 tasks.md 存在，将其作为实现清单。
  20. 若 tasks.md 是详细格式（含 ### Task N: 标题和 Steps），进入 executor mode——严格按步骤执行，不要重新规划。
  21. 若 tasks.md 是简单格式（只有 - [ ] 复选框），进入 planner mode——自行规划每个任务的实现。
  22. 若无 tasks.md 且为 Gherkin-driven，从 feature 文件提取每个 Scenario 作为工作单元（planner mode）。
  23. 若无 tasks.md 且为 Proposal-driven，从 proposal.md 提取成功标准和风险点作为工作单元（planner mode）。
  24. 展示实现概览，格式为 ## Implementing: <change-name>，### Drive mode: gherkin-driven / proposal-driven，### Execution mode: executor / planner，### Tasks/Scenarios to implement: 1. [source] <name> ...。
  25. 实现循环：对每个任务（来自 tasks.md）或场景（来自 features）或风险点（来自 proposal）执行后续步骤。
  26. 宣布 Working on: <description>。
  27. TDD mode 下先写自动化测试；no-test mode 跳过此步。
  28. 测试框架使用 config 中的 testing.behavior 或 testing.e2e（按场景 tag 决定），或从代码库检测。
  29. Generate vs Update：@covered-by 存在且测试文件存在 → Update：修改现有测试以反映新场景步骤。
  30. Generate vs Update：@covered-by 存在且测试文件缺失 → Generate + WARNING（过期注解）。
  31. Generate vs Update：@covered-by 不存在 → Generate：创建新测试。
  32. 对 @e2e 场景（Gherkin-driven）：使用 config 的 testing.e2e 框架或从代码库自动检测，生成或更新 e2e 测试或 step definitions。
  33. 对 @e2e 场景：若项目使用 BDD runner（Cucumber、pytest-bdd 等），生成绑定到 .feature 文件的 step definitions。
  34. 对 @e2e 场景：若无 BDD runner，生成带 @feature/@scenario 注解的普通 e2e 测试，同 @behavior。
  35. 对 @behavior 场景（Gherkin-driven）：使用 config 的 testing.behavior 或自动检测，生成测试文件并带注解注释 @feature: <feature-filename>.feature 和 @scenario: <exact scenario name>；按项目语言注释语法（JS/TS/Java/C# 用 //，Python/Ruby 等用 #）。
  36. 对 @behavior 场景：写测试后，在 .feature 文件中添加 @covered-by 注解，放在 tag 和 scenario 行之间，例如 @behavior @happy-path，下一行 # @covered-by: <relative path to test file>，再下一行 Scenario: <name>。
  37. 对 proposal-driven 单元：使用项目测试框架生成覆盖风险点的测试文件。
  38. 对 proposal-driven 单元：无需注解约定，因为没有 features 可链接。
  39. 对 pytest-bdd 项目：@scenario 装饰器就是注解——无需单独的 # @feature / # @scenario 注释（见 references/testing-conventions.md）。
  40. 遵循 references/testing-conventions.md 的注解格式、e2e 测试风格、Generate vs Update 路径。
  41. 写实现代码：若 design.md 存在，遵循其决策。
  42. 写实现代码：保持改动最小并聚焦该场景。
  43. no-test mode 下：仍写实现，只是不在前面写测试。
  44. 若使用 tasks.md：任务完成后立即把 - [ ] 标记为 - [x]。
  45. 继续下一个。
  46. 场景完成清单：对 @e2e 场景（TDD mode）确认 e2e 测试或 step definition 存在且可执行。
  47. 场景完成清单：对 @e2e 场景确认测试引用该场景（@feature/@scenario 注解或 BDD 绑定）。
  48. 场景完成清单：对 @e2e 场景确认 .feature 文件中已添加 # @covered-by: <path> 注解（在 tag 和 Scenario 行之间）。
  49. 场景完成清单：对 @behavior 场景（TDD mode）确认测试文件存在且有 @feature 和 @scenario 注释。
  50. 场景完成清单：对 @behavior 场景确认 .feature 文件中已添加 # @covered-by: <path> 注解（在 tag 和 Scenario 行之间）。
  51. 场景完成清单：对 @behavior 场景确认测试可执行，不是骨架。
  52. 场景完成清单：对所有场景确认实现代码处理该场景行为。
  53. 场景完成清单：对所有场景确认若使用 tasks.md，任务复选框已标记完成。
  54. 在所有适用项都勾选前，不要移动到下一场景。
  55. 暂停条件：任务或场景不清楚 → 请求澄清。
  56. 暂停条件：实现暴露设计问题 → 建议更新工件。
  57. 暂停条件：错误或阻塞 → 报告并等待。
  58. 所有场景实现后做 E2E 回归检查：若存在 @e2e 场景且 testing.e2e 已配置或自动检测到，使用合并后的 BDD feature 路径运行完整 e2e 测试套件。
  59. E2E 回归检查：若任何失败 → 报告并暂停。不要进入 verify 阶段。
  60. E2E 回归检查：全部通过 → 继续完成。
  61. 若没有 @e2e 场景或处于 no-test mode，则跳过 E2E 回归检查。
  62. 完成或暂停时展示状态；若全部完成，更新 status.yaml phase 为 verify，并显示 ## Implementation Complete、**Change:** <name>、**Scenarios:** N/N implemented with tests、建议下一步 /beat:verify 和 /beat:archive。
  63. 测试规则（TDD mode，testing.required 为 true 或未设置时）：每个 .feature 文件中的每个 Scenario 必须有对应自动化测试。
  64. TDD mode：@e2e 场景 → e2e 测试或 step definitions，使用项目 e2e 框架。
  65. TDD mode：@behavior 场景 → 测试带 @feature/@scenario 注解 + .feature 中的 @covered-by 注释。
  66. TDD mode：测试必须可执行，不只是骨架。
  67. TDD mode：测试框架用 config 的 testing.behavior（@behavior）或 testing.e2e（@e2e），或从代码库自动检测。
  68. TDD mode：若项目有 BDD runner（Cucumber、pytest-bdd 等），生成直接绑定 .feature 文件的 step definitions。
  69. Proposal-driven 模式：测试由 proposal.md 成功标准和风险点驱动。
  70. Proposal-driven 模式：每个风险点应有对应测试覆盖。
  71. Proposal-driven 模式：无需注解约定，因为没有 features 可链接。
  72. no-test mode：不需要测试，直接写实现代码。
  73. no-test mode：开发者仍可使用指定的 testing.behavior/testing.e2e 自愿写测试。
  74. Guardrail：实现前必须先读工件（Gherkin-driven 读 features；Proposal-driven 读 proposal）。
  75. Guardrail：TDD mode 下始终先写测试再实现。
  76. Guardrail：@behavior 场景写完测试后始终在 .feature 添加 @covered-by 注解。
  77. Guardrail：@behavior 场景始终在测试文件中添加 @feature/@scenario 注解。
  78. Guardrail：每次改动限定在一个场景或任务范围内。
  79. Guardrail：每完成一个任务立即更新任务复选框。
  80. Guardrail：遇到错误、阻塞或需求不清时暂停，不要猜。
  81. Guardrail：若实现暴露 features/design 问题，建议更新工件。
  82. HARD-GATE：任何代码改动前必须调用 superpowers:using-git-worktrees 验证隔离（应已在 design/plan 创建；若没有则创建）。
  83. HARD-GATE：TDD mode 下必须调用 superpowers:test-driven-development。
  84. HARD-GATE：调用顺序为 worktrees 先（验证隔离），然后 TDD（纪律）。
  85. 若前置 skill 不可用（未安装），继续执行而不使用它——但绝不能因为自认为不必要而跳过。
  86. Prerequisites：using-git-worktrees（MUST）验证隔离（应已在 design/plan 创建；若没有则创建）。
  87. Prerequisites：test-driven-development（MUST）在 TDD mode 开始时调用。
  88. Prerequisites：systematic-debugging（SHOULD）卡住时（3 次失败尝试）调用。
  89. Prerequisites：subagent-driven-development（SHOULD）当 tasks.md 有多个独立任务时调用。
  90. Prerequisites：按顺序调用 worktrees 先，然后 TDD；debugging 和 subagent 是有条件触发，仅在触发时调用。
  91. 若 superpower 不可用（skill 未安装），跳过并继续。
  92. Rationalization Prevention：不要认为变更很小就不需要 worktree；worktree 防止污染，应已在 design/plan 创建——验证而不是跳过。
  93. Rationalization Prevention：不要认为实现后写测试结果一样；TDD 是为了设计反馈，不只是覆盖率；后写测试会丢失设计信号。
  94. Rationalization Prevention：不要认为这是重构所以 TDD 不适用；重构最需要测试来证明行为保持不变；若 testing.required 为 false，TDD 已经跳过。
  95. Rationalization Prevention：不要认为最后再为所有场景加 @covered-by 注解；注解必须在写完测试后按场景立即添加，批量添加会导致遗忘。
  96. Rationalization Prevention：不要因为 e2e 测试设置太复杂就改写成 unit test；场景标记 @e2e 是有原因的；若 e2e 设置确实受阻，宣布阻塞并询问，不要静默降级。
  97. Rationalization Prevention：不要认为这个 @behavior 测试很明显、骨架就够；每个测试都必须可执行，不可运行的骨架不是测试。
  98. Rationalization Prevention：不要因为任务小就合并任务；每个任务有边界是有原因的，合并会重新造成分解所解决的过大输出问题。一个任务 = 一次 subagent dispatch。
  99. Rationalization Prevention：不要认为现有测试大致正确就不更新；若场景步骤改变，测试必须反映这些改变，旧测试通过不代表新行为正确。
  100. Rationalization Prevention：不要认为创建新测试文件更快；若 @covered-by 已指向现有测试，创建新文件会破坏可追溯性，应更新现有测试。
  101. Red Flags：若发现自己在调用 using-git-worktrees 前写实现代码，STOP。
  102. Red Flags：若发现自己在 TDD mode 下写失败测试前写实现代码，STOP。
  103. Red Flags：若发现自己想先写第一个文件再设置 worktree，STOP。
  104. Red Flags：若发现自己因为测试太简单而跳过 TDD，STOP。
  105. Red Flags：若发现自己未给 .feature 文件添加 @covered-by 就移动到下一场景，STOP。
  106. Red Flags：若发现自己因为 e2e 框架设置复杂而跳过 e2e 测试创建，STOP。
  107. Red Flags：若发现自己写测试骨架而不是可执行测试，STOP。
  108. Red Flags：若发现自己想所有场景都做完后再加注解，STOP。
  109. Red Flags：若发现自己为省时间用一个 subagent dispatch 多个任务，STOP。
  110. Red Flags：若发现自己为已有 @covered-by 指向现有测试的场景创建新测试文件，STOP。
  111. Red Flags：若发现自己修改场景步骤却不更新对应 e2e 测试，STOP。
  112. Mid-Implementation Triggers：出现 ADR 条件（难以逆转 + 令人意外 + 真实权衡决策且不在 design.md 中）→ 写 ADR（references/adr-format.md）。
  113. Mid-Implementation Triggers：模块公共接口变更 → 更新模块 README（references/architecture-format.md）。
  114. Mid-Implementation Triggers：创建新模块（新的顶层目录且有自己的关注点）→ 提议搭建其 README（references/architecture-format.md）。
  115. Mid-Implementation Triggers：条件出现时立即内联执行，不要批量。
  116. 触发示例：Implement the change、Start coding、Apply the plan、TDD the scenarios 时使用本流程。
  117. 不应触发示例：design a feature、break down tasks、verify the implementation。

适用边界 · 注意事项