Menü
以 Agent Teams 3 人並行審查 .spec 任務的程式碼（邏輯/品質/效能）並交叉審查，報告全文在對話輸出、摘要一行進 plan.md。當使用者提到 /plan-review、「Agent Teams 程式碼審查」、「plan-review 審查」時觸發此 Skill。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
CREW 環境健診 —— 一次性檢查 CREW 所有必要與選配依賴（Node/Git/Notion MCP/Agent Teams/瀏覽器 MCP/config/專案註冊/CLAUDE.md），列出綠黃紅燈與修法。當使用者提到 /crew-doctor、「CREW 環境健診」、「CREW 為什麼不能用」時觸發此 Skill。
瀏覽與探索已有的 .spec/ 規劃文件 —— 深度閱讀、跨任務比較、模式搜尋。當使用者提到 /plan-browse、「瀏覽 .spec 規劃」、「看之前的規劃設計」時觸發此 Skill。
從 .spec/{slug}/plan.md 以 Agent Teams leader-delegate 模式產生程式碼，含退出驗證與錨點有效性檢查，Leader 只協調不寫 code。當使用者提到 /plan-build、「從 spec 產生程式碼」、「plan-build 產碼」時觸發此 Skill。
結案前先跑文件漂移硬關卡（FAIL 擋、WARN 需明示放行），通過後蓋章 verified_at_commit、提交 Git、批次同步 plan.md 與 deploy.sql 到 Notion。當使用者提到 /plan-close、「feature 結案」、「同步 spec 到 Notion 並結案」時觸發此 Skill。
智慧推薦 CREW 當前任務下一步 —— 呼叫 crew-state.py 讀 state.json 算出下一個 /plan-* 指令並轉成人話。當使用者提到 /plan-next、「CREW 下一步指令」、「這個 spec 接下來做什麼」時觸發此 Skill。
CREW 規劃 —— spec / db / arch 三個 pass 把決策與驗收條件寫進 .spec/{slug}/plan.md，DB 設計另產 deploy.sql（零 Notion 呼叫）。當使用者提到 /plan、「CREW 完整規劃」、「一次跑完 spec/db/arch」時觸發此 Skill。
| name | plan-review |
| description | 以 Agent Teams 3 人並行審查 .spec 任務的程式碼（邏輯/品質/效能）並交叉審查，報告全文在對話輸出、摘要一行進 plan.md。當使用者提到 /plan-review、「Agent Teams 程式碼審查」、「plan-review 審查」時觸發此 Skill。 |
| argument-hint | [--quick] |
以 Agent Teams leader-delegate 模式，3 位 Reviewer 並行審查程式碼，完成後互相分享發現並交叉審查，Leader 彙整報告。
報告不落檔：完整報告在對話輸出（要當下看、當下修的東西，存成檔案只會變成沒人再讀的漂移來源）。 落檔的只有兩樣：
plan.md「檢查報告摘要」節的一行摘要，與state.json的results.review。
必須啟用 Agent Teams 實驗功能（同 plan-build，擇一設定）：
方式 A：加入 shell profile（~/.zshrc 或 ~/.bashrc）
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
方式 B：加入 settings.json 的 env 區塊
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
⚠️ 未設定時，建立 Agent Team 的指令會靜默失敗（不報錯但不產出 Reviewer 結果），難以 debug，務必在此先確認已設定。
建議已執行 /plan-build 產生程式碼，或已有開發中的程式碼。
💡 plan-review 從 .spec/ 和程式碼檔案讀取所有輸入，不依賴對話歷史。 若剛執行完 /plan-build，建議先 /clear 再執行，確保有足夠 context 空間。
前置檢查：參照 plugin 根目錄
references/prerequisites.md（相對 SKILL.md 為../../references/）檢查 CLAUDE.md 是否存在。
紀律護欄：
../../references/discipline-preamble.md（通用紀律）＋../../references/anti-rationalizations.md「plan-review 專用」＋../../references/boundaries.md「plan-review」段；斷點保險改為進度即寫state.json（crew-state.py unit／result）；有「可以跳過」「應該夠了」的衝動時，停下查表確認是否為已知偏離模式。
/plan-review # 完整 3 人審查
/plan-review --quick # 快速審查（僅 logic-reviewer，用 Subagent）
參照 plugin 根目錄 references/plan-common.md（相對 SKILL.md 為 ../../references/）的「定位活躍任務」（crew-state.py list），流程位置一律以 state.json 為準。
{prod_branch} 從專案設定讀取；未設定時，先取 origin/HEAD 指向的分支，若無則依序嘗試 production → master → main：
git diff $(git merge-base HEAD {prod_branch})..HEAD --name-only # 已 commit 的變更
git status --porcelain # 尚未 commit 的變更
兩者合併去重即為審查範圍。🔴 不要去找檔案清單文件（已廢除）—— 清單檔會過期，git 不會。
兩邊都是空的 → 提示使用者指定檔案，或先 /plan-build。
在 spawn Reviewer 之前先跑一次錨點檢查，把結果當 Reviewer 1 的輸入（它已經幫你標出「文件說的位置和程式碼對不上」的地方，Reviewer 不必自己重掃）：
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/check-spec-drift.py" \
--spec .spec/{slug}/plan.md --format json
| exit | 處理 |
|---|---|
| 0 | 報告「錨點全部有效」，照常進行 |
| 1 / 2 | 把 JSON 內每筆的 code／anchor／detail／fix 摘要進 Reviewer 1 的 prompt，並在確認畫面顯示「⚠️ 錨點 N 筆需注意」；不阻擋 |
| 3 | 環境問題 → 標「本次未檢查錨點」＋原因，🔴 不得說成漂移，也不得說成通過 |
🔴 本 skill 不修錨點、不寫 verified_at_commit；要修去 /plan-drift，硬關卡在 /plan-close。
.spec/{slug}/plan.md —— 目標與範圍、驗收條件 AC-n（功能正確性的判準）、決策紀錄 D-n（為什麼這樣寫，判斷「偏離」還是「刻意」的依據）、已知取捨與風險（已列為取捨的不要再當缺陷報）.spec/{slug}/deploy.sql —— 表結構、索引、約束的唯一事實來源（Reviewer 3 效能審查用）state.json 的 results.verify —— 上一輪運行時驗證結果（選讀，crew-state.py list --slug {slug} --format json）即將啟動 Agent Teams 程式碼審查：
📁 審查範圍：N 個檔案（git diff + git status）
🔍 錨點 pre-check：{全部有效 / ⚠️ N 筆需注意 / 本次未檢查（原因）}
📊 Reviewer 配置：
• Reviewer 1 — 邏輯正確性（model: sonnet）
• Reviewer 2 — 程式碼品質（model: sonnet）
• Reviewer 3 — 效能審查（model: opus）
確認開始？[Y/n]
完整政策見 plugin 根目錄 references/model-policy.md（相對 SKILL.md 為 ../../references/）。
model 參數傳入（sonnet / sonnet / opus），🔴 不可只在 prompt 寫「使用 Opus 模型」。sonnet；效能敏感（含交易、並行、大量資料）→ opus。sonnet，或直接建議使用者改跑 /plan-review --quick。採用例外時要在上面的確認畫面標明實際模型與理由。/plan-security（model: opus）負責。用 Agent tool 逐一具名 spawn 3 個 Reviewer（一個角色一次呼叫，各自帶結構化 model）：
model: sonnet）— 讀取 plan.md（AC-n ＋ D-n）、R0 的錨點 pre-check 結果與變更檔案，檢查 API 參數驗證、業務邏輯、查詢條件、例外處理、邊界條件、回傳格式，並逐條對照 AC-n 是否真的有對應實作model: sonnet）— 比對專案既有檔案風格，檢查命名規範、package 結構、Lombok、註解、error handling、edge casemodel: opus）— 讀取 deploy.sql（索引、約束）與變更檔案，檢查 N+1、分頁、索引、迴圈內 DB 呼叫、快取、連線池三位 Reviewer 完成後互相分享發現、交叉審查，Lead 只負責協調（delegate mode，不自己寫 code）彙整產出 Review Report，全程繁體中文。
完整派工 prompt 模板（含各 Reviewer 逐項檢查清單與標記符號）：plugin 根目錄 references/review-prompts.md（相對 SKILL.md 為 ../../references/），套用時將 {slug}、{檔案清單} 換成實際值。
使用 Agent tool 啟動單一 subagent（model: sonnet），只做邏輯正確性審查
（呼叫時必須實際傳入 {"model": "sonnet"}；--quick 針對小型變更，唯讀不改程式碼）：
你是資深程式碼審查員。
## 規劃文件（判準）
{plan.md 的 目標與範圍 / 驗收條件 AC-n / 決策紀錄 D-n / 已知取捨與風險}
## 錨點 pre-check 結果
{R0 的 JSON 摘要；無則寫「全部有效」或「本次未檢查（原因）」}
## 審查檔案
{檔案清單及內容}
## 專案上下文
{CLAUDE.md 內容}
## 任務
對以上程式碼進行快速審查，聚焦於：
1. 邏輯正確性
2. 明顯的安全問題
3. 風格一致性（與專案現有程式碼比對）
標記嚴重程度：🔴 嚴重 / 🟡 建議 / 🟢 良好
輸出使用繁體中文。
Leader 收集所有 Reviewer 的發現（含交叉分享結果），彙整成下列結構直接輸出在對話。
🔴 不要寫成 .spec/ 下的檔案 —— 這份報告的價值是「現在拿去修」，存成檔案只會在下次改碼後變成錯的。
# 程式碼審查報告
## 審查日期
{日期}
## 審查範圍
{N} 個檔案
## 統計
| 類別 | 🔴 嚴重 | 🟡 建議 | 🟢 良好 |
|------|---------|---------|---------|
| 邏輯正確性 | {N} | {N} | {N} |
| 程式碼品質 | — | {N} | {N} |
| 效能 | {N} | {N} | {N} |
| **合計** | **{N}** | **{N}** | **{N}** |
## 🔴 嚴重問題
### [{序號}] {問題標題}
- **檔案**：{路徑}:{行號}
- **Reviewer**：{logic/quality/performance}
- **問題**：{描述}
- **建議**：{修復建議}
## 🟡 改善建議
### [{序號}] {建議標題}
- **檔案**：{路徑}:{行號}
- **Reviewer**：{reviewer}
- **建議**：{描述}
## 🟢 良好實踐
{正面反饋清單}
## 交叉審查發現
{Reviewers 之間互相分享後發現的額外觀點}
7a. plan.md「檢查報告摘要」節 append 一行
依 references/plan-common.md「寫入紀律」用 Edit 對 <!-- crew:rep append-only --> 那一整行插入，格式固定：
- [{YYYY-MM-DD}] review {PASS|WARN|FAIL}｜🔴{N} 🟡{N}｜{一句話結論}
🔴 只寫這一行：逐條發現不進 plan.md（該節上限 6 行），🔴 不得整節取代、不得動別節。
日期用 date +%F 的實際輸出。結論詞：無 🔴 → PASS；有 🟡 無 🔴 → WARN；有 🔴 → FAIL。
7b. 寫回 state.json（唯一狀態權威）
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/crew-state.py" result --slug {slug} \
--kind review --status {PASS|WARN|FAIL} \
--set critical={🔴 數} --set warning={🟡 數} --set files={審查檔案數} --set mode={full|quick}
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/crew-state.py" set --slug {slug} \
--step review --status done --phase review
python3 "${CLAUDE_PLUGIN_ROOT}/scripts/crew-state.py" validate --slug {slug} --expect-phase review
validate exit 1 → 依訊息修正後重跑；仍失敗 → crew-state.py rebuild --slug {slug}。
程式碼審查完成！
📋 報告：見上方對話全文（依設計不落檔）
📊 統計：🔴 {N} 嚴重 / 🟡 {N} 建議 / 🟢 {N} 良好
📝 已寫入：plan.md 摘要一行 + state.json results.review
🔍 錨點 pre-check：{全部有效 / ⚠️ N 筆 / 本次未檢查（原因）}
{若有嚴重問題}
⚠️ 發現 {N} 個嚴重問題，建議修復後再結案。
後續可使用：
• 修正問題後再次 /plan-review
• /plan-drift — 修錨點失效（結案前一定要清乾淨）
• /plan-close — 結案並同步 Notion
分工邊界：本 skill 專責 CREW .spec 任務的 Agent Teams 多角色交叉審查，其餘審查需求請改用下列指令。
/code-review 或 codexjava-code-reviewsuperpowers:requesting-code-review/plan-security；架構設計建議 → 個人 java-design-advisor--quick 模式（單一 Subagent），節省 80% token。{prod_branch} 從專案設定檔的 prod_branch 欄位讀取（由 /project-add 設定）。若未設定，回退邏輯：先取 origin/HEAD 指向的分支，若無則依序嘗試 production → master → main。.spec/review.md 之後，程式碼一改它就變成錯的，還會被 /plan-close 原樣推到 Notion 汙染知識庫。要留痕就留 plan.md 那一行摘要與 state.json。/plan-close（D1／D2 擋結案），要修去 /plan-drift。git status 別漏：只跑 git diff merge-base..HEAD 會漏掉還沒 commit 的變更，剛跑完 /plan-build 的檔案通常都還沒 commit。/plan-build 或 commit 程式碼/plan）：仍可審查，但在報告開頭標「無驗收條件可對照，本次只做程式碼層面審查」check-spec-drift.py 回 exit 3：R0 標「本次未檢查」＋原文的「修法：」，不阻擋、不改判為漂移--quick 模式