菜单
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 分门槛用成主观印象，而不是明确评分