散文編輯 是做什麼的？
假設內容為 事實正確。專注於文字與結構，而非事實本身。相鄰的 NOTES.md 檔案包含實際操作範例。
測試標準
每句話都應告訴讀者 該做什麼、該期待什麼 或 做錯會發生什麼事；刪除不具備上述任何一項功能的句子。精煉並非簡短：絕不為了達到特定長度而刪減實質內容，而是刪除圍繞在內容周圍的支架。
刪除
- 開場廢話。將核心內容放在第一句。
- 重複論述。在最佳位置只說一次。
- 多餘的過渡詞（例如「值得注意的是」、「如上所述」、「為了」）。
- 不影響行為的編者評論（例如「雖然單調卻很重要」）。
- 模糊的量化（例如「驚人的比例」）。請給出有效運作的真正原因，否則就刪除該論述。
- 避免承諾的模糊用語。對於真正的不確定性，應明確說明，並附上決策標準。
- 用引用塊強調。保留那些會改變讀者行為的警告。
刪除標示為機器生成的文字
模型會挑選最適合廣泛讀者的寫法；而人類作者則為特定讀者與主題挑選。首先檢查結構，因為用詞習慣會隨模型而變。一句話只有在能給予此讀者他們原本沒有的東西時，才應保留。
- 鋪陳而非陳述。當沒人說過「X」時，卻寫「不是 X 而是 Y」；一個重複論點的一行結語；在觀點前先鋪陳一段；聽起來深奧但實則空洞的格言。直接陳述事實。
- 格式化的節奏。到處使用三點列舉與破折號，重複的句子開頭，堆砌的修飾詞。只有當確實有三件事情時才使用三項。
- 誇大其詞。將普通事實稱為「關鍵」或「穩健」，使用推銷用語，提及未具名的權威，使用「-ing」形式暗示含義。說明它做了什麼，否則就刪除。
- 格式化的排版。每個項目都加粗，每個想法都加標題，但強調或結構卻毫無意義。
- 草稿殘留物。聊天框、知識限制免責聲明、重複作為第一句的標題、關於文件本身而非主題的文字。
- 錯誤的讀者。重新解釋讀者已經知道的事情，導致結論最後才出現。
保留作者真正想表達的意思，並且不要添加任何東西來取代你刪除的內容。真正的對比、真正的三個項目清單、或引用的來源可以保留；只有當標記完全沒有增加任何價值時，才需要刪除。
受保護的：為什麼 絕非廢話
保留解釋 為什麼（為什麼是這個順序、這個工具、這個檢查優先、這個步驟不可跳過）的句子，即使它沒有給出指令：理由能讓讀者處理文件未預料到的情況，並在程序不再適用時察覺。在不明確的地方都應給出理由，特別是安全性與合規規則，因為意圖能讓人在沒有明確規範時套用規則。當一個句子同時包含修辭與理由時，應改寫以保留理由。測試標準是 「沒有這句話，讀者是否能做得更好。」
刪除不當的結構
只有在工作需要時才添加層級、表格、矩陣、巢狀標題或分支，而不是因為它們看起來嚴謹。問自己：工作流程在此處真的有分支嗎（如果每個讀者都走相同路徑，那這就是一個清單）？這個步驟是必要的，還是只為了看起來周全？如果程序只有四個步驟，就寫四個步驟：首次閱讀就能遵循的四步驟程序，比一個正確但容易被跳過的九步驟程序更好。常見陷阱、順序陷阱與「為什麼」則應保留。
模型載入的指令
規則表、技能、角色檔案與提示詞每次載入都要付出 Token 成本，且讀者是模型，它需要的是規則，而非其來龍去脈。根據載入時機定價（D28）：
- 每次對話（規則表、技能與角色描述）：僅規則。描述說明技能涵蓋範圍及何時載入，字數控制在 300 字以內；
tools/check.py會強制執行預算。 - 使用時載入（技能或角色主體）：規則加上一條理由。僅在規則若不含理由會顯得像是可選時，才加入一個具體的失敗案例，且不得包含日期、計數或專案名稱。
- 按需載入（
NOTES.md、EVIDENCE*.md）：事件、數字、日期與來源。主體文件指向此處。
使用祈使句。不要重述另一個已載入檔案中的規則；直接以名稱指向它。docs/REQUIREMENTS.tsv 中的固定需求會隨著改寫而移動，絕不會被無聲地忽略。
程序結構
目的 → 使用時機 → 開始之前 → 步驟 → 驗證 → 若無效則 → 升級處理
- 絕不可遺漏「驗證」：這是最常被跳過卻最有價值的部分。
- 每個步驟單一動作。準確命名 UI 元素。提供完整路徑。
- 在不可逆的步驟之前標示清楚，而非之後。
- 為有能力但不熟悉此環境的陌生人撰寫：熟悉領域，但從未見過此環境。
- 標題應使用他人會搜尋的名稱。不要包含日期、版本或「v2」。
語氣
- 使用平實語言、短句。
- 不要用委婉用語淡化嚴重後果（如沒收、終止、資料遺失、個人責任）：應直接明白地說明。
- 連結供應商文件，而非直接複製；僅記錄您工作中特有的部分：覆寫的內容很快就會過時。