Director Mode Lite：Claude Code、Codex CLI 與 Grok Build

你將建立什麼

本課建立一套能在 Claude Code、Codex CLI 與 Grok Build 之間移動的操作方法，但不假裝三個工具具有相同 runtime。

可攜的部分包括：

• 一份包含目標、context、限制、done-when 證據與未決問題的 Director Brief；
• 短小的 inspect → change → check → decide 循環；
• director-mode 與 session-relay 兩個核心 Skills；
• 位於 .director-mode/bin/director-relay 的可檢查 helper；
• 位於 .director-mode/bin/director-doctor 的唯讀診斷 helper；
• 位於 .director-mode/bin/director-open 的明確 full-access helper；
• 接收 session 必須重新核對證據的規則。

Authentication 與組織 policy 仍由各 vendor 原生管理。對可信任 workspace，director-open 會選用各 CLI 已文件化的 unrestricted permission profile，不安裝 hook 或隱藏 rule。

Runtime 契約： 預設安裝註冊零 Director Mode hooks，也不加入 deny rule、forced loop、test gate、commit gate 或隱式權限變更。Skills、relay、status 與 doctor 不會呼叫 director-open；full access 仍是獨立的明確啟動選擇。Managed policy 與既有 global hooks 仍可能生效。

為什麼需要三 CLI 方法

真正有用的問題不是「哪一個 CLI 勝出」，而是「下一個有邊界步驟是否能從不同 context 或能力受益」。

Handoff 可能有幫助的情況：

• 長 session 已累積太多不相關 context；
• 需要第二個 CLI 獨立檢查主張或 diff；
• 某工具具備目前工具沒有的專案整合；
• 下一項任務可以分離，且有明確驗收證據。

Handoff 通常有害的情況：

• 任務很小，當前 session 已有準確 context；
• 兩個 CLI 會同時修改相同 files；
• Brief 無法說清楚「完成」；
• Relay 會包含 secrets、推測或未審查 transcript dump。

預設仍應是一個 CLI 加一個有邊界任務。只有協調成本低於節省的 context 時，才加入另一個 CLI。

安裝三個 Adapters

先審查 repository，再使用 v2.1.0 全 CLI 路徑：

git clone https://github.com/claude-world/director-mode-lite.git
cd director-mode-lite
./install.sh --cli all --hooks none /path/to/project

安裝後確認兩個可攜 helpers，並閱讀當前介面，不要猜測：

.director-mode/bin/director-relay --help
.director-mode/bin/director-doctor --json --no-probe
.director-mode/bin/director-open --help

兩個核心 Skills 是 director-mode 與 session-relay。它們內建 guide、relay 與唯讀 doctor fallback，因此 plugin-only 安裝仍可運作；shell installer 另外提供完整 project-local guidance、generated agents 與 launchers。

「安裝完成」代表 35 個共用 skills、14 個原生 agent adapters、relay 與 open launcher 已存在，且預設註冊 零 hooks。在你信任的 repository，明確選用原生全能力 runtime：

.director-mode/bin/director-open claude  # bypassPermissions
.director-mode/bin/director-open codex   # never + danger-full-access
.director-mode/bin/director-open grok    # always-approve + sandbox off

使用 Grok 前，以 grok inspect --json 稽核 effective hooks。即使 .grok/hooks 為空，Grok 仍可能繼承 Claude 相容 hooks。

升級舊版時，以 ./install.sh --update --cli all --hooks none /path/to/project 移除 Director-owned hook registrations。Cleanup 會保留無關、custom 與 modified hooks；執行後審查 diff。

Session 接續有清楚的 provider 邊界。同供應商沿用原生 resume：Claude Code 使用 --continue 或 --resume，Codex 使用 resume 或 exec resume，Grok 使用 --continue 或 --resume。跨供應商一律從 portable packet 開新的接手端原生 session；來源 session ID 只是 metadata，不是可攜 resume token。

Director Brief

完整 transcript 不是好的協調格式。它混合觀察、猜測、放棄的計畫、工具 output 與私密細節。Director Brief 只攜帶下一位 worker 真正需要的契約。

目標
新增一個可觀察行為。

CONTEXT
- 相關 files 與 documentation
- 目前行為或 exact error
- 已做的決定與原因

限制
- Scope 與 architecture 邊界
- Compatibility 要求
- 權限 profile 明確：原生啟動，或在可信任 workspace 使用 director-open

完成條件
- 具名 tests、lint、type checks 或 build commands 通過
- 聚焦 diff 符合要求行為
- 人工 review 無 blocking concern

未決問題
- 下一個 session 編輯前必須確認的事實

五個設計原則讓 Brief 保持可信：

1. 分開觀察與推論。「Test X exit 0」是觀察；「功能正確」是推論。
2. 寫出 paths 與 commands。「測試通過」不如具體 command、exit status 與相關 output。
3. **把限制帶往下一站。**遺失 compatibility 或安全邊界的 relay 已經損壞。
4. **記錄不確定性。**Open question 比虛構確定性安全。
5. **保持精簡。**連結到 source files，不貼整個 repository 或 transcript。

把方法轉譯到每個 CLI

任務契約保持一致，但長期指引應留在各工具原生 project surface。

CLI	長期指引	Session 入口	開放 profile
Claude Code	CLAUDE.md 與已安裝 Claude assets	director-open claude 或原生啟動	bypassPermissions
Codex CLI	AGENTS.md 與已安裝 Codex assets	director-open codex 或原生啟動	never + danger-full-access
Grok Build	.grok/agents 與相容 assets	director-open grok 或原生啟動	always-approve + sandbox off

Codex 的 AGENTS.md 應保持務實：repository layout、支援 commands、慣例、限制與驗證方式。只屬於當前任務的細節放在 prompt。director-open codex 改的是 launch profile，不是 instruction precedence。

Claude Code 的長期 repository context 放在 CLAUDE.md；Grok 會收到 .grok/agents 原生 agents，也能讀取相容 Claude assets。三個 surfaces 不必逐字相同，重點是以各自原生格式表達同一契約。

Guidance-First 循環

每一輪包含四個動作：

1. Inspect

閱讀 Director Brief，只讀下一個決策需要的 files。以 paths 或 command output 回報目前行為。

2. Change

做能滿足一項驗收結果的最小一致修改。避免兩個 CLI 平行寫入相同 files。

3. Check

執行 repository 真實檢查。好的報告包含 command、exit status、重要 output 與沒有執行的項目。

4. Decide

每輪以一個明確建議結束：

• 接受：done-when 證據已存在；
• 修改：evidence 指出一項有邊界修正；
• 交接：不同 CLI 或新 session 有明確優勢；
• 停止：權限、context、evidence 或使用者意圖不足。

不需要維持 session 存活。未勾選項目只是資訊，不是強迫另一輪的授權。

安全的 Claude → Codex → Grok 範例

假設 Claude Code 已調查失敗 API test 並準備窄幅修正，而你希望驗收前有獨立 review。

階段 A：Claude Code 建立邊界並修改

給 Claude Code：

使用 Director Brief。
目標：修正文件記載的 409 response mismatch。
Context：只檢查具名 handler、schema 與 failing test。
限制：保留 public response shape 與既有安全控制。
完成條件：focused test、type check 與 diff review 提供證據。
一輪 bounded pass 後停止，建議接受、修改、交接或停止。

自行審查 Claude 的 diff 與實際 command output。

階段 B：建立 Relay，再明確審查

請 Claude Code 使用 session-relay。Artifact 應包含：

• exact goal 與 constraints；
• changed files；
• 實際執行 commands 與觀察結果；
• 仍需獨立驗證的主張；
• 下一個有邊界 review request。

新 packet 預設 review_status: unreviewed。先審查 artifact，移除 secrets、無證據主張、過期計畫與無關對話；只有完成明確審查後才加入 --reviewed。Schema validation 與 drift inspection 都不會把它標為 reviewed。

已驗證的 v2.1.0 介面會建立 director-handoff/v2，仍可讀取與驗證 v1 packet，也能準備接收 command 而不啟動另一個 CLI：

.director-mode/bin/director-relay create \
  --from claude \
  --to codex \
  --goal "Review the 409 response fix" \
  --summary "Focused implementation is ready for independent review" \
  --completed "Updated the handler and focused test" \
  --decision "Preserved the public response shape" \
  --next "Inspect the diff and rerun named checks" \
  --verification "pnpm test -- response.test.ts exited 0"
.director-mode/bin/director-relay validate
.director-mode/bin/director-relay status --json
.director-mode/bin/director-relay continue --to codex

第二個及後續 hop 重複執行 create 時加入 --parent（或 --parent <packet.json>）。Protocol v2 會記錄 root、parent、hop 與 route；status --json 會把 packet 捕捉的 branch、HEAD、Git status、diff statistics 與 live worktree 比較，而且不阻擋接續。

最後一行只印出接收 command；除非使用者另外選擇執行選項，否則不會啟動 Codex。接手端從 caller 的 live project root 開始，不會信任 packet path。

階段 C：Codex 獨立 Review

把已審查 relay 交給 Codex，要求它：

1. 讀取適用的 AGENTS.md；
2. 檢查引用 files 與 diff；
3. 執行相關 repository checks；
4. 回報不同意之處或缺少證據；
5. 除非你明確要求修正，否則不編輯。

可信任 repository 可用 director-open codex 啟動接收 session；其他情況照常啟動 Codex。組織 managed policy 仍可能覆寫兩種選擇。

階段 D：只把新問題交給 Grok

只有另一種觀點真的有用時才使用 Grok Build，例如檢查 project rules 與 implementation 是否一致。只 relay 已驗證狀態與這一個問題，不傳整份 transcript。

接收 Grok session 仍要重新檢查引用 files；不能把 relay 當成可信 proof。

Relay 契約

好的 relay 有七個欄位：

欄位	必要內容
目標	一個可觀察期待結果
Scope	包含與排除的 files 或 subsystems
限制	Architecture、compatibility、安全與使用者限制
修改	Changed files 與原因
證據	Commands、exit status、相關 output、diff observations
未知	未驗證主張與剩餘風險
下一步	給接收 CLI 的一項 bounded request

如果 relay 只寫「完成」、缺 command evidence、隱藏 failures、擴張 scope 或暗示新權限，就拒絕它。

衝突與平行規則

三個 CLI 不會自動組成安全團隊：

• 同一時間，一組 files 只能有一位 writer；
• reviewers 預設只讀，直到你要求編輯；
• repository 支援時，以不同 branches 或 worktrees 隔離平行工作；
• 不讓 relay 覆蓋較新的 repository 現實；
• 整合後重新執行受影響檢查；
• Git 與人工 review 仍是 recovery boundary。

若兩個 sessions 意見不同，優先採信目前 source、可重現 commands 與明確 requirements，而不是任一 session 的信心。

驗收清單

• Director Brief 含目標、context、限制、done-when 與未決問題。
• 明確記錄選用原生或 director-open runtime profile。
• 已稽核 effective hook list，沒有 inherited hook 能暗中中斷 handoff。
• Diff 聚焦且只有一位明確 owner。
• 每個 test 主張都有實際 command 與結果。
• Failures 與 skipped checks 都可見。
• Relay 在另一個 CLI 使用前已經審查。
• 明確記錄 review 前，packet 一律視為 unreviewed。
• status --json 沒有發現無法解釋的 live-worktree drift。
• 接收 session 重新檢查引用 files 與 evidence。
• 人工明確選擇接受、修改、交接或停止。

常見失敗模式

Transcript dumping

症狀： 下一個 CLI 收到數千行內容，卻沒有 decision boundary。 修正： 把 handoff 縮成七欄位 relay 契約。

權限混淆

症狀： 無法判斷 session 是原生、fully open，或仍受 managed policy／inherited hook 限制。 修正： 明確選擇原生啟動或 director-open <cli>，再檢查 effective configuration；不可把 relay packet 本身當成 authority。

把狀態當證明

症狀： Checkbox、checkpoint 或 model summary 被當成完成。 修正： 要求 repository-native checks 與 diff review。

平行 file collisions

症狀： 兩個 CLI 修改相同 surface，互相抹除意圖。 修正： 分配不重疊 ownership 或序列化工作。

Relay drift

症狀： Artifact 描述的是建立後已改變的 files。 修正： 與目前 tree 比較，重新產生或標記 stale state。

練習

選擇一個一小時內可解決的真實 issue：

1. 寫五欄位 Director Brief。
2. 用一個 CLI 完成一次 inspect/change/check。
3. 要求 session-relay artifact。
4. 審查並縮短它。
5. 給第二個 CLI 一項 review-only 任務。
6. 比較第二個 CLI 與第一個 CLI 的 evidence。
7. 明確接受、修改、交接或停止。

除非能寫出 Grok Build 或第三個 CLI 特別適合的一項 bounded question，否則不要加入第三個工具。

繼續學習

• 安裝 Director Mode Lite
• 開啟三 CLI workflow 指南
• 設計耐用 CLAUDE.md 指引
• Codex World：AGENTS.md guidance
• Grok World：project rules 與 Claude compatibility

Session 20 將處理 error recovery：分類失敗證據、保留任務邊界，並明確選擇 retry、fallback 或停止。