下圖呈現宿主可並行且未指定 --force-sequential 的路徑；否則依下方命令規則順序執行。

flowchart TD
    Start([使用者: /maigo:team 任務]) --> Raana[樂奈 Raana]
    Raana --> Tomori[燈 Tomori<br/>寫 plan-&lt;id&gt;.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]
    Commit --> Done([完成: summary])
    Join -- APPROVED + FAIL --> AnonFixTest[Anon 修 test]
    Join -- BLOCKED + PASS --> AnonFixMust[Anon 修 must-fix]
    Join -- BLOCKED + FAIL --> AnonFixBoth[Anon 兩邊一起修]
    AnonFixTest --> ContentChanged{受審內容改變?}
    ContentChanged -- 是 --> Fork
    ContentChanged -- 否: 僅環境恢復 --> 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

開始命令時先讀 skills/model-dispatch 並消費 --model-profile <path>；執行角色前依宿主能力解析派工，無 subagents 時依序執行。

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

使用

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

流程

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

宿主可並行時，同時觸發兩個角色

只有 model-dispatch 回傳 parallel=true 且未帶 --force-sequential 才並行；否則明示退回先 🟡 爽世、再 🟣 立希的順序版。沒有 subagents 時在主線依序執行。

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

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

Orchestrator 守則（旁白、不自實作、不跳關、commit message draft、fence tracking）依 skills/teammate-flow，並行專屬追加規則： - 真的並行：用宿主支援的並行呼叫觸發 🟡 爽世和 🟣 立希；只有順序能力時依上述 fallback - 不要假裝並行（先爽世完才呼叫立希不算） - 合流時把兩份輸出分開呈現給使用者，不要混在一起

Trade-off

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

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

合流邏輯

爽世	立希	處理
APPROVED	PASS	完成。給使用者 summary
APPROVED	FAIL	回到 🎀 愛音修 failure；受審內容有變就重跑 🟡 爽世 + 🟣 立希，僅環境恢復且內容未變時可沿用 review
NEEDS_CHANGES / BLOCKED	PASS	回到愛音修 must-fix，修完要重跑 Soyo + Taki（不能假設 test 還會綠）
NEEDS_CHANGES / BLOCKED	FAIL	回到愛音兩邊一起修，重跑 Soyo + Taki

合流時兩份結果必須對應同一份變更快照；以 skills/failure-handling 的驗證失敗規則判斷修復後哪些結果已失效。

失敗處理

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

`--force-sequential`

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