correct | 用結構性約束防止重複錯誤
本頁以 pstack-claude 0.9.126 為基準。我們練習處理「新增內容類型時，只更新導覽清單，漏掉驗證清單」的重複錯誤。先找兩次真實紀錄，再提出讓兩份清單不必手動同步的方案。
定位與適用情境
correct 的目標是改變專案結構，讓代理不能再用看似合理的方式犯同樣錯誤。原文假設代理只看到開過的檔案，會複製附近範例，因此修正不能只靠「下次記得」。
原文先讀近期提交、還原、審查留言、代理指令與說明暫時解法的註解。同類錯誤至少出現兩次，才算一個錯誤類別。本例是教學情境，不代表 TechSpecs 已發生過這類事件。
準備
備妥一份限定範圍的證據包。
- 兩次漏更新驗證清單的實際提交或審查紀錄，以及可重現的差異。
- 導覽與驗證清單的檔案位置、讀取端及使用方式。
- 專案目前使用的型別、靜態檢查（lint）、測試與持續整合（CI）指令。
- 可讀取與可修改的檔案範圍。指令文件與全域設定預設不在修改範圍。
找不到第二次紀錄時，回報證據不足。不要把一次錯誤拆成兩個症狀，假裝達到分類門檻。
操作步驟
- 要求代理將兩次紀錄歸到同一類，列出各自的來源位置與失敗行為。先確認這是兩份資料要手動同步的問題，而非名稱相似但原因不同的事件。
- 優先檢查架構能否消除錯誤。本例先評估由單一資料來源產生導覽與驗證規則，避免要求作者永遠記得同步。
- 若架構不能消除問題，再評估型別約束、會指出正確用法的 lint 或 CI 檢查，以及行為測試。每次降低約束層級，都要寫出更高層級不可行的原因。
- 核准修改範圍後，在隔離的測試資料或工作區重播一次過去錯誤。先觀察檢查因目標原因失敗，再套用正確修改，使用同一指令確認成功。不要在正式工作區破壞資料。
- 檢查是否仍有只能依賴判斷的規則。原文最後要求在代理指令檔維護規則與強制機制的對照表，但本例先交付建議內容。只有取得該檔案的明確修改授權，才寫回。
可直接使用的提示詞
用 pstack:correct 分析重複漏更新內容驗證清單的問題。
先只讀取我提供的兩次提交或審查證據、相關清單與呼叫端。
若無法證明同類錯誤至少發生兩次，回報證據不足並停止分類。
依架構、型別、lint 或 CI 檢查、行為測試的順序提出約束。
優先評估由單一資料來源產生導覽與驗證清單。
不要先加提醒文字，也不要用新包裝函式掩蓋原本兩份資料的同步責任。
每個類別列證據、採用層級，以及更高層級為何不可行。
提出用真實舊錯誤驗證新檢查的失敗與成功步驟。
說明本地與 CI 如何執行同一個檢查指令。
先交付提案與預計差異，等我核准才修改程式或測試。
不要修改 AGENTS.md、CLAUDE.md、技能、權限或全域設定。
規則與強制機制的對照表只列在回覆中，另行取得寫入授權。
不要刪檔、提交、推送或重寫歷史。預期結果與驗收
若證據支持單一資料來源方案，預期結果是新增內容類型時只改一處，導覽與驗證都取得新項目。若仍需要兩次人工編輯，就沒有消除這次情境的同步責任。
用下列條件檢查提案與後續實作。
- 每個錯誤類別至少連到兩次真實事件。
- 所選層級附上理由，不把「加一條規則」當預設解法。
- 新檢查會拒絕真實舊錯誤，且失敗原因不是缺少套件或指令拼錯。
- 修正後相同檢查成功，行為測試不因無關的內部重構而失敗。
- 本地與 CI 使用同一檢查指令。尚未執行的部分明確列為待驗證。
限制與權限
原文包含每類錯誤各自提交的流程，但技能本身不提供 Git 提交授權。本例不提交，也不擅自刪除舊程式。涉及刪檔或調整專案指令時，先取得相應權限。
原文要求例外寫在違規行，附理由、到期日與人類核准。沒有核准就不能加例外繞過檢查。當錯誤已不可能發生時，原文建議移除多餘規則，仍須遵守指令檔修改權限。
「讓錯誤不可能發生」是設計目標，不是無缺陷保證。單一檢查只能證明涵蓋的條件，不能替整個專案背書。
延伸閱讀與來源
- reflect 教學將對話教訓整理為待核准的技能修訂。
- 全部技能教學
- 版本與技能總覽
- 上游技能原文