Skip to content

Teammate Flow

Consumers: /maigo:go、/maigo:team。

teammate-flow 定義了 MyGO!!!!! 五人協作的共通流程骨架——從探索到實作到審查到驗證， 每個角色各自負責自己那一段，Orchestrator 負責串起來。

共通流程（Sequential 段）

以下四步在 /maigo:go 和 /maigo:team 都必須照順序走：

  1. 🐱 樂奈 (Raana) — 探 codebase，找出相關位置與既有慣例。「看完了。相關的在這三個檔案。」
  2. 🩵 燈 (Tomori) — 把要做的事寫成 plan（.maigo/plan-<id>.md，路徑由 scripts/artifact_path.py 算出）。「……讓我先理清楚它想做什麼。」
  3. 使用者確認 plan（如果有 open questions，先回答再往下）
  4. 🎀 愛音 (Anon) — 按 plan 動手實作。「OK 那我先做這步！」

步驟 5 以後由各 command 決定——/maigo:go 是順序（先 🟡 爽世再 🟣 立希）， /maigo:team 是並行（🟡 爽世和 🟣 立希同時觸發）。

交棒契約

Maigo 的 MyGO!!!!! 感來自「每個人用自己的方式把下一個人推到正確位置」，不是靠台詞堆疊。 每次 hand-off 都必須留下下一位能直接接住的資訊：

交棒 必須留下什麼 不能怎樣
🐱 樂奈 → 🩵 燈 相關位置、既有慣例、異狀、潛在影響面 不把探索報告寫成實作計畫
🩵 燈 → 🎀 愛音 交出實際 plan 路徑（.maigo/plan-<id>.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。

對話

對話本體（旁白節點以外）的互動節奏與用詞，依 skills/orchestrator-voice。

執行規則

  • 你（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 裡。

背景是兩次真實事故：

  1. 為每個 PR 的 🟣 立希驗證階段各開一個 isolation: 'worktree' run——每個 worktree 都 clone 完整 airflow checkout，約 10 個並行跑下去把硬碟耗盡 （No space left on device），整個 verify 階段掛了兩次。
  2. 即使明確交代「不要 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
  • 不能因為「來第三輪了」放水——標準從第一輪到第三輪都一樣