4x: Skill for Claude Code

Run History Analysis

跨專案分析 4x pipeline 累積的執行歷史，找出問題模式、優化空間，並量化 Opus/Sonnet 與 Claude/Codex 交叉驗證的實際效益。全程唯讀分析，寫文件（Step 3） 與研究開票可行性（Step 4）都需使用者明確確認才動手，見「注意事項」。

目標專案

預設分析當前 .4x/ 所在專案；使用者若額外指名其他專案路徑（例如同時要看 Kairos），一併納入分析。每個專案獨立派一個 agent（見 Step 1），各自分析。

Step 1: 每個專案各派一個 researcher agent

用 Agent tool，subagent_type: researcher，run_in_background: false（需要等 全部回來才能彙整）。每個 agent prompt 需明確包含：

• 目標 repo 絕對路徑
• 唯讀分析任務（只讀取、比對、彙整，不修改任何檔案）
• 先確認規模：ls .4x/run/ | wc -l、ls .4x/features/ | wc -l
• 優先用聚合工具/既有彙整資料控制讀取成本（逐一讀所有 run 目錄原始 log 成 本過高）
• 以下 4 個維度逐一分析：

維度 1：過去遇到什麼問題、怎麼解決

• 讀 .4x/learnings-context.md（若無則讀 .4x/learnings.json）全文
• grep -c '"needs-attention"\|"blocked"' .4x/run/*/events.jsonl 統計卡住比例
• 讀 docs/reference/discovered-feature-gaps.md（若存在），算已開票率
• 挑 2-3 個具體案例（feature id + 具體卡點 + 怎麼解決），聚焦具體事實而非抽象 分類
• 若使用者提供已知案例作對照，要求 agent 找新的、還沒提過的案例

維度 2：有什麼可以優化的地方

• 從 learnings 的 process 類條目找「重複發生但架構性尚未解決」的模式
• 跑 4x cost --by-round --json（repo 根目錄；若無 bin/4x 用系統 4x 或 make build）量化 retry（round≥2）佔總成本比例
• 找明顯偏貴/偏慢的 role/phase

維度 3：Opus vs Sonnet 效益

• 讀 .4x/settings.json 的 roles.*.model，確認哪些 role 用 opus/sonnet （fallback 邏輯見 internal/protocol/model.go）
• 跑 4x cost --json（by-role）拿 calls/totalUsd/avgUsd
• 交叉比對：貴的 opus 角色是否真的换來更低的失敗/retry率，還是純燒錢
• 點出任何 --phase-override 造成的臨時 model 覆蓋，避免歸因錯誤
• 若專案已有 docs/reference/model-routing-recommendations.md 這類既有分析， agent 應先讀過，只補充新發現

維度 4：Claude/Codex 交叉驗證效益

• 搜尋是否有 run 曾用 --phase-override <phase>:codex:... 或指定某 role 用 codex runner（grep events.jsonl/run.log 找 codex，或看 state.json 的 runner/runners 欄位）
• 找到的話，具體看那一輪 codex 當 reviewer 時抓出的問題，跟同 feature 若曾用 claude 審過的結果比較
• 樣本小要誠實說明，避免過度推論成通則

每個 agent 產出結構化報告（4 維度各一段，具體數字/feature id/檔案路徑佐證）， 控制在 800 字內，多用條列。

Step 2: 彙整跨專案綜合報告

等所有 agent 回來後，在主線程彙整（這步不再派 agent）：

• 逐維度比較各專案的數字（表格呈現），標出跨專案一致的模式（例如 retry 佔比、worktree 同步問題）——這類最有參考價值，代表是架構性而非單一專案偶發
• 標出專案特有的模式，分開陳述
• 給每個維度一個明確判讀/建議

直接以文字回覆使用者這份綜合報告（不要用 ReportFindings 工具）。