independent-review

name	independent-review
description	並行啟動兩個獨立代理人對目前產出（程式碼、計畫、報告、文件、設計）做批判性審查，整合後給出優先順序行動清單

Independent Review

當你完成一輪產出（不論是程式碼、設計計畫、技術報告、規格文件、PR 描述、需求評估）想避免自己的盲點時呼叫本 skill。它用兩個獨立代理人並行從不同角度審視同一份產出，最後由 Claude 整合為「必修 / 應補 / 延後」三層清單。

兩個代理人的視角依產出類型動態決定（見下方 §3），不硬綁「程式碼 + 測試覆蓋率」。

步驟

1. 判定產出類型（這步決定後續兩個代理人的任務設計，不能省略）：

   先根據使用者參數或現況推論下列類別之一；不清楚就先問使用者一個簡短問題確認。

   類別	典型觸發
   程式碼變更	目前在 git 分支、有 commit diff、使用者剛完成 bug fix / feature
   實作計畫	使用者剛寫完設計文件、plan-mode 產出的步驟列表、schema migration 規劃
   技術報告 / 分析	調查性文件、A/B 結果、效能分析、事故回顧
   規格 / 需求	功能需求文件、API 契約、使用者故事
   架構 / 設計	系統流程圖、元件劃分、資料流設計
   其他 / 邊界情境	DB migration、CI/CD 設定、config 變更、純測試碼、跨類別混合——直接詢問使用者要從哪兩個視角審查

2. 收集審查材料：

   • 程式碼：git log --oneline -20 + git diff --stat 取得變更概觀，並將 git diff 全文或關鍵檔案完整內容放入 prompt（不要只給路徑讓 agent 自找，會錯讀片段）。
   • 計畫 / 報告 / 文件：取得完整檔案路徑 + 相關依賴（引用的 spec、先前版本、相關程式碼位置）。
   • 如果有上一輪審查的結論，整理成 checklist 傳給代理人，要求逐項驗證。

3. 依類別設計兩個代理人的視角（原則：兩個代理人要正交互補，不是重疊）：

   類別	代理人 A	代理人 B
   程式碼變更	正確性審查：驗證修復是否到位、邊界、有無新問題、API 對齊	測試完整性：先確認 coverage 工具可跑，可跑則實測找 0% 方法；否則檢查測試是否涵蓋新行為與邊界、品質如何
   實作計畫	可行性 / 技術風險：架構合理性、依賴、rollback、向後相容	排程 / 拆解合理性：步驟粒度、並行機會、遺漏前置條件、估工時
   技術報告	資料正確性 / 論證嚴謹：數據來源、推論鏈、對立假設	完整性 / 受眾適配：缺哪些角度、讀者能否看懂、可執行結論
   規格 / 需求	一致性 / 歧義：條款衝突、未定義術語、邊界行為	可測試性 / 驗收條件：能否寫出驗收測試、成功標準量化
   架構 / 設計	耦合 / 擴展性：單一職責、模組邊界、未來變動代價	故障模式 / 可觀察性：失敗場景、監控、性能瓶頸

   若情境混合（例如 PR 同時含程式碼+規格文件），擇主要產出類型，在另一代理人的 prompt 裡補上次要角度的檢查項。

   對於 A、B 視角天生重疊較高的類別（如「實作計畫」的可行性與排程），在每位代理人的 prompt 末段明確列出「對方負責的範圍」，要求避開重疊區、聚焦自己的視角。

4. 並行啟動兩個 general-purpose 代理人（同一個 tool-use 訊息發兩個 Agent 呼叫 + run_in_background: true）。每個 prompt 應包含：

   • 背景段：產出位置、範圍、最近的決策脈絡、上一輪結論（如有）
   • 角色段：明確說明此代理人負責的審查視角（見 §3 表）
   • 逐項檢查清單：把關鍵檢查點列成題目要求代理人逐一回答
   • 產出格式要求：
     • 每項發現標示嚴重度（Critical / High / Medium / Low / Nitpick）
     • 每項附具體位置（file:line、段落標題、表格行）
     • 分開列出「新發現」vs「已在上一輪提出」
     • 對於 known-issue 與真正 bug 明確分辨
   • 反客套指示：「不要說整體看起來不錯、直接指出問題」「若此項確實通過，明確標 pass」

   Prompt 應足以涵蓋背景脈絡、角色定義、5–8 條具體檢查項與產出格式；越精確產出越可用。

5. 等代理人完成（背景任務完成會自動通知；不要主動 poll / sleep）。

6. 整合報告（由 Claude 自己做，不要再開第三個彙整代理人）：

   • 開表格比對兩個代理人的發現是否相互印證、矛盾、或互補。
   • 將所有 action 分成三層並給明確位置：
     • 必修 — 合併 / 送出前應處理的真實 bug、破壞性變動、嚴重遺漏
     • 應補 — 短期內應追加的測試、文件段落、計畫拆解細節
     • 延後 — 另開 issue / ticket 追蹤的大型改進（架構重構、抽換 logging / 監控、共用模組拆分）
   • 每項附難度標籤（trivial / medium / hard）或預估改動規模（單行 / 單檔 / 跨檔），不要強行估時數——AI 估時普遍不準。

7. 請使用者決策：提供明確選項（全做 / 只做必修 / 補某類別 / 僅報告）讓使用者挑，不要擅自動手。

注意事項

• 兩個代理人都用 general-purpose subagent_type（需要完整讀檔與跨檔分析）；不要用 Explore，它只適合定位搜尋、會錯過讀取視窗外的內容，不適合批判性審查。
• 務必並行：同一訊息裡發兩個 Agent 呼叫並 run_in_background: true，避免序列浪費時間。
• 視角要正交：兩個代理人不能做一樣的事。程式碼是「正確性 + 覆蓋率」；計畫是「可行性 + 排程」；報告是「正確性 + 完整性」……依 §3 表選。
• 產出格式強制：嚴重度標籤、具體位置、pass/fail 標記是必填；不符合的回報要求代理人補齊或自己標註。
• 前後端 / 跨 repo 情境：在 prompt 中明確告知兄弟目錄路徑（例如 ../<sibling-repo>/），讓代理人能搜相依。
• 整合階段由 Claude 親自做：兩份報告都在脈絡裡，直接比對更準確；開第三個代理人會失真。
• 此 skill 不自動動手修復：即使找到 Critical bug，也先呈報後等使用者指示。
• **規劃初期（從零開始）**請用 brainstorming；本 skill 只做「已有產出」階段的批判審查。