多 AI 交叉審議工作流
用途： 此技能用於在多個 AI 工具之間互相審查程式碼變更。使用者經常在不同 AI 工具之間來回切換，讓它們互相審查變更，這個技能將整個流程標準化，確保每次交接都有一致的格式與完整的追蹤記錄。
使用時機： 使用者呼叫 /discuss-multi-ai、提到要讓其他 AI 審查變更，或貼入包含 commit hash 的審議請求時使用。
判斷身份： 根據執行環境判斷自己是哪個 AI：
- Claude Code → claude
- OpenAI Codex → codex
- Google Gemini → gemini
- 其他 → 工具小寫名稱
審議流程： 不論是使用者呼叫 /discuss-multi-ai，或貼入包含 commit hash 的審議請求，都走同一個流程。
- 讀取變更內容
有指定 commit hash 時：
git show [commit hash] git diff [commit hash]~1..[commit hash]
無指定 commit hash 時： 檢查 git status：
- 有未提交變更：先理解變更內容再進入審查
- 無變更：使用最新 commit（git show HEAD）
- 逐項審查
針對每個變更檢查：
- 邏輯正確性與潛在 bug
- 是否引入副作用或破壞現有功能
- 程式碼品質與專案慣例一致性
- 安全性考量
- 其他不同意或疑慮的地方
- 處理審查結果
有疑慮時：
- 直接修改程式碼解決問題
- 在 docs/discuss-ai/ 建立說明文件，命名格式：[AI名稱]-[commit短hash]-[簡述].md
說明文件結構：
審議：[簡述主題]
- 來源 commit: [完整 hash]
- 審議者: [AI 名稱]
- 日期: [YYYY-MM-DD]
變更摘要
[原始 commit 做了什麼]
疑慮與修改
[檔案路徑]
問題：[描述問題] 修改：[說明如何修正] 理由：[為什麼這樣改比較好]
結論
[整體評估與建議]
無問題時：
- 明確表示認同，說明為什麼這些變更是合理的
- 不做無意義的修改來彰顯自己的存在
- 不需要建立說明文件
- 提交變更
將所有修改（包含程式碼修正和說明文件）一起提交：
discuss: [AI名稱] changes
[簡述本次審議的重點]
- 輸出審議文字
提交完成後，取得 commit hash 並輸出交接文字：
git rev-parse HEAD
如果使用者有提供目標 AI 名稱參數，則使用該名稱；否則使用「其他 AI」。
輸出文字：
你的修改我跟 [AI名稱或「其他 AI」] 討論後他做了以下變更 commit [完整commit hash] 你評估看看有沒有問題，如果有任何不同意或疑慮的地方請直接修改，並建立文件進行詳細說明。
告知使用者可以複製此文字貼到另一個 AI 工具中。
重要原則：
- 實事求是：沒有問題就說沒問題，不要為了顯示存在感而做不必要的修改
- 說明文件只在有實質疑慮時建立：docs/discuss-ai/ 不是流水帳
- 尊重原始意圖：理解變更的目的後再評估，不要因為風格偏好而否定邏輯正確的程式碼
- 保持可追蹤：commit hash 和說明文件讓整個審議過程可以回溯
適用場景： 需要由多個 AI 工具針對同一程式碼變更進行交叉審查的情境，例如在 Claude、Codex、Gemini 等工具間交接變更並取得第二意見。具體支援的平台、安裝方式與費用資訊暫未提供。
限制： 資料中未提供完整功能範圍、限制條件、價格與平台支援細節，暫未提供。