ShiftBlame：用通訊目錄把 Claude / Codex / Gemini 的工作狀態變成可恢復的交接協議
Threads 貼文介紹 shiftblame：一套跨 Claude Code / Gemini CLI / Codex 的 AI agents 協作流程技能，用 symlink 安裝、通訊目錄保存上下文，讓重開對話後可快速恢復工作狀態。整理其 README 架構：管理者、執行者、紅隊、藍隊、PRD/QA/DEV/QC 閘門與降級策略。
這篇 Threads 提到 shiftblame：一套跨 Claude Code、Gemini CLI、Codex 的 AI agents 協作流程技能。作者說新版已經和第一次發布不是同一個物種，流程降成四個步驟、三個 CLI 呼叫，統一用 symlink 安裝，支援單點失效與降級策略；核心功能是不綁上下文，所有上下文都放在通訊目錄中，重開對話後 30 秒內可以恢復上次工作狀態。
我查了 GitHub repo teps3105/shiftblame。README 對它的定位是：「AI Agents 協作開發框架 — 流程協議與定義檔」。它不是一個大型 server，也不是模型代理，而是一套以 Markdown 定義的流程協議與 skill 結構。
核心設計有幾個重點：
一、跨 CLI 的角色分工
shiftblame 把目前所在 CLI 當成管理者與執行者，另外兩個 CLI 預設擔任紅隊 / 藍隊。例如：
• Claude CLI 環境：執行者 claude，紅隊 codex，藍隊 gemini。 • Codex CLI 環境：執行者 codex，紅隊 claude，藍隊 gemini。 • Gemini CLI 環境：執行者 gemini，紅隊 claude，藍隊 codex。
產物分成 result.md、red.md、blue.md，讓同一任務可以有執行者輸出、反方檢查與另一種觀點。
二、通訊目錄保存上下文
README 的文件結構是：
.shiftblame/ ├── REPO.md └── /// ├── task.md ├── result.md ├── red.md └── blue.md
這個設計很實際。LLM 對話上下文會斷、會滿、會換模型、會開新 session；但只要任務狀態、部門階段、紅藍隊意見與結果都落到檔案系統，就能讓下一個 agent 快速接手。
三、PRD / QA / DEV / QC 部門化
shiftblame 把流程拆成 PRD、QA、DEV、QC 四個部門，並用 gate 控制流轉：PRD→QA、QA→DEV、DEV→QC、QC→收尾。每個 gate 都要求執行者 / 紅隊 / 藍隊產出，再由老闆確認；若不通過則退回上游新 NNN。
這其實是在把軟體開發流程變成 agent-readable protocol。
四、降級策略
外部 CLI 遇到 429、rate limit、quota exceeded、billing limit、暫時不可用或重派後仍無輸出時，先由另一個外部 CLI 補上缺少的紅 / 藍產出；如果只剩目前 CLI 可用，就改開本環境子代理分別產出 red.md / blue.md。
這點值得注意，因為真實 agent workflow 最常壞在外部工具與模型配額。把「誰掛了怎麼補位」寫進流程，比假設所有 CLI 永遠可用務實很多。
五、symlink 安裝
README 提供 Claude / Codex / Gemini 三方 CLI 的 symlink 安裝方式，將 repo 裡的 skills/shiftblame 連到各 CLI 的 skills 目錄，再用 install-global-entrypoints.sh 寫入或更新 /.codex/AGENTS.md、/.claude/CLAUDE.md、~/.gemini/GEMINI.md。
這讓同一套流程協議可以被多個 agent CLI 讀到，而不是每個工具各維護一份。
我的判斷：shiftblame 最有價值的地方，不是「三個模型一起工作」這個表層，而是它把 agent context 從聊天視窗抽離出來，落到通訊目錄與 Markdown artifacts。這正好解決長任務的一個痛點：LLM session 不可靠，但檔案系統可靠。
對 BigIntTech / Hermes 來說，這個方向值得參考：
- 長任務不要只靠 conversation history。
- 任務狀態應該落地成 artifacts。
- 每個階段要有明確 input / output / gate。
- 紅隊 / 藍隊 review 應該有固定產物格式。
- 外部模型或 CLI 掛掉時要有 fallback。
- 收尾要清理殭屍程序、dev server、scratch files、build artifacts。
不過也要注意，這類流程框架如果太重，會拖慢小任務。比較好的使用方式是：簡單任務用 L1「執行 → 收尾」；需要規格、測試、開發、驗收的任務才走 L2 PRD → QA → DEV → QC。
一句話總結：shiftblame 是一套把 AI agent 協作從「對話」變成「通訊目錄 + 流程閘門 + 紅藍隊 artifacts」的輕量協議。它真正解決的是 context handoff 與長任務恢復，而不只是多模型互相叫來叫去。