計劃模式
當使用者需要計劃而非執行時，請使用此技能。
核心行為
在此回合中，你僅進行規劃。
- 不要實作程式碼。
- 不要編輯專案檔案，除了計劃 markdown 檔案之外。
- 不要執行會變更狀態的終端機指令、提交、推送或執行任何外部動作。
- 必要時，你可以使用唯讀指令/工具檢視儲存庫或其他上下文。
- 你的交付產物是一個 markdown 計劃，儲存在作用中工作區的
.hermes/plans/下。
輸出要求
撰寫具體且可執行的 markdown 計劃。
在相關時，包含：
- 目標
- 當前上下文 / 假設
- 提議的方法
- 逐步計劃
- 可能變更的檔案
- 測試 / 驗證
- 風險、取捨與未解決問題
如果任務與程式碼相關，請包含確切的檔案路徑、可能的測試目標以及驗證步驟。
儲存位置
使用 write_file 將計劃儲存在：
.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
將該路徑視為相對於作用中的工作目錄 / 後端工作區。Hermes 檔案工具能感知後端，因此使用此相對路徑可將計劃保留在工作區中，無論是在 local、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：[描述性名稱]
**目標：** 此任務完成什麼（一句話）
**檔案：**
- 建立：`exact/path/to/new_file.py`
- 修改：`exact/path/to/existing.py:45-67`（如果已知行號）
- 測試：`tests/path/to/test_file.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 [files]
git commit -m "type: description"
常見錯誤
模糊的任務
不好： "加入驗證" 好： "建立包含 email 和 password_hash 欄位的 User 模型"
不完整的程式碼
不好： "步驟 1：加入驗證函式" 好： "步驟 1：加入驗證函式" 後面接著完整函式程式碼
缺少驗證
不好： "步驟 3：測試它是否有效"
好： "步驟 3：執行 pytest tests/test_auth.py -v，預期：3 passed"
缺少檔案路徑
不好： "建立模型檔案"
好： "建立：src/models/user.py"
執行交接
在儲存計劃後，提供執行方法：
"計劃完成並已儲存。準備好使用子代理驅動開發執行 — 我會為每個任務派遣一個全新的子代理，並進行兩階段審查（規格符合性，然後程式碼品質）。要繼續嗎？"
執行時，使用 subagent-driven-development 技能：
- 每個任務使用全新的
delegate_task，附上完整上下文 - 每個任務後進行規格符合性審查
- 規格通過後進行程式碼品質審查
- 只有在兩個審查都核准時才繼續
記住
細小任務（每個 2-5 分鐘）
確切的檔案路徑
完整的程式碼（可直接複製貼上）
確切的指令與預期輸出
驗證步驟
DRY、YAGNI、TDD
頻繁提交
好的計劃讓實作變得顯而易見。