多 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. 處理審查結果

有疑慮時：

1. 直接修改程式碼解決問題
2. 在 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 和說明文件讓整個審議過程可以回溯