提示代理
讀取者是一個有能力但缺乏你上下文的模型。說明最終必須成立的事實及其原因，然後讓它自行規劃路徑：為模型能規劃的工作所撰寫的路徑會被忠實遵循，即使包含錯誤步驟。包裝形式不同——簡報、交接、技能——但撰寫原則不變。
核心
什麼該放進去。 線測試：讀取者能否從任務及其訓練中推導出這項資訊？ 模型無法查詢的事實、使用者的慣例、契約、硬性限制與完成標準，皆無法通過測試，因此應保留。而模型能規劃工作的路徑則通過測試並應刪除。條件清單是終點狀態；步驟清單是一條路徑。
自足。 一個新的工作階段只會讀取提示與磁碟。每則訊息都攜帶完整的當前規則集，且變更會直接原地套用——絕不採用「與先前相同，加上這些變更」的方式——而每個文件都重新陳述其所依賴的每一條現行規則，絕不採用「如父層所述」的方式。
原因，以正向陳述。 模型從原因進行歸納，因此每條規則都應自帶原因（「每段落保持連續一行，因為聊天框將換行視為有意為之」）。陳述目標行為；禁止會將禁止的行為引入上下文，使其更容易被觸發，因此僅應作為硬性護欄使用，並搭配正向目標。壓力語言（MUST、CRITICAL、大寫）在當前模型上容易過度觸發；請改用「在……情況下使用 X」。
主導詞彙，單一位置，無冗餘指令。 模型已擁有的詞彙（收據、資訊迷霧、緊密循環）勝過片語；使用者自己的術語又勝過前兩者。每個意義只存在於一個位置。讀取者預設就會遵守的句子並無效益：應刪除整個句子，而非刪除其中的詞彙。
提示結構
- 意圖 —— 更大的目標、服務對象、輸出結果能促成什麼；模型會將其用於提示中未提及的微決策。
- 終點狀態 —— 完成時會存在什麼、具有哪些屬性、使用者現在能做些什麼。必須可檢查且詳盡：「所有修改過的檔案都已說明」較「產出變更清單」更能強制執行細節工作。交付物的格式在此定義；它是屬性，而非程序。
- 硬性限制 —— 不可違反的事項：唯讀來源、預算、術語、來源出處。使用者明確陳述的限制，就照其陳述 —— 絕不加入你自己的經濟預設值。
- 檢查點 —— 這是唯一仍應規定程序的地方：何時需暫停等待人類處理（破壞性或不可逆的操作、真正的範圍變更、只有他們擁有的資訊），以及哪些事項超出範圍。
- 自由條款 —— 賦予重組與提出異議的許可。遇到模糊不清時，做出常規的判斷並陳述假設；當答案可能避免後續問題時才提問，例如可能導致實質上不同工作的解讀方式，或一個難以撤銷的選擇。使用者歡迎這類提問。在無人值守的執行中，問題會變成一個採用安全預設值的裁決，工作繼續進行。
- 確認清單 —— 每份簡報都應包含：在報告完成前，根據本次工作階段的產出物稽核每項聲明，並明確說明哪些未經驗證；這幾乎能消除虛假的狀態報告。
只有在順序重要時（例如遷移、安全協議），或跳過某步驟即代表失敗時，才使用有序步驟清單；此時，一個供讀取者複製並逐項核對的清單會優於散文。
送出前檢查
是否有任何編號程序可以改寫為終點狀態的句子？是否每一行剩下的文字都是限制、檢查點、驗證規則或交付物規格？是否有任何句子會讓讀取者因為使用者未陳述的理由而停止、放慢或縮小範圍？讀取者是否必須參與過這個對話才能據以行動？
分支
- 傳送一次性訊息給你可模擬的讀取者（子代理派遣、另一個工作階段的提示、交接、給外部 AI 的訊息）→
references/briefs.md - 為無人值守的自動執行撰寫簡報，包含其檢查點備忘錄與裁決，以及在即將關閉的時間視窗下的順序安排 →
references/autonomous-runs.md - 持久性文件（技能、CLAUDE.md、參考文件），以及何時應將技能建置工作交給 Anthropic 的
skill-creator→references/skills-and-docs.md - 選擇讀取者的模型或投入程度，或為 Haiku 或 Fable 而非 Opus 撰寫 →
references/models.md