- 先將 /model 設定為 Haiku
- 然後從
.context/compound-engineering/todos/和舊版todos/目錄讀取所有待辦事項
逐一呈現所有發現、決策或問題以供分類。目標是逐一檢視每個項目，並決定是否要將其加入 CLI 待辦事項系統。
重要：分類期間請勿撰寫任何程式碼！
此指令適用於：
- 分類程式碼審查發現
- 處理安全稽核結果
- 審查效能分析
- 處理任何其他需要追蹤的分類結果
工作流程
步驟 1：呈現每個發現
對於每個發現，請以下列格式呈現：
---
問題 #X：[簡短標題]
嚴重性：🔴 P1（嚴重） / 🟡 P2（重要） / 🔵 P3（額外功能）
類別：[安全性/效能/架構/錯誤/功能/其他]
說明：
[問題或改善項目的詳細說明]
位置：[檔案路徑:行號]
問題情境：
[逐步說明哪裡出了問題或可能發生什麼]
建議解決方案：
[如何修復]
預估工時：小（< 2 小時） / 中（2-8 小時） / 大（> 8 小時）
---
您要將此項目加入待辦清單嗎？
1. 是 - 建立待辦檔案
2. 下一個 - 跳過此項目
3. 自訂 - 修改後再建立
步驟 2：處理使用者決策
當使用者說「是」時：
-
更新現有待辦檔案（若存在）或 建立新檔案名稱：
若待辦事項已存在（來自程式碼審查）：
- 將檔案從
{id}-pending-{priority}-{desc}.md重新命名為{id}-ready-{priority}-{desc}.md - 更新 YAML 前置元資料：
status: pending→status: ready - 保留 issue_id、priority 和 description 不變
若建立新的待辦事項：
{next_id}-ready-{priority}-{brief-description}.md優先級對應：
- 🔴 P1（嚴重）→
p1 - 🟡 P2（重要）→
p2 - 🔵 P3（額外功能）→
p3
範例：
042-ready-p1-transaction-boundaries.md - 將檔案從
-
更新 YAML 前置元資料：
--- status: ready # 重要：從 "pending" 改為 "ready" priority: p1 # 或 p2、p3，視嚴重性而定 issue_id: "042" tags: [category, relevant-tags] dependencies: [] --- -
填入或更新檔案內容：
# [問題標題] ## 問題陳述 [來自發現的說明] ## 發現結果 - [關鍵發現] - 位置：[檔案路徑:行號] - [情境細節] ## 建議解決方案 ### 選項 1：[主要解決方案] - **優點**：[益處] - **缺點**：[若有缺點] - **工時**：[小/中/大] - **風險**：[低/中/高] ## 建議行動 [在分類階段填入 - 具體行動計畫] ## 技術細節 - **受影響檔案**：[列出檔案] - **相關元件**：[受影響的元件] - **資料庫變更**：[是/否 - 若是請描述] ## 資源 - 原始發現：[此問題的來源] - 相關問題：[若有的話] ## 驗收標準 - [ ] [具體的成功標準] - [ ] 測試通過 - [ ] 程式碼審查通過 ## 工作紀錄 ### {日期} - 核准工作 **執行者：** Claude 分類系統 **動作：** - 問題已於分類階段核准 - 狀態從 pending 變更為 ready - 準備好被接手並開始工作 **學習心得：** - [背景資訊與見解] ## 備註 來源：{日期} 的分類工作階段 -
確認核准：「✅ 已核准：
{new_filename}（問題 #{issue_id}）- 狀態：ready → 可以開始工作」
當使用者說「下一個」時：
- 刪除待辦檔案 - 從目前位置移除，因為它不相關
- 跳至下一個項目
- 記錄跳過的項目以便總結
當使用者說「自訂」時：
- 詢問要修改什麼（優先級、說明、細節）
- 更新資訊
- 呈現修改後的版本
- 再次詢問：是/下一個/自訂
步驟 3：持續處理直到全部完成
- 逐一處理所有項目
- 使用檔案型待辦事項（todos/ + /skill:file-todos）追蹤以確保可見性
- 不要在項目之間等待核准 - 持續進行
步驟 4：最終總結
所有項目處理完畢後：
## 分類完成
**總項目數：** [X] **已核准的待辦事項（ready）：** [Y] **已跳過：** [Z]
### 已核准的待辦事項（可開始工作）：
- `042-ready-p1-transaction-boundaries.md` - 交易邊界問題
- `043-ready-p2-cache-optimization.md` - 快取效能改善 ...
### 已跳過的項目（已刪除）：
- 項目 #5：[原因] - 已移除
- 項目 #12：[原因] - 已移除
### 變更摘要：
分類期間，以下狀態更新已發生：
- **Pending → Ready：** 檔案名稱與前置元資料已更新，反映已核准狀態
- **已刪除：** 跳過發現的待辦檔案已移除
- 每個已核准的檔案目前在 YAML 前置元資料中都有 `status: ready`
### 後續步驟：
1. 檢視已核准且可開始工作的待辦事項：
```bash
ls .context/compound-engineering/todos/*-ready-*.md todos/*-ready-*.md 2>/dev/null
-
開始處理已核准的項目：
/resolve-todo-parallel # 有效率地處理多個已核准項目 -
或挑選個別項目來處理
-
處理過程中，更新待辦事項狀態：
- Ready → In Progress（在您的本地情境中，隨工作進行更新）
- In Progress → Complete（重新命名檔案：ready → complete，更新前置元資料）
## 範例回應格式
問題 #5：多步驟操作缺少交易邊界
嚴重性：🔴 P1（嚴重）
類別：資料完整性 / 安全性
說明：GoogleOauthCallbacks concern 中的 google_oauth2_connected 回呼執行多次資料庫操作，但沒有交易保護。如果任何步驟中途失敗，資料庫將處於不一致的狀態。
位置：app/controllers/concerns/google_oauth_callbacks.rb:13-50
問題情境：
- User.update 成功（電子郵件已變更）
- Account.save! 失敗（驗證錯誤）
- 結果：使用者電子郵件已變更，但沒有關聯的 Account
- 下次登入嘗試完全失敗
未受交易保護的操作：
- 使用者確認（第 13 行）
- 等候清單移除（第 14 行）
- 使用者個人資料更新（第 21-23 行）
- 帳戶建立（第 28-37 行）
- 頭像附件（第 39-45 行）
- Journey 建立（第 47 行）
建議解決方案：將所有操作包裝在 ApplicationRecord.transaction do ... end 區塊中
預估工時：小（30 分鐘）
您要將此項目加入待辦清單嗎？
- 是 - 建立待辦檔案
- 下一個 - 跳過此項目
- 自訂 - 修改後再建立
## 重要的實作細節
### 分類期間的狀態轉換
**選擇「是」時：**
1. 重新命名檔案：`{id}-pending-{priority}-{desc}.md` → `{id}-ready-{priority}-{desc}.md`
2. 更新 YAML 前置元資料：`status: pending` → `status: ready`
3. 在 Work Log 中新增分類核准記錄
4. 確認：「✅ 已核准：`{filename}`（問題 #{issue_id}）- 狀態：**ready**」
**選擇「下一個」時：**
1. 從目前位置刪除待辦檔案
2. 跳至下一個項目
3. 系統中不會保留該檔案
### 進度追蹤
每次以標題呈現待辦事項時，請包含：
- **進度：** X/Y 已完成（例如「3/10 已完成」）
- **預估剩餘時間：** 根據目前的進展速度估算
- **節奏：** 監控每個發現的處理時間，並據此調整估算
範例：
進度：3/10 已完成 | 預估剩餘時間：約 2 分鐘
### 分類期間請勿撰寫程式碼
- ✅ 呈現發現結果
- ✅ 做出是/下一個/自訂的決定
- ✅ 更新待辦檔案（重新命名、前置元資料、工作紀錄）
- ❌ 不要實作修復或撰寫程式碼
- ❌ 不要加入詳細的實作細節
- ❌ 那是 /resolve-todo-parallel 階段的工作
完成後提供以下選項
```markdown
您接下來想做什麼？
1. 執行 /resolve-todo-parallel 來解決待辦事項
2. 提交待辦事項
3. 什麼都不做，休息一下