メニュー
Use when an approved go-symphony design or task exists, the next step is to claim one real task, and coordination is needed across workspace artifacts, OpenSpec state, code changes, and review gates.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when a go-symphony task is already implemented, a GitHub PR exists or must be opened, and follow-up work is still needed because Copilot or other AI review comments may arrive after the initial PR push.
Use when an approved go-symphony design exists but the design-task tracking doc is missing, stale, or too coarse to support safe task claiming and parallel work.
Use when go-symphony work starts from a broad goal, rewrite, migration, or multi-surface feature and the scope, parity requirements, or abstraction boundaries are still unclear.
| name | delivering-go-task-end-to-end |
| description | Use when an approved go-symphony design or task exists, the next step is to claim one real task, and coordination is needed across workspace artifacts, OpenSpec state, code changes, and review gates. |
把一个已经认领的 go-symphony 任务从调研推进到关闭，同时避免 task 状态、spec 状态、代码状态和 review 状态彼此漂移。
核心原则： 只有当仓库产物、验证证据、OpenSpec 状态和任务板状态全部一致时，这个任务才算真正完成。
隔离规则： 从任务启动开始，后续 research、spec、实现、验证和 review 都必须在隔离的 git worktree 中进行，避免与同仓其他进行中的任务互相污染。
REQUIRED SUB-SKILLS: using-git-worktrees, deriving-task-board-from-design, openspec-explore, openspec-ff-change, openspec-apply-change, openspec-sync-specs, openspec-archive-change, test-driven-development, requesting-code-review, receiving-code-review, verification-before-completion
每个阶段切换前，都先更新 task 文档，再进入下一阶段。
在这些场景使用：
docs/plans/*-design.md这些场景不要使用：
deriving-task-board-from-designcompatibility-first-planning这里的“大阶段”包括：方案澄清、spec 与测试策略、代码实现、代码校验/review、最终对比与遗留风险梳理。
每个大阶段都必须按这个顺序执行：
不要只做“执行”，不做阶段性审核；也不要为了测试而测试，或者因为时间压力跳过复验。
对于一个已认领任务，其 workspace/<task-id>/ 至少应包含：
original_impl.mdnew_impl.mdfinal_impl_v1.mdfinal_impl.mdtest_strategy.mdtodo.md，当 review、对比或 parity 仍有遗留时如果这些文件不存在，就不要宣称对应阶段已经完成。
阶段目标：
执行：
*-design-task.md。deriving-task-board-from-design。status=todo 且所有硬依赖都已经 done。workspace/<task-id>/、开始 research、创建 OpenSpec change 或写任何实现代码之前，必须先调用 using-git-worktrees 创建隔离 worktree。claimed。workspace/<task-id>/。research。校验：
workspace/<task-id>/ 真实存在Owner、Claimed At 已落盘阶段验收阈值：
using-git-worktrees 建好并完成基线校验research修复与复验：
默认规则：
在每次状态切换时，都要往 Change Log 里追加一条简短记录，保证历史不依赖聊天上下文。
阶段目标：
执行：
subagent 1：使用 openspec-explore，查看 /Users/lihui/Documents/GitHub/symphony，输出到 workspace/<task-id>/original_impl.mdsubagent 2：使用 openspec-explore，查看当前 go-symphony 现状，输出到 workspace/<task-id>/new_impl.mdsubagent 3：结合任务目标和前两份结果，整合为 workspace/<task-id>/final_impl_v1.md随后，至少再启动 2+ 个 review subagent 评审 final_impl_v1.md。
审核评分规则：
| 维度 | 分值 |
|---|---|
| Symphony 对齐度与来源忠实度 | 30 |
| Go-native 简洁性与可维护性 | 20 |
| 不过度设计 / 边界是否干净 | 20 |
| 实现清晰度与可测试性 | 15 |
| 验证覆盖与落地安全性 | 15 |
阶段验收阈值：
>= 80修复与复验：
80 分，或存在高严重度问题，就修改 final_impl_v1.md 并重新评审workspace/<task-id>/final_impl.md当 final_impl.md 被接受后，把任务状态更新为 spec。
阶段目标：
final_impl.md 变成可执行的 OpenSpec change执行：
openspec-ff-change，根据 final_impl.md 创建该任务的 change 和 spec 产物。workspace/<task-id>/test_strategy.md，把功能目标映射到编译、lint、单测、e2e、关键集成验证。final_impl.md、新 spec 产物和 test_strategy.md 做 spec review。高严重度 spec 问题的判定：
final_impl.md 不一致test_strategy.md 无法证明关键功能能正常运转，只是在堆测试数量阶段验收阈值：
test_strategy.md 能解释每类测试在证明什么，而不是机械罗列修复与复验：
test_strategy.md不要让 final_impl.md、spec 产物、test_strategy.md 和 task 文档互相打架。
当实现真正开始时，把任务状态更新为 implementing。
阶段目标：
执行规则：
openspec-apply-changetest-driven-development不要把多个并行 agent 扔到同一组文件上。
阶段目标：
执行：
verifying审核：
verification-before-completiontest_strategy.md 检查：当前验证是否真的覆盖了任务要证明的功能阶段验收阈值：
workspace/<task-id>/todo.md 和 task 文档中写清理由修复与复验：
test_strategy.md 和测试本身，再继续阶段目标：
执行：
reviewrequesting-code-review 运行 reviewreceiving-code-review 评估 review 建议问题分流规则：
workspace/<task-id>/todo.md阶段验收阈值：
修复与复验：
阶段目标：
执行：
在标记任务为 done 之前，必须依次完成：
workspace/<task-id>/todo.md。openspec-sync-specs。openspec-archive-change。done。审核：
阶段验收阈值：
修复与复验：
只要 task board、workspace 产物、spec 和代码里还有任一处不一致，这个任务就不算完成。
| 阶段 | 最小证据 |
|---|---|
claimed | worktree 已就绪，task 文档已更新，且 workspace/<task-id>/ 已存在 |
research | original_impl.md + new_impl.md，且这些产物生成于该任务的隔离 worktree |
spec | final_impl.md + OpenSpec change + test_strategy.md |
implementing | 代码实现已在对应 change 下展开 |
verifying | lint/build/tests 已执行，并能解释它们证明了什么 |
review | review 发现已记录并完成分流 |
done | final compare 完成，sync + archive 完成，task 文档已更新 |
如果出现这些情况，就暂停并纠正流程：
workspace/<task-id>/final_impl.md 没经过带 rubric 的评审就被接受test_strategy.md 只是列测试，不解释这些测试证明什么done80 分门槛用成主观印象，而不是明确评分