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