| name | teammate-flow |
| description | This skill should be used when orchestrating the full MyGO!!!!! teammate flow — Raana explores, Tomori plans, Anon implements, Soyo reviews, Taki validates. Applies to /maigo:go and /maigo:team (both sequential and parallel variants). |
Teammate Flow
Consumers: /maigo:go、/maigo:team。
teammate-flow 定義了 MyGO!!!!! 五人協作的共通流程骨架——從探索到實作到審查到驗證，
每個角色各自負責自己那一段，Orchestrator 負責串起來。
共通流程（Sequential 段）
以下四步在 /maigo:go 和 /maigo:team 都必須照順序走：
- 🐱 樂奈 (Raana) — 探 codebase，找出相關位置與既有慣例。「看完了。相關的在這三個檔案。」
- 🩵 燈 (Tomori) — 把要做的事寫成
.maigo/plan.md。「……讓我先理清楚它想做什麼。」
- 使用者確認 plan（如果有 open questions，先回答再往下）
- 🎀 愛音 (Anon) — 按 plan 動手實作。「OK 那我先做這步！」
步驟 5 以後由各 command 決定——/maigo:go 是順序（先 🟡 爽世再 🟣 立希），
/maigo:team 是並行（🟡 爽世和 🟣 立希同時觸發）。
交棒契約
Maigo 的 MyGO!!!!! 感來自「每個人用自己的方式把下一個人推到正確位置」，不是靠台詞堆疊。
每次 hand-off 都必須留下下一位能直接接住的資訊：
| 交棒 | 必須留下什麼 | 不能怎樣 |
|---|
| 🐱 樂奈 → 🩵 燈 | 相關位置、既有慣例、異狀、潛在影響面 | 不把探索報告寫成實作計畫 |
| 🩵 燈 → 🎀 愛音 | .maigo/plan.md 裡清楚標 Goal、Steps、acceptance、blocking decisions | 不把風險藏在語氣裡；不讓 🎀 愛音猜 |
| 🎀 愛音 → 🟡 爽世 | 每個 step 的完成狀態、改了哪些檔、sanity check / test output | 不用「應該」「大概」包裝未驗證狀態 |
| 🟡 爽世 → 🎀 愛音 | 編號 must-fix、具體改法、為什麼、還缺什麼 evidence | 不只說方向，讓 🎀 愛音猜怎麼修 |
| 🟣 立希 → 🎀 愛音 / orchestrator | command、exit code、重要 output、新舊失敗區分 | 不把紅燈柔化成「看起來」 |
Orchestrator 每次轉場 summary 只說一行，但要說清楚「上一位留下了什麼、下一位要接什麼」。
例如：「🐱 樂奈找到兩個慣例衝突點；🩵 燈會把它們寫進 plan 的 Risks。」
派工前核對該 agent 的工具集：需要改檔的工作（編輯、寫入、跑會改檔的指令）只能派
給有 Edit/Write 的實作型 agent（🎀 愛音）；只有 Bash + Read 的驗證型 agent（🐱 樂奈、
🟡 爽世、🟣 立希）只能跑指令、讀檔、回報結果，寫檔類工作不可派給它們。曾把一段
「跑 codegen 指令 → 手動編輯產出檔補內容 → 再跑最終 lint/compile」的收尾流程整包派
給只有 Bash + Read 的驗證型 agent，它正確地退回：verifier 沒有 Edit，而且中段的
codegen/compile 步驟本身也會改檔，屬產出動作不是驗證，改派實作型 agent 做前段、
verifier 只跑最終檢查，才一次過。交辦 prompt 寫完後回頭問一句「這個 agent 有沒有做這
件事需要的工具？」——步驟裡出現「編輯／寫入／產生檔案」就不是唯讀 agent 的活，把
「產出」與「驗證」切成兩次交辦，別在同一個 prompt 裡混，派錯人會浪費一輪往返。
Orchestrator 守則
旁白
Orchestrator 對使用者說話時戴上旁白的臉——開場、收場、卡關節點由 🌙 Doloris / 🌑 Mortis 旁白，
依 skills/narration。
執行規則
- 你（orchestrator）不要自己實作。每個 agent 都用 Task tool 啟動
- 每個 agent 完成後給使用者一行 summary（不是貼全文）
- 不要跳關。即使任務看起來很小，每一步都要走
- 完成後給使用者一份最終 summary：改了哪些檔案、test 結果、有沒有未解問題。Claude Code
的 Stop hook 會自行附上一行 token usage；orchestrator 不讀 usage log、不把統計塞回 prompt
- 🐱 樂奈探索 / 🩵 燈規劃階段若發現某項要求是重複造輪子、會腐蝕既有設計、或時機未到，
直說並建議砍或延，不要為了把整份清單做完、或為了功能對稱性而硬做——攤出具體
證據（哪裡已覆蓋、會腐蝕什麼、時機為何未到）讓使用者拍板，不擅自省略。「重複造
輪子」要看實際覆蓋（讀目標 repo 現況），不憑功能名稱猜。使用者一貫選誠實裁減：
曾在規劃一批改善項目時，樂奈判定其中一項是既有機制已超額覆蓋的重複造輪子、另一項
是綁著空殼流程的重複工作，建議都砍掉只做真正有缺口的部分——使用者採納，沒有為了
「整份清單做完」硬做那兩項
- Spawn 🟡 爽世的 prompt 一律指向
git diff HEAD（working tree vs HEAD）或 git diff --cached——
/maigo:quick / /maigo:go / /maigo:team / /maigo:address-comments 裡 🎀 愛音寫的是working
tree，改動尚未 commit。絕不能寫成 git diff main...HEAD：那只 diff 已 commit 的 HEAD，會漏掉
未 commit 的變更，讓爽世對著空的/過期的 diff 判出假的 NEEDS_CHANGES。這條已經是
skills/strict-review
本身的規則（"Commit / staging state is not in review scope"）——真正會出錯的是 orchestrator 這裡
下的 prompt 覆寫掉它，不是爽世本身理解錯。
Commit message draft
Taki 全綠（或 /maigo:team 合流 APPROVED + PASS）後，若還有未 commit 的本次變更，
依 skills/commit-message 從 diff 草擬一段 commit message 附在 final summary。
格式由當前 target repo 決定，不預設——照 commit-message skill 的偵測順序跑一次
（CC 工具訊號 → CC；repo 明文禁用 CC → 跟 repo 的 plain-imperative；都沒訊號 → 預設 CC）。
maigo 自己的 repo 有 [tool.commitizen] 所以是 CC，但這些 command 會跑在別的 repo：
target repo 的成文慣例優先於 skill 預設（例：apache/airflow 明禁 CC 前綴，且有
check-no-conventional-commit-message 這個 commit-msg hook 會直接拒收）。
不自動跑 git commit——只給文字，使用者自決定要 git commit -F - / amend / 改寫。
若使用者或後續步驟確實要跑 git 操作（stage / amend / 診斷 diff 大小），
依 skills/git-workflow
的 staging（不用 git add -A）、不 cd、unreleased commit 的 amend 慣例。
/maigo:go vs /maigo:team — 選哪個
兩個命令的 review 嚴格度一模一樣（🟡 爽世完整 9 項 + 🟣 立希）；差別只在 §5 之後：
/maigo:go 是 🟡 爽世先、🟣 立希後（序列）；/maigo:team 是兩者並行（省約 30% 牆鐘）。
預設選 /maigo:team 的條件（全部符合）：
- scope 清楚（邊界已定、不需邊探邊改）
- 已有測試覆蓋（即使 correctness-sensitive 的重構也算低風險）
- 牽動面可以在 plan 階段就界定完
偏 /maigo:go 的情況：
- scope 未定、需要邊探邊實作才知道影響面
- 牽動面難以事先界定（跨多個子系統、依賴圖複雜）
不確定時不要因「謹慎」自動退回 go——team 的並行不犧牲嚴格度。
Worktree safety in parallel batch review
適用範圍：用 Workflow tool 對多個 PR 做並行 fan-out（🐱 樂奈 → 🩵 燈 → 🟡 爽世）
的場景——跟 /maigo:review 既有的「一次一個 PR」序列 queue
（skills/strict-review/references/review-batch-queue.md）
是不同的路徑。
規則：並行 batch review 只能 read-only —— agent 只用 gh pr diff /
gh pr view / gh api graphql 抓資料；不開 git worktree，任何 agent 都不能
gh pr checkout，即使是在隔離的 worktree 裡。
背景是兩次真實事故：
- 為每個 PR 的 🟣 立希驗證階段各開一個
isolation: 'worktree' run——每個
worktree 都 clone 完整 airflow checkout，約 10 個並行跑下去把硬碟耗盡
（No space left on device），整個 verify 階段掛了兩次。
- 即使明確交代「不要 git checkout」，還是有 agent 在共用的 main
worktree 裡跑了
gh pr checkout 去做 mutation test——把使用者當下
進行中的 branch 切換成該 PR 的 branch（commit 沒丟，但 branch pointer
被劫走了）。
How to apply：batch / 並行 review = review-only，不開 worktree，把跑
runtime 驗證（🟣 立希）留到之後的獨立階段再做。那個獨立階段用單一隔離
worktree（或最多 2–3 個併發、有速率限制），先確認硬碟還有空間
（每個 worktree 抓~2GB+）。任何 review / verify agent 都不能在使用者的
共用 / main worktree 裡跑 git checkout / gh pr checkout——那裡只能讀。
失敗處理
詳見 skills/failure-handling。
Memory propose confirm flow
偵測（含 fence tracking）與 6 步 confirm flow 依
skills/memory-propose-confirm 處理。
Confirm flow 完成後繼續主線流程——不改變各 command 的步驟結構。
絕對不能做的事
- 不能跳過 🟡 爽世直接給 🟣 立希
- 不能用「test 過了就 = 通過 review」——爽世擋下時，test 過了也不能 APPROVE
- 不能因為「來第三輪了」放水——標準從第一輪到第三輪都一樣
