no-comments | 查證註解與可執行約束
本頁以 pstack-claude 0.9.126 為基準。no-comments 的原文採積極刪註解策略,並由 comment-sicko 審查者找出值得修正的程式限制。本頁不把這項策略當成凌駕專案文件保留規則的授權。
定位與適用情境
例如某個重試參數旁有「IMPORTANT,不可更改這個值」,但沒有測試說明原因。這個技能要查證它描述的是外部協定限制,還是自家實作的暫時繞路,再評估是否能用型別、執行期檢查、測試或持續整合 (CI) 規則表達。
輸入是指定檔案或差異,以及註解涉及符號的實作與讀寫位置。輸出包括註解判斷、保留理由、待查項目、接受的根因修復與約束編碼提案,不是「所有註解歸零」。
準備
- 明確指定範圍。原文未指定時以基底分支,預設
main,連同工作目錄差異為範圍。 - 先標記必須保留的內容。包括專案要求的準確繁體中文功能註解、有效文件、TODO、license 與被註解的舊程式。
- 備妥相關函式、呼叫端與變數讀寫證據。
IMPORTANT或「不可移除」不會單靠措辭自動成立或失效。 - 確認專用代理與規則來源可取得。本次快取沒有
comment-sicko.md,不能據此重建完整例外清單。
操作步驟
- 派出範圍明確的註解審查。 Claude Code 原文使用
pstack:comment-sicko。先把專案保留規則列成硬限制。審查者初始任務不是修改應用程式邏輯。 - 核對報告與差異。 拒絕越界、擅改應用程式或刪除受保護內容的結果。對薄弱的保留或刪除理由,以 how 或 why 追查符號。外部依賴、平台、廠商或協定規則若已指出查證位置但尚未證實,保留為
HOLD。 - 處理接受的根因問題。 簡單且已授權的問題用最小修復。若需要新的形狀,先讓 architect 停在草圖,再依核准範圍實作。不能借「修根因」擴大到範圍外的所有相似位置。
- 提出約束編碼。 對可確認的限制,提出最便宜的型別、執行期、測試或 CI 檢查,互動時先等核准。即使編碼後,專案要求的準確功能註解與其他保護內容仍保留。
- 交付審核紀錄。 列出刪除數、恢復項目、
HOLD、重跑次數、草圖、修復、編碼提案與未強制約束。原文對被拒報告只重跑一次,第二次仍被拒時撤回其被拒變更並回報,不無限重試。
可直接使用的提示詞
Claude Code 可用 /pstack:no-comments,Codex 插件可選 $pstack:no-comments。以下範例先要求唯讀審查,再決定是否修改。
用 pstack:no-comments 檢查目前重試參數差異,先唯讀列出判斷,不刪註解或修程式。
先讀實作、呼叫端與參數讀寫,查證 IMPORTANT 所宣稱的限制。
保留專案要求的準確繁體中文功能註解、有效文件、TODO、license 與被註解的舊程式。
未知用途先保留並回報,不按名稱或語氣推測。
外部協定或依賴規則尚待查證時標 HOLD,附應查的來源。
可確認的自家約束請提出最小型別、測試或 CI 編碼方案,等我核准才實作。
若缺 comment-sicko 定義或派工工具,標明缺口,不聲稱專用審查已完成。
預期結果與驗收
- 報告能區分準確功能說明、外部限制、自家繞路與未知用途,並附實際證據。
- 外部規則的
HOLD不被當作含糊註解直接刪掉。要反駁規則,應有文件或來源證明。 - 已接受修復留在範圍內。被拒或越界的修改沒有混入最終差異。
- 編碼提案有待核准狀態。沒有核准或沒有可執行檢查時,不宣稱約束已被強制。
- 專案保護的註解與文件完整保留,不能用刪除數量判定成功。
限制與權限
原文對部分含糊保留項及未編碼約束採刪除預設。本專案要求保留缺乏查證依據的內容,因此不能照搬該刪除預設。正確做法是保留、說明證據缺口並等待確認,尤其不可刪除受保護內容。
Codex 沒有 comment-sicko 代理類型。來源要求以 spawn_agent 讀取隨附 poteto-mode/references/agents/comment-sicko.md。本次提供的快取未含該定義,實際使用前要確認安裝包與工具,不把一般閱讀冒充專用審查。
原文會在接受發現後修改程式,不能把技能名稱理解成只讀工具。任何刪註解、應用程式修復與 CI 變更都要在使用者授權內。本頁的保留規則也適用於自動或無人值守執行。