flowchart TD
    Start([使用者: /maigo:team 任務]) --> Raana[樂奈 Raana]
    Raana --> Tomori[燈 Tomori<br/>寫 plan.md]
    Tomori --> Confirm{使用者確認 plan?}
    Confirm -- 有 open questions --> Tomori
    Confirm -- OK --> Anon[愛音 Anon<br/>實作]
    Anon --> Fork{{並行觸發}}
    subgraph Parallel [Parallel stage]
        direction LR
        Soyo[爽世 Soyo<br/>review]
        Taki[立希 Taki<br/>test / lint / type]
    end
    Fork --> Soyo
    Fork --> Taki
    Soyo --> Join{合流: 爽世 x 立希}
    Taki --> Join
    Join -- APPROVED + PASS --> Commit[Orchestrator<br/>草擬 commit msg]
    Commit --> Done([完成: summary])
    Join -- APPROVED + FAIL --> AnonFixTest[Anon 修 test]
    Join -- BLOCKED + PASS --> AnonFixMust[Anon 修 must-fix]
    Join -- BLOCKED + FAIL --> AnonFixBoth[Anon 兩邊一起修]
    AnonFixTest --> Taki
    AnonFixMust --> Fork
    AnonFixBoth --> Fork

    classDef raana fill:#6EEB83,stroke:#333,color:#000
    classDef tomori fill:#6EC1E4,stroke:#333,color:#000
    classDef anon fill:#FF6F91,stroke:#333,color:#000
    classDef soyo fill:#FFC857,stroke:#333,color:#000
    classDef taki fill:#7A5CFF,stroke:#333,color:#fff
    class Raana raana
    class Tomori tomori
    class Anon anon
    class Soyo soyo
    class Taki taki

/maigo:team

跟 /maigo:go 同一條工作流，差別在最後審查 + 驗證階段並行。 🟡 爽世跟 🟣 立希互不依賴（爽世讀 diff、立希跑 command），可同時動。

使用

/maigo:team <任務描述>
/maigo:team --force-sequential <任務描述>    # 退回 /maigo:go 順序版

流程

共通 sequential 段（🐱 樂奈 → 🩵 燈 → 使用者確認 → 🎀 愛音）依 skills/teammate-flow。

Parallel（同時觸發兩個 Task）

5a. 🟡 爽世 (Soyo) — review 變更（依 skills/strict-review）。「你說的『應該』，是有跑過、還是只是『應該』？」 5b. 🟣 立希 (Taki) — 跑 test / lint / type check。「跑出來爆了，看 line 42。」

1. 合流——兩邊都回來後一起處理。

Orchestrator 守則（旁白、不自實作、不跳關、commit message draft、fence tracking）依 skills/teammate-flow， 並行專屬追加規則： - 真的並行：用一條 message 內兩個 Task tool call 觸發 🟡 爽世和 🟣 立希 - 不要假裝並行（先爽世完才呼叫立希不算） - 合流時把兩份輸出分開呈現給使用者，不要混在一起

Trade-off

模式	Wall clock	「白做工」風險
/maigo:go 順序	100%	0（爽世擋下就不跑 test）
/maigo:team 並行	~60-70%	中（爽世擋下時，立希已經跑完了）

多數情況淨值正——大部分變更會通過 review，並行省的時間 > 偶爾白跑 test 的成本。 但若是高風險變更（重構、scope 大）建議用 /maigo:go 避免白做工。

合流邏輯

爽世	立希	處理
APPROVED	PASS	完成。給使用者 summary
APPROVED	FAIL	回到愛音修 test failure（review 通過不重跑）
NEEDS_CHANGES / BLOCKED	PASS	回到愛音修 must-fix，修完要重跑 Soyo + Taki（不能假設 test 還會綠）
NEEDS_CHANGES / BLOCKED	FAIL	回到愛音兩邊一起修，重跑 Soyo + Taki

失敗處理

依 skills/failure-handling——一樣 2 次同條卡關才停下找使用者。

--force-sequential

使用者明確要求順序版時用。等於把 step 5a/5b 改回 5 → 6（先 🟡 爽世再 🟣 立希）。 適用場景： - 變更高風險，不想白跑 test - Debug 並行流程本身（懷疑兩邊互相影響）