Claude Code Task System 工作流分析¶

分析目的¶

研究 CJ Hess 提出的 Claude Code task system（協調層）如何應用到我們現有的 Claude Code Planning 工作流，識別： 1. 可以直接採用的概念 2. 需要調整的部分 3. 與現有工具（brainstorming、planning-with-files、OpenSpec）的整合點 4. 潛在衝突與解決方案

注意： 此文件是分析與設計，不是實作指南。實作前需進一步驗證。

現有工作流回顧¶

目前的 Claude Code Planning 三階段¶

參考： ~/clawd/WORKFLOW.md

階段 1：Brainstorming（Superpowers Skill）¶

探索可能性、收集需求
產出：brainstorming.md

階段 2：Planning¶

小功能/探索： planning-with-files → task_plan.md
大功能/正式規格： OpenSpec (OPSX) → tasks.md

階段 3：Execution¶

Claude Code 參考 planning 產出執行
追蹤進度：progress.md、findings.md

關鍵約束（防衝突規則）¶

❌ 不要同時建立 task_plan.md 和 tasks.md
✅ 使用 OpenSpec 時，planning-with-files 只建立 findings.md + progress.md
✅ OpenSpec tasks.md = 任務清單，progress.md = 執行日誌

Task System 核心概念回顧¶

1. 協調層（Coordination Layer）¶

不是： To-do list
是：多 agent 協調機制

特性： - 每個 task 可 spawn 獨立 sub-agent（200k context） - Dependencies (blockedBy) 強制執行順序 - Free parallelism（7-10 agents 同時運行） - Persistence（跨 session 存活）

2. 結構強制正確性¶

關鍵洞察：
依賴圖存在於 Claude 的 context window 之外 → 不會忘記、不會漂移

vs 舊方法：
計劃存在 Claude 腦中 → context 滿後降級、/clear 後遺失

3. Multi-layer Swarms（未來）¶

目前（Layer 2）：
你 → Claude → sub-agents

未來（Layer 3+）：
Sub-agents 可以再 spawn sub-agents

應用到我們工作流的可能性¶

方案 A：Task System 作為 Planning 的替代品¶

概念：
直接用 Claude Code task system 取代 task_plan.md / tasks.md

優勢： - ✅ 持久化（不怕 session restart） - ✅ 依賴強制執行（結構確保正確性） - ✅ 並行化（加速執行） - ✅ 隔離 context（每個 task 獨立思考）

挑戰： - ❌ 與 OpenSpec 衝突 — OpenSpec 已有 tasks.md 格式（Markdown table） - ❌ brainstorming → task system 的轉換 — 誰負責把 brainstorming.md 轉成 task dependencies？ - ❌ DyDo 的角色 — DyDo 規劃後，如何傳遞給 Claude Code task system？

結論： 可行，但需要重新設計整個 planning → execution 流程。

方案 B：Task System 作為 Execution 層的增強¶

概念：
保留現有 planning（brainstorming + planning-with-files / OpenSpec），
但在 Claude Code execution 時使用 task system 協調 sub-agents

流程：

Planning（DyDo 負責）：
Brainstorming → brainstorming.md
Planning-with-files → task_plan.md 或 OpenSpec → tasks.md
重點： 識別可並行的任務、定義依賴關係
Handoff（DyDo → Claude Code）：
DyDo 啟動 Claude Code session
Prompt 包含：task_plan.md / tasks.md + 建議的 task dependencies

例如：

參考 task_plan.md，請建立 task system：
- Task 1: 實作 auth middleware（無依賴）
- Task 2: 實作 login endpoint（blockedBy: 1）
- Task 3: 實作 logout endpoint（blockedBy: 1）
- Task 4: 寫測試（blockedBy: 2, 3）

Execution（Claude Code + Task System）：
Claude Code 建立 task dependencies
Spawn sub-agents 並行執行 Task 1, 2, 3（若無依賴）
Task 4 等 2, 3 完成後自動啟動

優勢： - ✅ 保留現有 planning 工具（無衝突） - ✅ DyDo 仍然負責「定義問題清晰到 swarm 能解決」 - ✅ Claude Code 專注執行（利用 task system 加速） - ✅ 階段分離清楚：Planning（思考） vs Execution（行動）

挑戰： - ⚠️ DyDo 需要學會「思考依賴」 — 不只是步驟，而是「哪些可並行、哪些必須順序」 - ⚠️ Prompt 設計 — 如何清楚傳遞依賴資訊給 Claude Code？ - ⚠️ Monitoring — DyDo 如何監控 sub-agents 進度？（目前只看 bubble）

結論： 這是最務實的方案。增強 execution，不破壞現有 planning。

方案 C：Hybrid（Planning 定義高層 tasks，Execution 細化成 sub-tasks）¶

概念：
Planning 定義高層任務（例如「實作 auth 系統」），
Claude Code execution 時自己拆解成 sub-tasks（login, logout, sessions）

流程：

Planning（DyDo）：

產出 task_plan.md：

1. 實作 auth 系統
2. 實作 API endpoints
3. 寫測試

Execution（Claude Code + Task System）：
Claude Code 看到「實作 auth 系統」
自己拆解成 sub-tasks：
- 1.1 Login endpoint
- 1.2 Logout endpoint
- 1.3 Session middleware
- ...（建立依賴關係）
Spawn sub-agents 並行執行
Multi-layer：
Layer 1（DyDo）：高層任務定義
Layer 2（Claude Code main）：拆解成 sub-tasks
Layer 3（Sub-agents）：執行具體 sub-tasks

優勢： - ✅ DyDo 專注高層規劃（不需要細化到每個 function） - ✅ Claude Code 自主拆解（利用其對代碼的理解） - ✅ 真正的 multi-layer swarms（符合 CJ 的願景）

挑戰： - ❌ 複雜度 — 三層架構，難以追蹤 - ❌ 控制 — DyDo 失去對細節的掌控 - ❌ 目前不支援 — Claude Code sub-agents 還不能再 spawn sub-agents（Layer 3）

結論： 未來可能，但目前技術還沒到位。

建議採用的方案¶

階段性實施：方案 B → 方案 C¶

短期（立刻可做）：方案 B¶

目標： 在 execution 層使用 task system，不改變 planning 流程

實施步驟：

DyDo Planning 時增強依賴分析：
Brainstorming 後，識別哪些任務可並行
Planning 時明確標注依賴關係

產出範例：

## 任務列表

### Phase 1（可並行）
- [ ] Task 1: 實作 auth middleware
- [ ] Task 2: 實作 database schema

### Phase 2（依賴 Phase 1）
- [ ] Task 3: 實作 login endpoint（依賴 Task 1）
- [ ] Task 4: 實作 user CRUD（依賴 Task 2）

### Phase 3（依賴 Phase 2）
- [ ] Task 5: 整合測試（依賴 Task 3, 4）

啟動 Claude Code 時傳遞依賴資訊：

Prompt 範本：

參考 task_plan.md 的任務列表。

請使用 task system 建立以下 tasks：
- Task 1: 實作 auth middleware（無依賴）
- Task 2: 實作 database schema（無依賴）
- Task 3: 實作 login endpoint（blockedBy: 1）
- Task 4: 實作 user CRUD（blockedBy: 2）
- Task 5: 整合測試（blockedBy: 3, 4）

請並行執行可並行的任務。

監控與追蹤：
DyDo 定期檢查 ~/.claude/tasks/<project>/ 的任務狀態
有 blocker 時立刻通知 Hsc

中期（技術成熟後）：方案 C¶

前提： Claude Code sub-agents 支援再 spawn sub-agents（Layer 3）

實施： - DyDo 只定義高層任務（「實作 auth 系統」） - Claude Code 自主拆解成 sub-tasks - Sub-agents 各自執行

與現有工具的整合點¶

1. Brainstorming Skill（Superpowers）¶

整合點：
Brainstorming 產出的「可能性探索」可以標註依賴關係

增強： - 問題：「這些功能哪些可以並行開發？」 - 產出：依賴關係圖

2. Planning-with-files¶

整合點：
task_plan.md 格式可以增強，明確標註依賴

範本更新：

## 任務與依賴

| Task | Description | Dependencies | Can Parallel |
|------|-------------|--------------|--------------|
| 1 | Auth middleware | - | ✅ |
| 2 | DB schema | - | ✅ |
| 3 | Login endpoint | Task 1 | ❌ |
| 4 | User CRUD | Task 2 | ❌ |
| 5 | Tests | Task 3, 4 | ❌ |

3. OpenSpec (OPSX)¶

整合點：
tasks.md 已經是任務列表，可以增強成依賴格式

挑戰： - OpenSpec 格式是 Markdown table - Task system 用 JSON - 需要轉換層

可能解法： - DyDo 讀取 OpenSpec tasks.md - 轉換成 task system JSON prompt - 傳遞給 Claude Code

潛在衝突與解決方案¶

衝突 1：`tasks.md` 格式不同¶

問題： - OpenSpec tasks.md = Markdown table - Task system = JSON / internal format

解法： - 保持分離 — OpenSpec tasks.md 是 planning artifact - Claude Code task system 是 execution artifact - DyDo 讀取 OpenSpec，轉換成 task system prompt

衝突 2：誰負責拆解任務？¶

問題： - Planning 階段拆解 vs Execution 階段拆解

解法（方案 B）： - Planning（DyDo）： 高層任務 + 依賴關係 - Execution（Claude Code）： 細化實作細節

解法（方案 C，未來）： - Planning（DyDo）： 只定義高層目標 - Execution（Claude Code）： 完全自主拆解

衝突 3：monitoring 與控制¶

問題： - DyDo 如何監控 7-10 個並行 sub-agents？

解法： - 方案 1（簡單）： 只監控主 session 的 bubble - 方案 2（進階）： DyDo 定期讀取 ~/.claude/tasks/<project>/ 檢查狀態 - 方案 3（理想）： Task system 提供 API / webhook 通知進度

學習與適應¶

DyDo 需要學會的新技能¶

依賴分析：
不只是「步驟 1, 2, 3」
而是「1 和 2 可並行，3 依賴 1 和 2」
Prompt 設計：
如何清楚傳遞依賴資訊給 Claude Code
如何提示「請使用 task system 並行執行」
監控技巧：
檢查 ~/.claude/tasks/<project>/ 的任務狀態
識別 blockers 並報告

Hsc 需要的新習慣¶

設定環境變數：

export CLAUDE_CODE_TASK_LIST_ID="<project-name>"

使用 Ctrl+T：
檢查 task view
審查依賴圖
信任並行化：
不用擔心「會不會亂掉」
結構強制正確性

實驗建議（先不實作，但可以測試）¶

實驗 1：手動測試 task system¶

目的： 理解 task system 實際運作

步驟： 1. 選一個小專案（例如實作簡單 API） 2. 手動定義 tasks + dependencies 3. 啟動 Claude Code，明確要求使用 task system 4. 觀察： - 是否真的並行？ - 依賴是否正確強制執行？ - Persistence 是否可靠？

預期學習： - Task system 的實際表現 - Prompt 如何影響 task 拆解 - 哪些任務適合並行

實驗 2：DyDo 生成 task dependencies¶

目的： 測試 DyDo 是否能正確分析依賴

步驟： 1. 給 DyDo 一個任務（例如「實作 auth 系統」） 2. 要求產出：任務列表 + 依賴關係 3. 人工審查：依賴是否合理？有無遺漏？

預期學習： - DyDo 對依賴分析的能力 - 需要哪些 prompt 改進

實驗 3：整合測試（Planning → Execution）¶

目的： 端到端測試整個流程

步驟： 1. DyDo 完成 planning（brainstorming + planning-with-files） 2. DyDo 生成 task dependencies 3. 啟動 Claude Code，傳遞 dependencies 4. 觀察執行過程 5. 記錄問題與改進點

預期學習： - 整個流程是否順暢？ - 哪裡需要人工干預？ - 是否真的加速開發？

與宝玉經驗的對比¶

宝玉的 6 條建議 vs Task System¶

參考：Claude Code 上下文管理

宝玉建議	Task System 如何實現	額外價值
1. 關掉自動壓縮	Sub-agents 獨立 context，不需壓縮	✅ 結構化解決
2. 中間結果存文件	Task completion 自動保存狀態	✅ 自動化
3. 一個會話只做一件事	每個 sub-agent 專注一個 task	✅ 強制執行
4. 長任務用總結接力	Dependencies 自動接力	✅ 無需手動總結
5. 一定要用 Git	仍然需要（task system 不取代 Git）	⚠️ 互補
6. 卡住了別硬扛	Task 失敗 → 重新 spawn，不影響其他	✅ 隔離失敗

結論： Task system 自動化了宝玉建議的大部分最佳實踐。

潛在風險與緩解¶

風險 1：過度依賴並行化¶

問題： 不是所有任務都適合並行

緩解： - Planning 時謹慎評估依賴 - 不確定時選擇順序執行（保守策略）

風險 2：成本爆炸¶

問題： 7-10 個 agents 同時運行 → token 使用量暴增

緩解： - 小專案不用 task system - 大專案時計算 ROI（時間節省 vs 成本增加） - 利用自動 model 選擇（Haiku/Sonnet/Opus）

風險 3：複雜度增加¶

問題： 多層架構難以 debug

緩解： - 從簡單場景開始（2-3 個並行 tasks） - 逐步增加複雜度 - 保持清晰的任務命名和文檔

風險 4：失去控制感¶

問題： Sub-agents 並行執行，Hsc 看不到細節

緩解： - 使用 Ctrl+T 檢查 task view - DyDo 定期報告進度 - 關鍵任務仍然順序執行（不並行）

結論與建議¶

建議採用方案：方案 B（短期）¶

理由： - 最務實（不破壞現有工作流） - 增強 execution（利用 task system 加速） - 保留 DyDo planning 的價值（定義問題 + 依賴分析）

下一步（實驗階段）¶

實驗 1： 手動測試 task system（小專案）
實驗 2： DyDo 練習依賴分析
實驗 3： 端到端整合測試
評估： 根據實驗結果決定是否正式採用

長期願景（方案 C）¶

當 Claude Code 支援 multi-layer swarms（sub-agents 再 spawn sub-agents）： - DyDo 只定義高層目標 - Claude Code 自主拆解並執行 - 真正實現「定義問題清晰到 swarm 能解決」的願景

參考資料¶

CJ Hess 原文： Claude Code Task System：Agent Swarms 的實現
現有工作流： ~/clawd/WORKFLOW.md
宝玉經驗： Claude Code 上下文管理

狀態： 📋 分析完成，待實驗驗證
更新日期： 2026-01-27