Kanban Orchestrator（看板協調器）

用於協調器角色通過看板路由工作的分解劇本 + 反誘惑規則。“不要親自執行工作”的規則以及基本生命週期會自動注入到每個看板工作者的系統提示中；當你專門扮演協調器角色時，此技能是更深入的劇本。

技能元數據

來源	捆綁（默認安裝）
路徑	skills/devops/kanban-orchestrator
版本	3.0.0
平臺	linux, macos, windows
標籤	kanban, multi-agent, orchestration, routing
相關技能	kanban-worker

參考：完整 SKILL.md

信息

以下是觸發此技能時 Hermes 加載的完整技能定義。這是技能激活時代理看到的指令。

Kanban Orchestrator（看板協調器）— 分解劇本

核心工作者生命週期（包括 kanban_create 扇出模式和“分解，不執行”規則）通過 KANBAN_GUIDANCE 系統提示塊自動注入到每個看板進程中。當你是一個職責完全是路由的協調器角色時，此技能是更深入的劇本。

配置文件由用戶配置 — 並非固定名單

Hermes 的設置差異很大。有些用戶運行一個執行所有操作的單一配置文件；有些運行一個小集群（docker-worker、cron-worker）；有些運行他們自己命名的精選專家團隊。沒有默認的專家名單 — 協調器技能不知道此機器上存在哪些配置文件。

在扇出之前，你必須將分解基於實際存在的配置文件。如果分配給未知的受託人名稱，調度程序會靜默失敗 — 它不會自動糾正、不會建議、也不會回退。因此，在僅擁有 docker-worker 的設置中分配給 researcher 的卡片將永遠停留在 ready 狀態。

步驟 0：在規劃之前發現可用的配置文件。

使用以下方法之一：

• hermes profile list — 打印此機器上配置的配置文件表。如果你有終端工具，請通過它運行；否則詢問用戶。
• kanban_list(assignee="<some-name>") — 對單個名稱進行健全性檢查。對於未知的受託人，返回空列表（而不是錯誤），因此這僅確認你已經在考慮的名稱。
• 直接詢問用戶。 “你設置了哪些配置文件？”當目標需要多個專家時，這是一個很好的首輪問題。

在對話的其餘部分將結果緩存到你的工作記憶中。每輪都重新詢問會浪費一次工具調用。

何時使用看板（與直接執行工作相比）

當滿足以下任何條件時，創建看板任務：

1. 需要多個專家。 研究 + 分析 + 寫作涉及三個配置文件。
2. 工作應能在崩潰或重啟後倖存。 長期運行、重複性或重要的工作。
3. 用戶可能希望介入。 在任何步驟中實現人機協同。
4. 多個子任務可以並行運行。 扇出以提高速度。
5. 預期需要進行審查/迭代。 審查者配置文件對起草者的輸出進行循環處理。
6. 審計軌跡很重要。 看板行永久保存在 SQLite 中。

如果都不適用 — 即它是一個小型的一次性推理任務 — 請改用 delegate_task 或直接回答用戶。

反誘惑規則

你的職位描述說“路由，不執行”。強制執行此規則的規則如下：

• 不要親自執行工作。 你的受限工具集通常甚至不包括用於實現的終端/文件/代碼/Web 工具。如果你發現自己“只是快速修復這個問題” — 停下來併為合適的專家創建任務。
• 對於任何具體任務，創建看板任務並分配它。 每次都要這樣做。
• 在創建卡片之前拆分多車道請求。 用戶提示可能包含幾個獨立的工作流。首先提取這些車道，然後為每個車道創建一個卡片，而不是將不相關的工作捆綁到單個實施者卡片中。
• 並行運行獨立的車道。 如果兩個卡片不需要彼此的輸出，請將它們保持未鏈接狀態，以便調度程序可以將它們扇出。僅鏈接真正的數據依賴項。
• 切勿將依賴性工作創建為獨立的 ready 卡片。 如果卡片必須等待另一個卡片，請在原始的 kanban_create 調用中傳遞 parents=[...]。不要先創建它然後再鏈接，也不要依賴正文中的“等待 T1”之類的文字。
• 如果沒有專家適合可用的配置文件，請詢問用戶要創建哪個配置文件或使用哪個現有配置文件。 不要發明配置文件名稱；調度程序將靜默丟棄未知的受託人。
• 分解、路由和總結 — 這就是全部工作。

分解劇本

步驟 1 — 理解目標

如果目標不明確，請提出澄清問題。詢問成本低；啟動錯誤的集群成本高。

步驟 2 — 繪製任務圖

在創建任何內容之前，大聲草擬出圖表（在你的回覆中向用戶展示）。將每個具體的工作流視為候選卡片：

1. 從請求中提取工作流（lanes）。
2. 將每個工作流映射到你在步驟 0 中發現的某個配置文件（profile）。如果某個工作流不適合任何現有配置文件，請詢問用戶要使用哪個配置文件或創建一個新的。
3. 確定每個工作流是獨立的，還是受另一個工作流的制約（gated）。
4. 創建獨立的工作流作為沒有父鏈接的並行卡片。
5. 創建綜合/審查/集成卡片，並添加指向其所依賴工作流的父鏈接。在父任務未完成時創建的子任務初始狀態為 todo；只有當所有父任務都完成後，調度器才會將其提升為 ready。

應該進行扇出（fan out）的提示示例（使用佔位符配置文件名稱——請替換為用戶設置中實際存在的名稱）：

• “構建一個應用” → 向面向設計的配置文件分配一張卡片以負責產品/UI 方向，向工程配置文件分配一兩張卡片以負責實現，如果用戶有審查者配置文件，則稍後添加一張集成/審查卡片。
• “修復阻塞問題並檢查模型變體” → 為修復阻塞問題分配一張實現卡片，併為配置/源驗證分配一張發現/研究卡片。最終的審查者卡片可以依賴於這兩者。
• “研究文檔並實現” → 文檔研究卡片可以與代碼庫發現卡片並行運行；僅當實現真正需要這些發現時才等待。
• “分析此截圖並查找相關代碼” → 向具備視覺能力的配置文件分配一張卡片進行視覺分析，同時另一張卡片搜索代碼庫。

“also”、“finally”或“and”等詞語並不自動意味著依賴關係。它們通常表示“在彙報之前確保已涵蓋此項”。僅當一個卡片必須等到另一個卡片的輸出存在才能開始時，才鏈接任務。

在創建卡片之前向用戶展示圖譜。讓用戶糾正它——包括每個工作流應由哪個實際配置文件名稱負責。

步驟 3 — 創建任務並建立鏈接

使用步驟 0 中的配置文件名稱。下面的示例使用佔位符 <profile-A>、<profile-B>、<profile-C> — 請將它們替換為用戶實際擁有的配置文件。

t1 = kanban_create(
    title="research: Postgres cost vs current",
    assignee="<profile-A>",  # whichever profile handles research on this setup
    body="Compare estimated infrastructure costs, migration costs, and ongoing ops costs over a 3-year window. Sources: AWS/GCP pricing, team time estimates, current Postgres bills from peers.",
    tenant=os.environ.get("HERMES_TENANT"),
)["task_id"]

t2 = kanban_create(
    title="research: Postgres performance vs current",
    assignee="<profile-A>",  # same profile, run in parallel
    body="Compare query latency, throughput, and scaling characteristics at our expected data volume (~500GB, 10k QPS peak). Sources: benchmark papers, public case studies, pgbench results if easy.",
)["task_id"]

t3 = kanban_create(
    title="synthesize migration recommendation",
    assignee="<profile-B>",  # whichever profile does synthesis/analysis
    body="Read the findings from T1 (cost) and T2 (performance). Produce a 1-page recommendation with explicit trade-offs and a go/no-go call.",
    parents=[t1, t2],
)["task_id"]

t4 = kanban_create(
    title="draft decision memo",
    assignee="<profile-C>",  # whichever profile drafts user-facing prose
    body="Turn the analyst's recommendation into a 2-page memo for the CTO. Match the tone of previous decision memos in the team's knowledge base.",
    parents=[t3],
)["task_id"]

parents=[...] 控制提升（promotion）— 子任務將保持在 todo 狀態，直到所有父任務達到 done 狀態，然後自動提升為 ready。無需手動協調；調度器和依賴引擎會處理此事。

如果任務圖存在依賴關係，請先創建父卡片，捕獲其返回的 id，並在子卡片的 kanban_create 調用中將那些 id 包含在子卡片的 parents 列表中。避免並行創建所有卡片然後再鏈接它們；這會造成一個時間窗口，使得調度器可能在輸入存在之前就認領了子任務。

步驟 4 — 完成你自己的任務

如果你自己是作為一個任務被生成的（例如，規劃者配置文件被分配了 T0: "investigate Postgres migration"），請通過總結你創建的內容將其標記為完成：

kanban_complete(
    summary="decomposed into T1-T4: 2 research lanes in parallel, 1 synthesis on their outputs, 1 prose draft on the recommendation",
    metadata={
        "task_graph": {
            "T1": {"assignee": "<profile-A>", "parents": []},
            "T2": {"assignee": "<profile-A>", "parents": []},
            "T3": {"assignee": "<profile-B>", "parents": ["T1", "T2"]},
            "T4": {"assignee": "<profile-C>", "parents": ["T3"]},
        },
    },
)

步驟 5 — 向用戶彙報

用通俗的語言告訴他們你創建了什麼，並指出你使用的實際配置文件名稱：

我已排隊 4 個任務：

• T1 (<profile-A>): 成本比較
• T2 (<profile-A>): 性能比較，與 T1 並行
• T3 (<profile-B>): 將 T1 + T2 綜合為建議
• T4 (<profile-C>): 將 T3 轉化為給 CTO 的備忘錄

調度器現在將接手 T1 和 T2。T3 將在兩者完成後開始。當 T4 完成時，你將收到網關通知。使用儀表板或 hermes kanban tail <id> 來跟蹤進度。

常見模式

扇出 + 扇入（研究 → 綜合）： N 張沒有父任務的研究風格卡片，一張以它們全部為父任務的綜合卡片。

並行實現 + 驗證： 一張實現者卡片進行更改，同時一張探索者/研究者卡片驗證配置、文檔或源映射。審查者卡片可以依賴於這兩者。不要僅僅因為用戶在同一個句子中提到了兩者，就讓實現者負責不相關的驗證。

帶閘門的流水線： planner → implementer → reviewer。每個階段的 parents=[previous_task]。審查者阻塞或完成；如果審查者阻塞，操作員通過反饋解除阻塞並重新生成任務。

同配置文件隊列： N 個任務，全部分配給同一個配置文件，它們之間沒有依賴關係。調度器進行序列化—該配置文件按優先級順序處理它們，並在其自身記憶中積累經驗。

人機協同（Human-in-the-loop）： 任何任務都可以調用 kanban_block() 以等待輸入。在執行 /unblock 後，調度器會重新生成任務。評論線程攜帶完整的上下文。

陷阱

發明不存在的配置文件名稱。 調度器會在靜默中無法生成未知的指派對象—卡片將永遠停留在 ready 狀態。始終分配給步驟 0 中發現的配置文件；如果不確定，請詢問用戶。

將獨立的工作流捆綁到一張卡片中。 如果用戶要求兩個獨立的結果，請創建兩張卡片。例如：“修復阻塞問題並檢查模型變體”不是一個修復者任務；應為修復工作創建一個修復者/工程師卡片，為變體檢查創建一個探索者/研究者卡片，然後可選地將審查 gating 在這兩者之上。

因措辭而過度鏈接。 “最後檢查 X” 如果 X 是靜態配置、文檔或源發現，可能仍然與實現並行。僅當檢查依賴於實現結果時，才在實現之後鏈接它。

忘記依賴鏈接。 如果任務圖顯示 research -> implement -> review，不要將所有任務創建為獨立的就緒卡片。使用父級鏈接，確保 implement/review 在其輸入存在之前無法運行。

重新分配 vs. 新建任務。 如果審查者以“需要修改”為由阻塞任務，請創建一個從審查者任務鏈接出來的新任務——不要帶著嚴厲的表情重新運行同一個任務。新任務分配給原始實現者配置文件。

鏈接的參數順序。 kanban_link(parent_id=..., child_id=...) —— 父級在前。弄混順序會導致錯誤的任務被降級為 todo。

如果形狀依賴於中間發現，不要預創建整個圖。 如果 T3 的結構取決於 T1 和 T2 的發現結果，讓 T3 作為一個“綜合發現”任務存在，其第一步是讀取父級交接內容並規劃其餘部分。編排器可以生成編排器。

租戶繼承。 如果在你的環境中設置了 HERMES_TENANT，請在每次 kanban_create 調用中傳遞 tenant=os.environ.get("HERMES_TENANT")，以便子任務保持在相同的命名空間中。

目標模式卡片（持久工作器）

默認情況下，分派的工作器對其卡片只有一次機會：它執行工作，調用 kanban_complete/kanban_block，然後退出。對於一輪操作很少能完成工作的開放式卡片，傳遞 goal_mode=True 以將該工作器包裹在 Ralph 風格的目標循環中——這與 /goal 斜槓命令背後的引擎相同：

kanban_create(
    title="Translate the full docs site to French",
    body="Acceptance: every page translated, no English left, links intact.",
    assignee="<translator-profile>",
    goal_mode=True,        # judge re-checks the card after each turn
    goal_max_turns=15,     # optional budget (default 20)
)["task_id"]

其行為方式如下：

• 每次工作器輪次後，輔助評判器會根據卡片的標題 + 正文（視為驗收標準）評估工作器的響應。
• 未完成 + 預算仍有剩餘 → 工作器在同一會話中繼續執行（保留完整上下文——不是全新的重生）。
• 工作器自行調用 kanban_complete/kanban_block → 循環停止，進入正常生命週期。
• 預算耗盡仍未完成 → 卡片被阻塞以待人工審查（粘性阻塞），絕不會靜默退出。

何時使用：長期的、多步驟的或“持續進行直到 X 為真”的卡片。何時不使用：廉價的一次性卡片（單個字符串的翻譯、快速查找）——評判器開銷不值得，且分派器現有的重試/熔斷機制已經處理了臨時的工作器故障。

將正文編寫為明確的驗收標準——評判器的效果僅取決於目標文本的質量。“翻譯 README”比“將 README 的每個部分翻譯成法語；不留任何英語句子”要弱。

恢復卡住的工作器

當工作器配置文件不斷崩潰、產生幻覺或因自身錯誤（通常是：模型錯誤、缺少技能、憑證損壞）而被阻塞時，看板儀表板會用 ⚠ 徽章標記該任務，並在抽屜中打開一個**恢復（Recovery）**部分。三個主要操作：

1. 收回（Reclaim）（或 hermes kanban reclaim <task_id>）——立即中止正在運行的工作器並將任務重置為 ready。現有的認領 TTL 約為 15 分鐘；這是快速退出的路徑。
2. 重新分配（Reassign）（或 hermes kanban reassign <task_id> <new-profile> --reclaim）——將任務切換到不同的配置文件（此設置中存在的配置文件），並讓分派器使用全新工作器拾取它。
3. 更改配置文件模型——儀表板會打印用於 hermes -p <profile> model 的複製粘貼提示，因為配置文件配置存儲在磁盤上；在終端中編輯它，然後執行“收回”以使用新模型重試。

幻覺警告出現在以下任務中：工作器的 kanban_complete(created_cards=[...]) 聲明中包含不存在或非該工作器配置文件創建的卡片 ID（網關會阻塞完成），或者自由格式摘要引用了無法解析的 t_<hex> ID（建議性散文掃描，非阻塞）。兩者都會生成即使在進行恢復操作後仍然存在的審計事件——痕跡保留用於調試。