claude-code-prompts — 拆開一個 AI Coding Agent 的 Prompt 骨架

大部分 AI coding agent 教學的問題不是講錯，是從功能開始，不從問題開始。

「這個工具有幾個 tool call」「這個框架支援哪些 LLM」——這些都不是最重要的問題。最重要的問題是：你怎麼告訴一個 AI agent 它是誰、它能做什麼、它什麼時候該停下來問你？

這個問題的答案，幾乎所有 agent 框架都藏在 prompt 裡——但很少有人完整把 prompt 架構攤開來講。claude-code-prompts 做的事情就是這件：把一個可以實際運作的 AI coding agent 的 prompt 架構整個拆開，38 個 Markdown 檔案，分 7 大類。

這不是「Awesome Prompts」清單

先釐清這個專案跟你可能預期的有什麼不同。

awesome-chatgpt-prompts 是角色扮演清單——「你是一個 Linux 終端機」、「你是一個英文老師」。每個 prompt 獨立運作，彼此沒有關係。

claude-code-prompts 完全不是這個概念。它的 38 個 prompt 是互相連動的系統：system prompt 定義 agent 的身份和權限模型，tool prompts 定義每個工具的使用規則，coordinator prompt 把多個 agent 串接成有組織的工作流，memory prompts 解決 context window 不夠用的問題。把其中任何一塊單獨拿出來用，都不是它設計的使用方式。

這個東西比較像是：有人把一台機器的內部構造拆開讓你看，而不是給你一份操作說明書。

38 個 Prompt，分 7 個層級

整個架構分這幾層：

System Prompt（1 個） — agent 的身份定義。包含權限模型（哪些操作需要確認、哪些可以直接執行）、行為規則、風險分級。這是整個系統的基礎，其他 prompt 都在這個框架底下運作。

Tool Prompts（11 個） — 每個工具一份，包括 Shell、File Read/Edit/Write、Grep、Glob、Web Search、Agent Launcher。設計邏輯很有意思：不是「這個工具怎麼用」，而是「agent 使用這個工具時的思考模式是什麼」。

Agent Prompts（5 個） — General Purpose、Code Explorer、Solution Architect、Verification Specialist、Documentation Guide。每個 agent 有不同的「工作性格」：Code Explorer 會先廣泛掃描再聚焦，Solution Architect 會先問限制條件再給方案。

Memory Prompts（4 個） — 對話壓縮、Session 筆記、記憶萃取、記憶整合。這一塊解決的是 LLM 的根本限制：context window 有限，但工作會跨很多輪對話。

Coordinator（1 個） — 多 agent 協調器。這是整個 repo 裡架構最複雜的部分，後面細說。

Utility Prompts（4 個） — Session Title、Tool Summary、Away Recap、Next Action。比較輔助性質，幫助 agent 管理工作狀態。

Pattern Analyses（9 個） — 每種 pattern 的設計分析 + 可複用模板。這部分其實是最適合用來學習的——它告訴你「為什麼這樣設計」，而不只是「這樣設計」。

Verification Specialist 的設計很值得看

整個 repo 裡品質最高的 prompt，我覺得是 Verification Specialist。

它設計了一個「專門找碴」的 agent。幾個關鍵設計決策：

第一，純唯讀。這個 agent 禁止修改任何專案檔案。唯讀的設計不只是安全措施——它強制讓驗證和實作分離，避免 agent 在「驗證」的過程中順手改了你沒預期它改的東西。

第二，Anti-rationalization 清單。這個清單列了 6 種 LLM 常見的「自我說服跳過檢查」陷阱，包括「測試通過了所以應該是對的」、「這個 case 很少見應該不需要測」之類的。

告訴 AI「你不要這樣想」，是一種很有效的提示技巧——但很多人沒想到要用。類比一下：就像你在做 code review 之前，先把你自己容易忽略的盲點貼在旁邊提醒自己。

第三，Spot-check 警告。prompt 明確告訴 agent：「呼叫你的人可能會重新執行你聲稱跑過的指令。」這個設計很聰明——它利用 LLM 的「遵循指令」傾向，讓 agent 因為「可能被抓包」而真的去跑測試，而不是假裝跑過。

Coordinator Prompt 的 4 階段工作流

這是整個 repo 裡架構最完整的部分。它把一個複雜任務拆成 4 個階段：

Research — Coordinator 並行派遣多個 worker 收集資訊。關鍵：每個 worker 的 prompt 必須完全自包含，因為 worker 看不到你與 coordinator 的對話。這一點很容易忽略，但是非常重要——如果你把 context 放在主對話、然後給 worker 一個簡短的「幫我查 X」，worker 完全不知道 X 是什麼脈絡下的 X。

Synthesis — Coordinator 本人整合所有發現、制定計畫。這一步不委派給 worker。因為整合是一個需要判斷的動作，而判斷需要完整的上下文——只有 coordinator 有。

Implementation — 派遣 worker 執行。Coordinator 在這一步必須提供完整的檔案路徑和行號，不能只說「修一下那個地方」。

Verification — 獨立驗證，不接受 worker 的自我評估。這個設計的邏輯跟 Verification Specialist 是同一個：實作的人評估自己的工作，可信度很低。

Memory Extraction 的持久記憶設計

這一塊解決的是一個實際問題：你跟 Claude Code 一起工作了幾十個 session，但每次開新 session 它又從零開始，不記得你上次說你不喜歡用全域變數、不記得這個專案的 naming convention 是什麼。

Memory Extraction prompt 的設計是讓 agent 在對話結束前，主動從最近幾條訊息裡萃取值得保留的資訊，分成幾類：user preferences（你的偏好）、project patterns（專案慣例）、error corrections（之前犯過的錯）、workflow notes（工作流記憶）。

寫入前要檢查是否已存在等價記憶（去重），而且每條記憶有信心等級：high / medium / low。

這個結構如果你自己做，可以把它存到 CLAUDE.md 的底部，或者存到一個獨立的 memory.md 檔案然後在每次 session 開始時 /read 進來。

使用前的兩個注意事項

第一，這不是 Anthropic 官方產品。是 RepoWise 團隊觀察 Claude Code 的行為模式之後獨立重寫的，不保證跟 Claude Code 實際的 internal prompt 完全一致。用法上是：把你覺得有價值的 prompt 複製出來，根據你自己的技術棧和工具替換佔位符，整合進你的工作流。

第二，專案很年輕。建立時間是 2026-04-01，到現在幾週。GitHub Stars 增長快，但長期維護承諾未知——而且從設計上看，這也比較像 RepoWise 團隊的行銷素材，不是一個以社群維護為目標的開源專案。意思是：現在用沒問題，但不要把關鍵工作流的 99% 都綁在這個 repo 上。