計劃模式
當使用者需要計劃而非執行時，使用此技能。
核心行為
本次任務中，你僅進行計劃。
- 不實作程式碼。
- 不編輯專案檔案，計劃 Markdown 檔案除外。
- 不執行變更性的終端指令、不提交、不推送、不執行外部操作。
- 必要時，你可以使用唯讀指令或工具檢查儲存庫或其他上下文。
- 你的交付物是儲存在作用中工作區下
.hermes/plans/的 Markdown 計劃。
輸出要求
撰寫具體且可執行的 Markdown 計劃。
在相關時，包含以下內容：
- 目標
- 當前情境 / 假設
- 建議方法
- 逐步計劃
- 可能變更的檔案
- 測試 / 驗證
- 風險、取捨與待決問題
如果任務與程式碼相關，請包含確切的檔案路徑、可能的測試目標以及驗證步驟。
儲存位置
使用 write_file 將計劃儲存在：
.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
請將其視為相對於作用中工作目錄 / 後端工作區的路徑。Hermes 檔案工具可感知後端，因此使用此相對路徑可將計劃保留在本地、Docker、SSH、Modal 和 Daytona 後端的工作區中。
如果執行環境提供了特定的目標路徑，請使用該確切路徑。
如果沒有，請自己在 .hermes/plans/ 下創建一個合理的時間戳檔名。
互動風格
- 如果請求足夠明確，直接撰寫計劃。
- 如果沒有明確的
/plan指令，從當前對話上下文推斷任務。 - 如果任務確實描述不足，提出簡短的釐清問題，而非猜測。
- 儲存計劃後，簡短回覆你計劃了什麼以及儲存路徑。
寫好計劃
本技能的其餘部分闡述了撰寫 良好 實作計劃的技巧——也就是上述 Markdown 檔案中的內容。
概述
撰寫全面的實作計劃，假設實作者對程式碼庫零上下文且品味可疑。記錄他們所需的一切：要觸碰哪些檔案、完整程式碼、測試指令、要檢查的文件、如何驗證。給他們細小的任務。遵循 DRY、YAGNI、TDD。頻繁提交。
假設實作者是一位熟練的開發者，但對工具集或問題領域幾乎一無所知。假設他們不太擅長良好的測試設計。
核心原則： 好的計劃讓實作變得顯而易見。如果有人需要猜測，代表計劃不完整。
何時需要完整實作計劃
在以下情況務必使用：
- 實作多步驟功能
- 拆解複雜需求
- 透過子代理驅動開發委派給子代理
不要跳過的情況：
- 功能看似簡單（假設導致錯誤）
- 你計劃自己實作（未來的你需要指引）
- 獨自工作（文件很重要）
細小任務的顆粒度
每個任務 = 2-5 分鐘的專注工作。
每個步驟都是一個動作：
- "撰寫會失敗的測試" — 步驟
- "執行程式以確認失敗" — 步驟
- "實作最簡程式碼使測試通過" — 步驟
- "執行測試並確認通過" — 步驟
- "提交" — 步驟
太大：
### 任務 1：建置認證系統
[跨 5 個檔案，50 行程式碼]
適當大小：
### 任務 1：建立含有 email 欄位的 User 模型
[10 行，1 個檔案]
### 任務 2：在 User 加入密碼雜湊欄位
[8 行，1 個檔案]
### 任務 3：建立密碼雜湊工具函式
[15 行，1 個檔案]
計劃文件結構
標頭（必填）
每個計劃必須以以下內容開頭：
# [功能名稱] 實作計劃
> **給 Hermes 的提示：** 使用子代理驅動開發技能逐任務實作此計劃。
**目標：** [一句話描述此計劃建構的內容]
**架構：** [2-3 句關於方法的說明]
**技術堆疊：** [關鍵技術 / 函式庫]
---
任務結構
每個任務遵循此格式：
### 任務 N：[描述性名稱]
**目標：** 此任務完成的內容（一句話）
**檔案：**
- 建立：`確切/路徑/新檔案.py`
- 修改：`確切/路徑/現有檔案.py:45-67`（若知道行號）
- 測試：`tests/路徑/測試檔案.py`
**步驟 1：撰寫會失敗的測試**
```python
def test_specific_behavior():
result = function(input)
assert result == expected
```
**步驟 2：執行測試以確認失敗**
執行：`pytest tests/path/test.py::test_specific_behavior -v`
預期：FAIL — "function not defined"
**步驟 3：撰寫最簡實作**
```python
def function(input):
return expected
```
**步驟 4：執行測試以確認通過**
執行：`pytest tests/path/test.py::test_specific_behavior -v`
預期：PASS
**步驟 5：提交**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
撰寫流程
步驟 1：理解需求
閱讀並理解：
- 功能需求
- 設計文件或使用者描述
- 驗收標準
- 限制條件
步驟 2：探索程式碼庫
使用 Hermes 工具理解專案：
# 理解專案結構
search_files("*.py", target="files", path="src/")
# 查看類似功能
search_files("similar_pattern", path="src/", file_glob="*.py")
# 檢查現有測試
search_files("*.py", target="files", path="tests/")
# 讀取關鍵檔案
read_file("src/app.py")
步驟 3：設計方法
決定：
- 架構模式
- 檔案組織
- 所需的相依性
- 測試策略
步驟 4：撰寫任務
依序創建任務：
- 設定 / 基礎設施
- 核心功能（每個功能採 TDD）
- 邊界情況
- 整合
- 清理 / 文件
步驟 5：加入完整細節
對每個任務，包含：
- 確切的檔案路徑（不是 "設定檔" 而是
src/config/settings.py） - 完整的程式碼範例（不是 "加入驗證" 而是實際程式碼）
- 確切的指令與預期輸出
- 驗證步驟證明任務可運作
步驟 6：審查計劃
檢查：
- 任務是順序且合乎邏輯的
- 每個任務是細小的（2-5 分鐘）
- 檔案路徑是確切的
- 程式碼範例是完整的（可複製貼上）
- 指令是確切的，附有預期輸出
- 沒有遺漏上下文
- 應用了 DRY、YAGNI、TDD 原則
原則
DRY（不要重複自己）
不好： 在 3 個地方複製貼上驗證 好： 抽取驗證函式，到處使用
YAGNI（你不需要它）
不好： 為未來需求加入 "彈性" 好： 只實作現在需要的
# 不好 — 違反 YAGNI
class User:
def __init__(self, name, email):
self.name = name
self.email = email
self.preferences = {} # 還不需要！
self.metadata = {} # 還不需要！
# 好 — YAGNI
class User:
def __init__(self, name, email):
self.name = name
self.email = email
TDD（測試驅動開發）
每個產生程式碼的任務應包含完整的 TDD 週期：
- 撰寫會失敗的測試
- 執行以確認失敗
- 撰寫最簡程式碼
- 執行以確認通過
詳見 test-driven-development 技能。
頻繁提交
在每個任務後提交：
git add [檔案]
git commit -m "類型: 描述"
常見錯誤
模糊的任務
不好： "加入認證" 好： "建立含有 email 和 password_hash 欄位的 User 模型"
不完整的程式碼
不好： "步驟 1：加入驗證函式" 好： "步驟 1：加入驗證函式" 接著完整的函式程式碼
缺少驗證
不好： "步驟 3：測試它可運作"
好： "步驟 3：執行 pytest tests/test_auth.py -v，預期：3 通過"
缺少檔案路徑
不好： "建立模型檔案"
好： "建立：src/models/user.py"
執行交接
儲存計劃後，提供執行的方式：
"計劃完成並已儲存。準備使用子代理驅動開發執行——我將為每個任務分配一個新的子代理並進行兩階段審查（規格遵循度，然後程式碼品質）。要繼續嗎？"
執行時，使用 subagent-driven-development 技能：
- 每個任務使用全新的
delegate_task並附上完整上下文 - 每個任務後進行規格遵循度審查
- 規格通過後進行程式碼品質審查
- 僅在兩個審查都核准時才繼續
切記
細小任務（每個 2-5 分鐘）
確切的檔案路徑
完整的程式碼（可複製貼上）
確切的指令與預期輸出
驗證步驟
DRY、YAGNI、TDD
頻繁提交
好的計劃讓實作變得顯而易見。