القائمة
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.
التثبيت باستخدام 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 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.
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 | deriving-task-board-from-design |
| description | 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. |
把已批准的设计文档整理成可执行的任务板，而不是再写一份“第二设计文档”。
核心原则： 任务 ID、依赖边和状态历史是执行期真相源，不能依赖聊天记忆。
这个 skill 负责创建或刷新 docs/plans/*-design-task.md，不负责真正实现某个任务。
在这些场景使用：
docs/plans/*-design.md 已经批准，准备进入实现docs/plans/*-design-task.md 还不存在这些场景不要使用：
compatibility-first-planningdelivering-go-task-end-to-end在落笔之前，先做这些检查：
*-design.md -> *-design-task.md。不要凭记忆认领任务、重排任务 ID，或推进任务状态。
任务文档要短、清晰、偏执行。固定包含这些 section：
Source DesignStatus LegendDependency RulesTask TableClaiming RulesChange LogTask Table 保持最小化：
| ID | Title | Goal | Depends On | Parallel | Status | Owner | Claimed At | Workspace | Change | Done When | Notes |
|---|
读取已批准的设计文档，并抽出这些内容：
如果设计里已经有 T01 到 T18 这类 ID，优先复用，不要随意重排。
如果任务文档不存在：
10-20如果任务文档已存在：
Change Log 里写明原因每个任务都要有：
Done WhenNotes 里写出第一个预期验证命令或 gate“ready” 应该是推导结果，而不是单独状态：
ready 的含义是 status=todo 且所有硬依赖都已 done不要再引入单独的 ready 状态。
状态集固定为：
todoclaimedresearchspecimplementingverifyingreviewblockeddoneblocked 可以打断任何活动状态。解除阻塞后，要回到之前的工作状态。
把这个原状态记录在 Notes 中，例如 resume_to=implementing。
认领必须遵守这些规则：
todo 且所有硬依赖都已 done 的任务Owner 和 Claimed Atworkspace/<task-id>/Change Log 中追加认领记录如果要选“下一个任务”，优先选未阻塞、能解锁更多后续工作的高杠杆任务。
刷新已有 task 文档时，要以证据为准：
workspace/<task-id>/ 文件当证据冲突时，按这个优先级判断：
如果任务被标成 claimed 或 done，但证据缺失，不要默认沿用旧状态。保留历史，但要在 Notes 或 Change Log 里显式说明回退或阻塞。
如果一个被标成 done 的任务被证伪，就回退到“仍然有证据支持的最高状态”：
reviewverifyingimplementingspecresearchclaimedtodo不要因为聊天里说“做完了”，就把任务标成 done 或推进状态。
| 场景 | 动作 |
|---|---|
| task 文档不存在 | 从已批准设计创建 *-design-task.md |
| task 文档存在但过时 | 刷新它，且不要改动稳定任务 ID |
任务依赖都完成且状态是 todo | 它是可认领的 |
| 任务已经被认领 | workspace/<task-id>/ 必须真实存在 |
| 设计中的粗任务已经够好 | 直接复用，不要再发明新 ID |
Done When，让完成条件变主观当 task 文档已经初始化或刷新完成后，使用 delivering-go-task-end-to-end 去认领并执行某一个任务。