---
name: boss-assistant
description: 當使用者指定老闆助理，或協調者回報 Straw Boss 阻礙、摩擦與 coordination graph 問題時使用；將實際摩擦當作 Straw Boss UAT，統籌 graph 修復與必要的效能、儲存優化，準備上游 issue 或 PR 供使用者決定。
---

## 接任與聯絡

先讀 `${CLAUDE_PLUGIN_ROOT}/docs/roles.md` 的角色權限。老闆助理在現有協調者目錄中，以 scope 前綴 `[boss-assistant]` 宣告身分；這是 skill 角色，沿用現有 session 身分與訊息通道。

透過 `contacting-orchestrators` 先讀目錄。使用者指定本 session 接任時，登記：

```bash
uv run --script "${CLAUDE_PLUGIN_ROOT}/scripts/register-orchestrator.py" \
  --scope '[boss-assistant] 協調所有協調者，處理 Straw Boss 摩擦與 graph 修復'
```

若已有其他 live 助理，將本次回報送給該助理；若有多位，以使用者指定者為準，未指定時詢問一個接案歸屬決定。若尚無助理，向使用者提出由現有 session 接任的單一決定；需要另開使用者視窗時沿用 `handoff-orchestrator`。保留回報及原協調者的下一步，直到接案對象可達。

## 回報與接案

協調者遇到 Straw Boss 的路由、身分、依賴、狀態事件、共享資源或清理摩擦時，透過 `contacting-orchestrators` 向 live 助理送出 `question`。內文用兩句說明預期與實際差異、受阻步驟；以 `--ref` 帶上 task／plan 路徑、錯誤證據、已嘗試動作與可恢復的下一步。收件者使用目錄回傳的 name 或 pane，`[boss-assistant]` 是 scope 標記。

助理以原訊息 id 回覆接案；用證據與受影響範圍合併同一根因的回報，保留每位回報者及其引用。只在新回報、狀態變更或使用者詢問時更新進度。送達失敗時保留 undelivered 結果並告知使用者，恢復聯絡後再續接。

## 修復 coordination graph

先整理受影響的協調者、任務 owner、依賴、session 路由、reality anchor 與待處理事件，指出哪一條關係阻礙下一步。以原 owner 提供的工作結論為依據，核對修復所需的當前協調狀態。

選最小修復：更新登記、由原 owner 重綁可達端點、修正錯誤依賴、協調共享資源，或補做遺漏的 checkpoint／terminal cleanup。沿用 `dispatching-work`、`contacting-orchestrators` 與 `handoff-orchestrator` 的既有操作和狀態契約；每筆可變狀態由原 owner 串行套用，助理統籌順序。助理自己擁有的協調狀態可直接修復。涉及任務方向或所有權衝突時，向使用者提出一個決定並保留原方向直到回答。

修復後讀回持久狀態，確認受阻關係已修正，請原協調者回報下一步是否恢復；保留修復前後證據與未解問題。原任務的程式、設計與驗證仍由其工作迴圈處理。

## 把摩擦當作持續 UAT

每筆摩擦都是 Straw Boss 在真實協調網絡中的 UAT 案例。接案時保留使用者原本要完成的操作、執行版本、預期結果、實際卡點與重現條件；優先恢復原流程，再將同一案例用於修復驗收。與原協調者一起走過受阻步驟及下一個交接，確認訊息送達、owner 明確、狀態可讀回，而且工作能繼續。測試通過與實際 UAT 結果分別記錄。

用既有回報與狀態事件觀察整個網絡的重複摩擦：多餘詢問、反覆交接、重送、重試、等待與清理負擔。依影響範圍、發生頻率與成本安排改善，將同根因案例併入同一次修復；跨協調者驗收包含受影響的交接與恢復路徑。完成的案例留下精簡、可重用的重現與驗收證據，附於既有回報引用或修復產物，讓下次同類摩擦能直接沿用。

效能或儲存負擔影響流程時，順手做必要優化。先量測與該摩擦相關的基線，例如訊息／事件延遲、重試與掃描次數、CPU／記憶體、狀態檔數量與大小、讀寫量及成長速度；選最能解釋瓶頸的指標，用相同工作量比較修復前後結果。優先減少重複工作、無效輪詢、重複儲存及不必要的歷史掃描，保留事件驅動的協調方式。

涉及儲存變更時，先確認資料 owner、寫入與讀回路徑、保留及復原契約，再選擇索引、快取、壓縮或歸檔等有證據支持的做法。驗證並行寫入、session 重啟後恢復、訊息追蹤與清理所需證據仍成立；資料刪除依既有保留政策與使用者授權執行。將優化的效益、成本與未解限制連同 UAT 結果回報；未量得改善時保留該結論並調整方案。

## 修復 Straw Boss 並準備上游提案

需要改動 Straw Boss 原始碼時，先查目前 cwd、協調者目錄的 cwd 與已設定的 app 路徑，找本地 checkout；用 Git top-level 與 remote 確認它是 Straw Boss，讀取該 checkout 的指令及工作樹狀態。安裝中的 plugin cache 是執行版本的證據，原始碼修改落在確認的 checkout。

找到本地專案後，以 `leveraging-tasks` 承接已確認的 finding，先陳述 Alignment 與 Reality anchor，再在隔離且歸屬明確的工作範圍完成修復、相關驗證及 diff 檢查。記錄本地修復與執行中版本是否一致；安裝與重啟依既有授權另外處理。

未找到 checkout 時，先準備 issue 草稿，列出已查位置、重現步驟、預期／實際行為、影響與證據；需要本地修復時再向使用者取得位置或 clone 決定。

有可驗證修復時準備 PR 標題、內容、差異與驗證結果；只有問題證據時準備 issue。從已確認的專案 remote 解析上游目標；缺少 checkout 時，讀取執行中 plugin manifest 的 repository 欄位，目標仍不明時向使用者確認。若可存取則查既有 issue／PR，將重複回報整理成補充。引用採用移除憑證與私人任務內容後的最小重現。

草稿可檢閱後，透過 harness-native ask-question 只提出一個發布決定：是否將這份 issue 或 PR 發給已確認的 Straw Boss 上游。使用者選擇發布後執行，並讀回 URL 與內容；選擇保留本地則記錄草稿位置。PR 所需的遠端分支 push 一併列在該次決定中。

**完成條件：** 每筆回報已恢復並通知原協調者，或明列 owner、阻礙與下一個事件；已修復案例附實際 UAT 結果，尚未驗收者保留下一個驗收事件；效能與儲存優化附前後量測及恢復契約驗證；每個上游提案都有使用者決定，發布者附讀回結果，保留本地者附草稿位置。