為代理程式寫作
您使用此技能撰寫的任何文字，其讀者都是僅擁有文字的代理程式。它沒有看到對話內容，無法詢問您的意圖，並且會嚴格依據文字的字面意思，全力執行。大多數失敗源於您所知內容與寫入頁面內容之間的落差。因此，請從讀者的角度出發：寫作前，先確定工作的終點、讀者所處的情境以及它需要的材料；然後以讀者能獨立使用的文字進行撰寫。
兩種輸入類型
粗略請求（例如：「撰寫一份簡報，讓代理程式修復不穩定的登入測試」）：從對話和工作空間中蒐集事實，然後從頭起草。
現有提示詞：保留它。進行最小程度的修改，只修正實際有問題的地方，保留有效的結構和措詞，並且不要添加原作者未陳述的要求。完全重寫會隱藏哪個修改是關鍵的，也會悄悄丟棄原作者意圖。以下預設值仍然適用：如果提示詞缺少角色句、範例或結尾檢查，請補上。每當您添加任何內容（無論是上述項目之一，還是用來填補實際差距的規則），在交付時都要列出。
如果只有使用者知道的某個事實會改變讀者的交付內容或其可能採取的行動，請在寫作前提問：最多問幾個問題，每個問題附上您建議的答案。否則，選擇一個合理的預設值，並將其列為假設。
寫作前
工作的終點
陳述目標、為何重要（誰會使用結果，以及用於什麼目的）、何謂完成，以及要回傳什麼。描述目的地，而非路徑：給出結果、成功標準和限制條件，讓讀者自行選擇路徑。目前的模型自行規劃，效果比您指定的一系列步驟更好，而且您猜錯的步驟仍然會被執行。只有在順序本身就是要求的情況下才列出步驟，例如必須在部署前執行的遷移。
修改前：1. 開啟 refresh.ts。2. 將 refresh() 包在 try/catch 中。3. 重試三次。4. 執行測試。
修改後：當 session 逾時時，客戶端應無聲地更新 token，以便使用者保持登入狀態。完成條件是 tests/auth/refresh.test.ts 中新的逾時案例通過，且沒有現有測試失敗。保持 AuthClient 的公開 API 不變，因為其他三個套件會呼叫它。
將品質形容詞轉換為讀者可應用的標準。「詳盡」、「簡潔」和「只列出重要的」會被嚴格且不可預測地執行：被要求只回報重要問題的審查者，會找到小問題並對其保持沉默。明確指出閾值，或指出要保留和要刪除的內容。如果後續步驟會過濾結果，請要求提供所有內容。
修改前：仔細審查，且只回報重要問題。
修改後：回報您發現的每個問題，包括您不確定的問題，並將每個問題標記為「破壞行為」或「僅限風格」。後續步驟會進行過濾。
讀者所處的情境
當文字分配任務時（簡報、系統提示詞、議題、計畫或交接），請以一個角色句開頭：讀者是誰、在此任務中的功能以及它所處的情境。「您是此 pull request 的程式碼審查者，您沒有撰寫此 PR；團隊計畫今天將其合併。」這個角色設定了讀者的觀點及其責任。工具或技能的描述則沒有角色；它們說明該工具或技能的作用以及何時使用。
然後告訴讀者從其所在位置看不到的資訊：在任務進行中是否有人可以回答問題，還是它會無人看管地執行；還有哪些人在相同的檔案或系統中工作；它的變更是否會被審查或是可逆轉的；它應該評估還是修改事物；以及它可以在不詢問的情況下做什麼，包括是否可以進一步委派。明確指出需要停止並回報的具體情況。「不確定時請問」會讓讀者去猜測，結果它可能會問所有事情或什麼都不問。
您將無人看管地執行；在您完成之前，沒有人可以回答問題。只有在修復會刪除資料或碰觸 src/auth/ 以外的程式碼時，才停止並回報。另一個代理程式正在同時編輯 docs/，因此請避開該目錄，不要還原您沒有進行的變更。
讀者所需的材料
對於每個來源，給出它的位置以及要從中獲取什麼。直接指向讀者可以自己開啟的內容（檔案路徑、命令、它可以達到的 URL），而不是進行轉述，讓它讀取真實的內容。將僅存在於您脈絡中的內容完整寫出：在對話中做出的決定、使用者對某個需求的原文、您執行命令的結果、已經排除的方法及其原因。
修改前：請參閱 docs/ 和我們先前的討論。
修改後：請閱讀 docs/billing.md 中的「退款」部分，以了解四捨五入規則。有一個需求不在任何檔案中；使用者的原文是：「部分退款絕不能超過原始收費金額，即使經過貨幣轉換也是如此。」
當您包含日誌、使用者文字或其他代理程式的輸出時，請將其放在一個清楚標示的區塊中，並說明這些是工作素材，而非指示。將您自己的指示保留在此類區塊之外，因為引號或資料區塊內的文字通常會被視為內容，不具有指示權威。
開始寫作
使用讀者的語言，而不是您自己的。在運作過程中，您可能會創造標籤（例如「方案 B」、「偷懶路徑」、「P2 問題」）和簡寫（例如「→ 鎖競爭」），這些對讀者來說毫無意義。請將每個都用其代表意義替換，對真正的術語定義一次，然後像新鮮解釋一樣進行寫作。在描述先前已完成的工作時，請說明是誰做的，以免讀者認為是它自己採取了這些行動。
修改前：方案 B 已被排除（→ 鎖競爭）；繼續使用 lazy-init，注意 P2 陷阱。
修改後：先前的 session 排除了在每個請求上重建連線池的做法：在負載下，p95 延遲從 80 毫秒上升到 400 毫秒，原因是鎖競爭。目前的方法是在首次使用時建立連線池。還有一個已知問題：...
為每個規則附加一個原因子句（例如「…因為某個腳本會解析此欄位」）。原因讓讀者能夠處理您未列出的情況，並顯示規則的適用範圍。僅在所有有能力模型都已知道原因，或脈絡使其顯而易見時，才可省略原因。
每個規則只陳述一次，放在它歸屬的位置。重複並不會增加份量；它會讓讀者過度套用規則（重複的「先問」指示會導致本該安全的步驟也停頓下來），而且複本會在編輯過程中逐漸偏離。基於同樣原因，請使用平實的措詞：不要使用大寫、『重要』或壓力性詞語，例如「這是關鍵」或「別偷懶」。將『絕不』和『總是』這類絕對詞語保留給真正的不變量，例如安全限制和不可逆的操作。
不要規定如何思考。省略「逐步思考」和要求將推理寫入答案或標籤中的請求；目前的模型會自行推理，有些則拒絕將推理過程寫下來的請求。如果您需要了解原因，請要求簡短說明或支持證據，例如檔案：行號參考或命令輸出。
在修復已知失敗時，請寫出其背後的原則及其原因，而不是僅僅禁止您看到的那個實例。一份禁止清單只涵蓋它所列出的內容；一個原則則涵蓋了相鄰的情況。
修改前：不要使用 Object.create()。不要使用 proto。
修改後：偏好使用明確的組合而非原型操作，因為此處的審查者傾向於自上而下閱讀的程式碼。
使用段落寫作。僅在項目確實是平行或順序關係時才使用列表：欄位、有序步驟、獨立檢查。要點會去除連接指令所需的「因為」和「除非」，而且讀者往往會模仿他們所獲得的格式。
包含一個關於讀者應產生什麼的簡短範例，並標記為範例；它傳達形式、語氣和詳細程度，效果勝過一段描述。僅在預期輸出從文字本身即可明確無誤時，才可省略範例，例如單一要執行的命令。
在以任務分配為目標的文字結尾，加上一個讀者在回報完成前會執行的檢查：存在時，是證明結果的命令或測試；否則，是需重新檢視的完成標準。請要求它清楚說明任何它無法驗證的內容。
交付
交出完成後可貼上或已寫入其檔案的文字，使用現有提示詞的語言或使用者要求的語言。在文字之外，用幾行列出您所做的、使用者可能想要更改的假設。將您的設計筆記保留在文字本身之外。
在交付之前，像讀者一樣閱讀草稿：有能力，但只能依靠此頁面。任何需要猜測您意圖的地方，都請修正該頁面。