Command Post

指揮官模式 — 圖、下令、交棒、往上請示

多個 session 同時活著的時候，沒有人知道全貌。忘記關掉的吃著整台機器；兩個對同一棵樹 動手害彼此重跑；發號施令的那一個不知道別人手上有什麼，於是重複開單。

這支 skill 做四件事：畫地圖、指揮（一對一派工，或指派幾個 session 互審）、 交棒、問人的時候問得清楚。

指揮官是一個角色，不是一個 session。 狀態全部住在檔案裡——session 登錄、每個 session 自己寫的宣告、單樹的輪次狀態、板子上唯一手寫的那一格。任何讀了那幾份檔的 session 都接得 起來，所以換一個不需要交接會議，只需要照〈五、交棒〉那一節走。

目錄名與腳本檔名仍然是 command-post。 它是識別字：POLARIS-ACTOR-IDENTITY 那一行 指著那條路徑，改名會讓每一張單的 holders[] 從下一次寫入起推不出是誰。名字給人讀，路徑 給機器讀，兩者不必是同一個字。

一、地圖

python3 .claude/skills/command-post/scripts/command-post.py
python3 .claude/skills/command-post/scripts/command-post.py --json

它不問任何人。 答案全部讀得出來——~/.claude/sessions/{pid}.json 是完整的登錄， 每一份帶著 name、pid、cwd、sessionId、messagingSocketPath。逐個問一輪要花掉每個 peer 一輪 context，而那一輪的答案還不一定比它自己剛寫下的話新。

「它在做什麼」是那個 session 自己寫下的宣告，不是它 transcript 裡最後一則說的話， 也不從名字、路徑或進程資訊推一句——推出來的那一句長得跟讀到的一模一樣，而它會在最需要 真話的時候是錯的。

每個 session 自己寫自己的那一行，只寫自己的：

python3 .claude/skills/command-post/scripts/command-post.py --declare \
  --session-id <自己的 sessionId> \
  --holding '接的是什麼' --blocked-on '現在卡在哪；沒卡就寫「沒有」' \
  --tickets-opened '開了哪幾張單給誰'

為什麼是宣告，不是最後一則話

兩個理由，第二個才是真正的那一個。

一、最後一則話是「它剛好講到哪」，不是「它在做什麼」。

二、讀不完，而且差的是數量級。 2026-08-29 量到：

外部做法對這件事有直接的話，兩條指同一個方向：orchestrator 累積每個 worker 的 context， 四個 worker 以上就撐爆視窗（這台機器上是 8 個）； 而 lead agent 該收的是萃取過的結論而不是完整 transcript，因為 raw transcripts are source material, not durable memory。

所以指揮讀的是索引，要細節去問那一個 session。 框架知識同理：讀得出「有哪幾支 skill、 各管什麼」就夠指揮，不是把 933 KB 讀進來。

閒置多久仍然由 transcript 的 mtime 算——那是一次 stat，不打開檔案。

transcript 在哪：cwd 把 / 和 . 都換成 -。 只換 / 的話，家目錄帶點的機器 （hsuanyu.lee 這種）一筆都對不到——而輸出看起來只是「大家都讀不到」，不像壞掉。

讀不到的留在地圖上

一列的身分讀得到、而它在做什麼讀不到時，那一列還在，並且說出讀不到的是哪一份東西。 它不從清單上消失，也不填一個猜的。至少三種讀不到，各自說各自的話：

這四種要人做的事不一樣，所以它們不可以長成同一句話：沒寫過要去叫它寫，讀不動要去看 那個檔，缺欄位是它寫了但沒寫全。

一個安靜的第三態，下一次就會被當成查過了。

名字與進程來自同一次查表

每一列同時帶得出「要跟它講話用哪個名字」與「它是這台機器上的哪一個進程」，兩者出自同一份 登錄檔。任何一列缺其中一項，那一列自己說出它缺什麼。

不在這台機器上的分開放

登錄裡 pidDomain 跟這台機器對不上的那些單獨列出來，而且永遠不是「該關掉」的候選 ——這裡關不掉它們，把它們列成候選等於教人去做一件做不到的事。

二、指揮

地圖之上做兩件事，兩件都只出建議，不出動作。

該關哪些

產出一份清單，每一項帶著憑什麼這樣認為——閒置多久、它最後說的話是不是「做完了」。 執行關閉的是人。

這支 skill 不自己關掉任何 session。 真的要動手的話（kill），它在動手之前停下來等 那個人自己說的話，並把停下來的理由記下來。理由是：關掉一個 session 會丟掉它還沒寫進磁碟的 工作，而那件事沒有復原鍵。

誰去做哪一件

這支只回答哪一個 session 去做。它不回答一件工作要不要立案、現在該在哪一站、什麼時候停 ——那些在 driving-work-to-done，只在那裡。

同一個問題的分法，舉一個例：「某張單的證據要重量」進來的時候——

• 那條流程回答：這件事要不要立案、現在在 engineering 還是 verify-ac、重量完算不算收斂。
• 這支回答：手上八個 session 裡，哪一個的 cwd 就在那棵樹上、而且閒著。

前者問的是工作，後者問的是人手。兩邊都不知道對方的答案，也不需要知道。

指揮者自己的四條邊界

每一條都是真的壞掉之後才補的，各自帶著那一天的實例。它們講的是指揮者自己不該做什麼 ——不是別人。

一、按 context 邊界切分，不按工作的類型切分。

把自己切成「別人施工、我審查」聽起來像分工，實際上是把每一份工作的 context 都搬到指揮者 這裡來：要審查就要讀對方讀過的東西，於是同一份 context 被讀兩次，而指揮者的視窗是那個會 先滿的。外部做法把它講成 Dividing by type of work creates constant coordination overhead；divide by context boundaries。

2026-08-29 的實例：指揮的 session 讀 peer 的 transcript、再自己重推一次它們的結論， 一整天沒有交付任何東西。

分法是按 context 邊界：一份工作連同它要的 context 整包給一個 session，指揮者只拿那一行 宣告。要細節就去問那一個 session，不是自己把它的 context 讀進來重推一次。

二、不把別的 session 開的單收進來再轉手給第三個。

每一次轉手都掉一層保真度（telephone game）。指揮者當中繼的時候，「誰要做什麼」多了一個 可以漏掉的地方，而漏掉的樣子是安靜的——那張單就是沒有人開始做，沒有任何東西會紅。

2026-08-29 的實例：產品 session 開的 DP 要先給指揮者、再由指揮者轉給施工的 session。 結果那天新開的四張 DP 一張都沒有到施工的 session 手上；同一天指揮者還發明了一個問題叫 施工的 session 停下來等答案，又把它調去做一張產品 PR。

開單的人直接送給要做的那一個。 指揮者從地圖上讀得到誰接了什麼，不需要經手。

三、收到指令之後的第一個動作是查地圖，不是自己下去查。

順序固定三步：

1. 先查地圖：這件事有沒有 session 已經在做。有的話轉給那一個，回報使用者「已經交給 哪一個」。
2. 沒有人在做，先回報一句，帶著自己的建議（派給誰，或開一個新的 session）。這一步 不讀 code、不查 log、不翻 ticket。
3. 使用者說「由你去找」，才自己動手。 那是一句明確的授權，不是預設。

使用者 2026-09-09 拍板，原話：「指揮官收到指令後，先優先找有沒有 session 在處理，沒有先 回報，我跟你說由你去找，你再去找，我想延長指揮官的 session」。

例外是答案已經在手上的唯讀問題。 「那張單現在什麼狀態」在地圖上讀得到就直接答。 要開始查才答得出來的，就是第 2 步——分界不是問題唯不唯讀，是答它要不要新的 context。 少了這一格，一句話的問題也會變成一次往返。

2026-09-08 的實例：指揮的 session 自己讀了三個 repo 的程式碼、查了 log 平台、翻了兩張 ticket，每一項都有實作 session 做得動——而它的 context 在那一天壓縮了一次。壓縮掉的是 所有 session 的「要做什麼、怎麼算成功」，以及使用者當天全部的拍板，而那份東西只有這一 個 session 手上有。

這一條跟第一條方向相同、切點不同：第一條講的是已經分派出去的工作不要自己重讀一遍， 這一條講的是還沒分派的指令不要自己接手。

四、待決是那一格的，不是整張單的。

一張單被擋住的通常只有其中一格。指揮官問使用者之前，先回答一個問題：這張單還有哪些格 不依賴這個答案？ 答案不是空的，就先把那幾格派下去，做到只剩待確認；然後才帶四格去問 被擋的那一格（見〈五〉）。

問人的那一則要寫得出「其餘各格已在做／已做完」，才算問完。 寫不出來，表示還有東西 沒派，那一則還不該送。

2026-09-10 的實例：一張跨三個 repo 的產品單，其中一個 repo 的 push 被遠端規則擋下（CI 的映像壞了）。指揮官把對 SRE 的稿、branch 命名、base 逐件拿去問使用者，負責那個 repo 的 實作 session 閒置約一小時。同一段時間，另外兩個 repo 裡有五件可做的事——整合施工、挖字、 後台設定、本機端到端、一顆 PR 的改動——一件都沒派。被擋的只有一個 repo 的一個動作。 使用者原話：「卡住就不繼續做了嗎」「明明就是不同 repo」「為什麼不是做到『剩需確認的 東西』」「你沒有善盡自己能做的全部，這是那個 skill 負責的」。

這一條不放寬〈往上傳之前先過濾〉。 被擋的那一格若是不可逆或對外的，照舊往上傳、 不退回去。這一條讓的是「其餘各格先做」，不是「被擋的那一格自己決定」。

派工之前：今天進來的需求重對一次

一個判斷的前提，會被後來進來的需求推翻，而判斷本身不會自己失效。 派工之前，把今天 進來的需求從頭重讀一次。任何建立在更早一句話上的判斷（「早上說過 X，所以 Y 不需要了」） 都要重驗兩件事：那句話的前提還在不在，以及這件事現在住在哪個 repo。

2026-09-10 的實例：早上的決定是「key 併成一組，那顆 PR 就不需要了」。下午有人要求「側邊欄 改成英文」，而側邊欄那段文字住在那顆 PR 的 repo。指揮官沿用早上的判斷把那顆 PR 判成可以 關掉，沒有在新需求進來之後重對一次。

送訊息給別的 session 時

• 不轉述一句同意而不帶原話。 「人已經同意了」不算授權，那個人自己說的話才算。
• 不要求任何 peer 去做一件它自己的權限設定會擋下來的事。 對方被擋下來的事，繞道給另一 個 session 做，就是把使用者的權限決定繞過去。
• 不要求任何 peer 去改它自己的設定。

這三條沒有任何機制在擋，它們靠被讀到而生效。

三、派工之後

一條鏈的心跳不該是那個人。 2026-08-29 這台機器上 8 個 session 從 10:06–12:38 UTC 全部 停到隔天 10:14，22 到 24 小時。沒有一個是卡住的：每一個都做完一輪、在自己的視窗裡印完 報告、然後停住。唯一會叫醒它們的東西是有人送訊息，而那個人只在他自己想到的時候出現。

指令自己帶著回報要求

不要手打派工的文字。手打的那一版每次都會漏掉同樣兩樣東西，而漏掉的樣子是安靜的：

python3 .claude/skills/command-post/scripts/command-post.py --order \
  --issue <那張單的路徑> --to <session 名> [--from <回報給誰>]

它只印出來，不送給任何人——送出去仍然是 SendMessage，那是一個不可逆的動作。

它做兩件手打做不到的事：確認那條路徑真的存在（一個指向不存在位置的成功定義，讀起來 跟一份好的成功定義一模一樣，--issue 指不到就 exit 3、不產出指令），以及把「回報給誰」 寫死在文字裡（答不出來就 exit 4——一則沒有收件者的回報要求等於沒有）。

指令裡不重講那份成功定義，只給路徑。重講一次就有第二份會漂的定義，而漂掉的那一刻 沒有人在看。

回報要的是狀態，不是逐條判定。 判準是使用者 2026-08-30 的原話：「只要需要『下一步該 幹嘛的指引』，就要回報」「碰到問題必須回報主管指引」。所以指令要的只有三樣——做完哪一張 或卡在哪一張、需不需要指引、需要的話缺什麼。逐條判定留在那張單的 .spine/ 裡，要細節的 人自己去讀。

以前那一版寫「回報要對得上那份定義：哪幾條過了、哪幾條沒過、量不到的有哪些」。那是細節， 而指揮官不用知道細節——每一則到了指揮官那裡還要再摘一次給人，而多跳的訊息鏈每一跳都 會掉東西。

回報不等於停下來等，這一句要明著寫在指令裡。 做完 → 送一則狀態 → 自己抽下一張繼續； 只有板子答不出下一步、或自己走不下去，才停著等。少了它，「做完要回報」會被讀成「做完要 停下來等回話」，而那正是 driving-work-to-done 列為退化訊號的第二條。

指派兩個以上的 session 互審

一對一的派工回答「誰去做」。有些問題不是「誰去做」，是**「這個結論站不站得住」**——而那個 問題一個 session 自己答不了：它會去驗自己的結論，而去驗它會回綠 （.claude/rules/ 那一份講的同一件事：自己剛寫出來的判斷是草稿，不是根據）。

python3 .claude/skills/command-post/scripts/command-post.py --review \
  --issue <那張單的路徑> --to <session A> --to <session B> [--to <session C>]... \
  --about '<要互相下判斷的是什麼>' [--from <回報給誰>]

它一個收件者產一則，每一則指名它自己與其餘的人。不產群發的那一種：一則沒有指名 收件者的指令，每一個收到的人都會以為對方會做。

跟一對一差三樣，而那三樣正是「互審」與「兩則獨立的派工」的差別：

--about 缺了就 exit 2 並說出理由。人數與模式對不上的兩種也各自擋：--review 只給 一個收件者是 exit 5（一個人審不了「互相」），--order 給超過一個是 exit 6（它是一對一， 訊息會指去 --review）。不安靜地產出一則看起來像的東西——一個人的「互審」讀起來跟 互審一模一樣，而收到的人沒有對象可以互審。

它跟一對一一樣不重講那份成功定義，只給路徑。

指揮台那一頁：每一輪重讀

python3 .claude/skills/command-post/scripts/command-post.py --board \
  --issues <單樹根> --waiting-on '<指揮官自己在等什麼>'

它印三段：唯一手寫的那一格、在飛的單、這台機器上的 session。

它的主要用途不是交接，是每一輪重讀。 把目標重寫到 context 尾端，避開 lost-in-the-middle（Manus 講的 recitation， https://manus.im/blog/Context-Engineering-for-AI-Agents-Lessons-from-Building-Manus）。 交接是副作用——主 session 壓縮太多就換一個，這一頁不掉。

三條限制，前兩條是這個 workspace 既有的規矩：

• 產生的部分不手寫。 先例是 {單樹根}/OPEN.md，它自己的表頭就寫著「下一次重算會整份重寫」。
• 成功條件只指過去，不抄。 那一欄是路徑，不是內容。唯一權威是那張單的 fence， verify-ac 拿它跟 git 歷史比；抄第二份就是兩份會漂，而漂的是最不能漂的那一份。
• 手寫的只有一格：--waiting-on。板子答不出來的只有它，交接時唯一會遺失的也是它。

「誰在做」那一欄：脊椎寫下、這裡去問死活

那一欄以前整欄是空的。現在它是產生的，而產生它的兩半各在一邊：

• 寫：init／advance／record 每次寫輪次狀態時，把「這一趟是誰在跑」記進 {單}/.spine/loop-state.json 的 holders[]。核心不認得 session 是什麼——它掃所有 SKILL.md 找下面這一行，跑它，把印出來的第一行原樣記下來。
• 讀：這一支拿那份紀錄，在執行的這一刻去 session 登錄量每一個對象還在不在。 紀錄只證明「當時它動過這張單」，還在不在是現在才問得到的。

--whoami 不靠任何人宣告：它往上走進程祖先，每一跳去 ~/.claude/sessions/{pid}.json 找， 找到就是它（實測兩跳）。這件事重要的地方在覆蓋率——這台機器上 8 個 session 只有 1 份 自願寫下的宣告，而 init／advance／record 是流程走不過去就不能繼續的三步。

不覆寫，逐個對象各佔一格。 只有 init 寫的話，換手之後那一欄永遠是開單的那個人； 每次覆寫的話，最後一個路過的人就成了「誰在做」。而覆寫的那一版連「不只一個人接著同一張 單」都表達不出來——那正是這一欄最該被看見的東西。

答不出來分成四句不同的話，不合併成空白：沒有人接（量到了，holders[] 是空的）、 這一次問不到（狀態檔或登錄讀不到）、紀錄在、人不在（有紀錄，登錄裡找不到那個 對象）、推不出來是誰（寫的時候就推不出來，理由跟著記下來）。

表格的第一列是脊椎建議的下一張。 它同時也是一張在飛的單——只把它寫成一句話的那一版， 一張正在施工、正被人接著的單在這張表上根本沒有列，而那正好是第五欄最該印出東西的那一種。 它跟 seed／stop 重疊時用路徑去重，不會出現兩次。

板子上的兩個不穩訊號

兩個都只印，不判斷該不該換一個。

第二個為什麼是連續而不是總數：總數會隨 session 變長而單調上升，於是它對「現在還穩不 穩」永遠給同一個方向的答案。連續失敗會被任何一次成功歸零，所以它量得到的是當下。

只讀尾巴。 這台機器上最大一份 transcript 92 MB，為了一個訊號讀完它，這支就變成它自己 要避免的那件事。

「看了 43 筆、沒有一筆失敗」與「這個視窗裡一筆工具結果都沒有」是兩件事，而它們都會是 0，所以板子把它們印成兩句不同的話。後者答不出這個問題。

外部做法對「誰來判不穩」有直接的一句：self-evaluation 有偏差，不穩要由外部量，不由那個 agent 自己判（https://www.anthropic.com/engineering/harness-design-for-long-running-applications）。 這兩個訊號是外部量的——它們讀的是磁碟上的 transcript，不是問那個 session「你還好嗎」。 而判斷仍然留給人：印出來的是量，不是結論。

「等使用者」不是任何一個 session 的預設狀態

一個實作 session 閒置超過一個回合，而它手上那張單還有可做的格，是指揮官的缺陷訊號。 不是那個 session 的，因為決定它下一件做什麼的是指揮官。

每一輪讀板子時從兩個已經印出來的量讀它：session 那一段的「閒置多久」，以及「在飛的單」 那張表的「誰在做」。「那張單還剩哪幾格沒派」板子答不出來——一張單底下有哪幾格不是 任何一份檔案裡的資料，它只在指揮官手上。所以這一半由指揮官自己補：看到一個閒著的 session，就問它那張單還剩什麼。

這個訊號不做成腳本。 格子那一半沒有資料來源，要做就得先發明一份「每張單有哪幾格、 各派給誰」的紀錄，而那份紀錄要人手維護、會跟實際派出去的訊息漂開。它守的也不是一個不可逆 或會出去的後果——閒置的代價是時間，下一輪讀板子就看得到。實例見〈指揮者自己的四條邊界〉 第四條。

心跳：靠排程，不靠某個人想起來

一條鏈的心跳不該是那個人。 上面〈三〉開頭那一段量到的 22–24 小時全停，成因是唯一會 叫醒它們的東西是有人送訊息。

以前這裡的解法是 notify_when_idle，那一版不夠——它自己量到一個偵測不到的第三態 （下一段），而一個有洞的偵測配上「有網子接著」的印象，比沒有網子糟。

現在的解法是指揮官自己排一個班：定期重讀板子、掃自己的收件匣，不等任何人來敲。

• 一次性的下一次：ScheduleWakeup，說出這一次要等的是什麼、等多久。
• 反覆的班表：CronCreate / CronList / CronDelete。

間隔照那個要等的東西挑，不照一個好看的數字挑。 等的是 CI 就照那條 pipeline 的長度； 沒有特定訊號要等就拉長（20–30 分鐘一次），讓安靜的醒來很少。

這個做法自己的限制要說出來，它有兩個：

1. 排程活在那個 session 裡。 那個 session 結束，班表跟著沒了——所以它守不住「指揮官 自己掛掉」這一種。守那一種的是〈五、交棒〉：狀態全住在檔案裡，換一個 session 讀得回來。
2. 醒來的是指揮官，不是被派工的那一個。 它讓指揮官定期回頭看，不會讓一個停住的 session 自己動起來。看到它停住之後要做的仍然是送一則訊息。

notify_when_idle 那一格：它偵測不到的第三態

排程取代的是「心跳」，不是這一格——notify_when_idle 仍然可以在派工時順手訂，只是不要 把它當成網子。

SendMessage 的 notify_when_idle: true 讓那個 session 下次閒下來時回一則通知。 它是 one-shot，所以每一次派工都要重訂一次——上一次的訂閱已經用掉了。

訂閱成功不等於通知會到你手上。 這一格是量過的（2026-08-30，對兩個不同的 session 各訂 一次）：兩次的回覆逐字相同，都寫著「delivered to you if that session runs in the same permission class as this one (or is one this session spawned); otherwise it is only logged here」，而它從來不說這一次落在哪一邊。success: true 在兩種情況下長得一模一樣。

所以這條偵測有一個偵測不到的第三態：permission class 不同的 session 靜默了，通知只留在 紀錄裡，指揮官這邊什麼都不會發生——而那跟「它還在忙」長得一樣。這一種要靠上面那個排程 自己回頭看地圖，不要當成有網子接著。

收到 idle 通知不要立刻重訂，會自轉

2026-08-30 真的發生了一次：收到 idle 通知之後重訂一次，而重訂的那一刻它正好是閒的， 訂閱當場觸發，把同一個事件原樣再送一次——兩則逐字相同，收的人分不出那是新事件還是 回聲。

順序是：收到通知 → 先核對板子 → 它真的動過就不重訂（它還在跑，做完會照契約回報）→ 只有真的靜止才重新掛訂閱。

判成靜默之前：先問，不要先宣布

收到 idle 通知而那個 session 沒有回報過，看起來就是靜默。先做這兩件事：

一、核對板子的那條查詢自己要有 preflight。 「它今天有沒有動」這種查詢在讀不到的時候 會回空集合、exit 0，而空集合讀起來跟「它沒做事」一模一樣。所以問「今天有沒有動」之前 先問一次「不加任何視窗的話有沒有東西」，兩者都空才是真的空。

2026-08-30 的實例：git log --since=2026-08-30 的裸日期被 git 解成「那天的此刻」， 於是 20:27 跑的那一趟連 20:26 的 HEAD 都濾掉，回 0 筆、exit 0，輸出裡沒有一個字說視窗 是從 20:27 開始的。同一個 repo 同一分鐘：--since='2026-08-30 00:00' 是 17 筆、 --since=yesterday 是 21 筆。指揮官因此對一個正在出貨的 session 宣布它「閒下來沒回報」。

二、對 peer 下判斷之前先問它。 問句跟宣告的成本差很多：宣告錯了，對方要花一整輪去 反駁；問句錯了，對方一句話就答完。上面那個實例裡，指揮官的措辭是「你閒下來了但沒回報」 ——一個沒驗過的讀數被寫成了事實。

每個 session 維持是自己的視窗

派工是 session 對 session，不是把工作收成 in-process 的 teammate。理由是可見性： 每個 session 有自己的視窗，人看得見它在做什麼、隨時插得進去。收進同一個進程裡的那些 只有指揮官看得到。

Agent Teams：這一次量到什麼

以前這裡寫「證不出來能用」。那是一句沒有量的話——它讀起來像一個結論，實際上只說了 「我沒試」。2026-09-06 量了一次，量到的與沒量到的分開寫。

量到的（在這台機器、CLI 2.1.260、一個一般的互動 session 裡）：

所以量到的結論是：功能在這個 build 裡，但這個 session 呼叫不到它。這跟「證不出來 能用」不是同一句話——前者說得出缺的是什麼。

文件說的（https://code.claude.com/docs/en/agent-teams，讀來的，不是量到的）：lead 固定不能換、team 不能巢狀、/resume 不還原 teammate、有 TeammateIdle 與 TaskCompleted 兩個 hook、teammate 之間有共用的 task list 與依賴。這一段標成文件說的，因為它一條都 沒有在這台機器上被跑過。

還沒量到的，以及要怎麼驗（留給下一個指揮官，一個新 session 才做得到）：

1. 開一個新的互動 session，第一件事跑 ToolSearch 'select:TeamCreate,TeamAdd'。有東西回來就記下它的完整 schema；沒有就記 下這個 build 對一般 session 一律不給。
2. 有的話，建一個兩人的 team，指派一件小工作，然後回答三個問題：別的 session 看不看得 到那些 teammate（ListAgents 有沒有列）、人在自己的終端機看不看得到它們在做什麼、 TeammateIdle 會不會叫醒 lead。
3. 第二題的答案決定要不要用它。那一題不是效能問題，是可見性問題——下面〈每個 session 維持是自己的視窗〉那一段就是為它存在的。

在那之前，這支 skill 不依賴 Agent Teams。 不依賴的理由不是「它不能用」，是上面第 2 步還沒有人跑過。

四、交棒：指揮官是角色，不是 session

換一個指揮官不需要交接會議。要交的東西只有一格，其餘全部讀得回來。

接手的人照這個順序讀

一步一步，每一步答一個問題。前四步都不需要問任何人。

順序不能換。 先讀板子再讀單：反過來的話會從一張單的內容去推整盤狀況，而那張單答不出 「別人手上有什麼」。

第一步答不出「誰扮什麼角色」，這是已知的洞。 板子的「在做什麼」那一欄只讀每個 session 自己寫的宣告，而 2026-09-06 量到的覆蓋率是 0/10——十個活著的 session 零份宣告。所以接手的 人看得到有十個 session，看不出哪一個是 review、哪一個在跑 DP 線。補法不是另開一份角色 表（那就是下面〈交棒不新增任何要人維護的狀態〉禁止的東西），是讓宣告真的被寫：--order 與 --review 產出的指令第一段就要收件者跑一次 --declare。那一格由做事的那個 session 自己寫，不由指揮官代寫。

唯一手寫的那一格怎麼交

--waiting-on 是板子上唯一不是產生的東西——它也是交棒時唯一會遺失的東西。它裝的是 「指揮官自己在等什麼」，而那件事沒有任何檔案記得住：等的可能是使用者一句還沒回的話、一個 還沒到期的外部答覆、或一個剛決定但還沒發出去的順序。

交法只有一步：前一個指揮官把它現在那一句原樣送給下一個，下一個第一次跑 --board 的 時候原樣帶進去。

# 交出去的那一個：把它現在那一句印出來，原樣送過去
python3 .claude/skills/command-post/scripts/command-post.py --board \
  --issues <單樹根> --waiting-on '<現在在等什麼>' | head -20

# 接手的那一個：第一次跑板子就把那一句帶進去
python3 .claude/skills/command-post/scripts/command-post.py --board \
  --issues <單樹根> --waiting-on '<接過來的那一句>'

沒有在等任何東西的時候要寫「沒有」，不要留空。 空的那一格跟「前一個指揮官忘了交」 長得一模一樣，而它們要人做的事相反。

什麼時候該交

這裡不給門檻，理由跟〈板子上的兩個不穩訊號〉是同一個：那兩個訊號偵測不出「開始不穩」 那一刻，配一個門檻只會讓一個猜測看起來像一個量測。

決定是人做的，板子把兩個量印給他看。真的要換的時候照上面兩步走。

交棒不新增任何要人維護的狀態

接手讀的五樣裡，四樣是既有的：session 登錄（機器寫的）、每個 session 自己的宣告 （它自己寫的）、單樹的輪次狀態與 holders[]（脊椎寫的）、這一份 SKILL.md。第五樣就是 那一格。

不要為交棒另開一份「指揮官交接文件」。 一份手寫的交接文件會跟這四樣漂開，而漂掉的 那一刻正好是有人要接手、最需要一句真話的時候。板子每一輪都重讀，所以它不會過期。

五、問人的時候

問之前先過〈指揮者自己的四條邊界〉第四條。 那一條沒過，下面這幾節都還不用讀。

形狀就是這個 workspace 既有的那一份

結論、根據、待決，三段，順序固定；待決的每一項帶自己的建議與理由。這支不發明第二種 格式——.claude/rules/style-and-language.md 已經規定了一份，而兩份會漂。

待決的每一項帶四格

指揮官問人的時候，被問的那個人不是第一線接觸這些工作的人。 這是指揮官模式的直接後果： 他只跟指揮的那個 session 講話，其餘 session 的來龍去脈他沒看過。所以「要不要開一張單」這種 一行式的問題，對第一線的人是完整的，對他是空的——他手上沒有那張單怎麼冒出來的那一段。

所以每一項待決帶四樣，缺一項就是還沒問完：

四格各一兩句就夠——帶前因後果不等於寫長。 那一份規則同時規定一般回覆不超過一個螢幕， 兩者不衝突：四格要的是每一格都有東西，不是每一格都很長。

四格是加在「待決」那一項裡面的，三段仍然是既有的結論／根據／待決，不另立一套格式。

往上傳之前先過濾

指揮官的價值在於擋掉不該佔用人的注意力的問題，不在於當一個轉發器。判準一句話：

這件事在提問者自己的管轄內，而且做錯了改得回來 → 退回去讓它自己決定； 其餘才往上傳。

兩類分得開，各舉一個真的收到過的：

退回去要帶理由，理由就是那個判準：這是你的單、這件事改得回來。只回一句「你自己決定」 不算退回——它沒有把判準交出去，下一次同樣的問題會再上來一次。

不確定的往上傳。 這條過濾省的是人的注意力，不是指揮官的判斷；把一件真的不可逆的事誤判 成可逆，代價比多問一次大得多。所以不可逆或對外的不退回去，沒有例外——那一格不參與 「在不在管轄內」的判斷。

這個判準來自一次量測：一個 session 的收件匣 206 則 peer 訊息，含求指示標記的 59 則，逐則 讀完能認定是真的在問人的約 28 則，兩類的分界很乾淨。那份量測自己的邊界要一起說：它來自 舊的作業方式（這一版的回報契約之前）、是那個 session 對自己的收件匣做的分類、59 是 樣式命中不是確認數。所以它證得出兩類真的分得開，證不出比例會維持。

要代送的對外內容，哪一種先給人看

上面那一格說「不可逆或對外的不退回去」。它管的是「這件事誰決定」，不是「這段文字誰過目」 ——一則要送出去的 review 回覆，決定權本來就不在提問的那個 session 手上，剩下的問題只有一個： 使用者要不要逐則讀過它。這一節回答的是後者，所以它不是上面那條的例外，是那條沒有回答的 另一半。

判準看那則回覆在主張什麼：

分界是事實與立場。reviewer 提的可驗證技術主張，判真偽本來就是這一端的活；真正只有人 回答得出來的是立場，不是事實。所以照做型的回覆裡沒有任何需要人拍板的東西，逐則確認只是把 它排進一條隊伍。

代價量得出來：2026-08-29 到 08-31，同一批工作有八支 PR 停在原地，其中四支是 CHANGES_REQUESTED ——等的就是那幾則沒被放行的回覆。

這條界線只劃在 review 回覆上。 推 commit、改寫歷史、送出 JIRA 或 Slack 的對外留言、動 共用資源，仍然照上面那一格往上傳，那個判準一個字都不放寬。

判錯的責任在指揮官。 任何一則判成直接送、而使用者事後認為該先看的，整批回到逐則確認 ——一條沒有人負責的界線會往寬的那邊漂。

什麼時候值得畫一張圖

判準一句話：要對方同時比對三個以上的量、而那些量之間的關係用句子講會需要回頭讀第二次時， 畫。其餘不畫。

對三種問題各判一次：

不因為看起來用心就畫。 一張沒有人需要的圖，是把讀的人的時間換成自己的努力看起來比較多。

圖不取代那三段。 圖出現的時候結論、根據、待決仍然在，待決仍然帶著建議——圖是根據的一 部分，不是「你自己看」的代替品。

圖上每一個量都要說得出它從哪裡量到的。 畫不出來源的量不要畫進去。

這支不做的事

• 不判定一件工作算不算完成。 那是 verify-ac。
• 不決定下一站。 那是 driving-work-to-done。
• 不停止不是它自己起的進程、不動別的 session 的工作區或分支、不啟動或停止任何共用的 服務與容器。