跳到主內容

Theme / 0.9.130

Pstack

用可驗證的工作流程協作,從單一入口學會工程技能

Skills

no-comments | 查證註解與可執行約束

由專用審查者檢查指定範圍的註解,查證例外與外部規則,對接受的問題提出根因修復及約束編碼。

no-comments | 查證註解與可執行約束

本頁以 pstack-claude 0.9.126 為基準。no-comments 的原文採積極刪註解策略,並由 comment-sicko 審查者找出值得修正的程式限制。本頁不把這項策略當成凌駕專案文件保留規則的授權。

定位與適用情境

例如某個重試參數旁有「IMPORTANT,不可更改這個值」,但沒有測試說明原因。這個技能要查證它描述的是外部協定限制,還是自家實作的暫時繞路,再評估是否能用型別、執行期檢查、測試或持續整合 (CI) 規則表達。

輸入是指定檔案或差異,以及註解涉及符號的實作與讀寫位置。輸出包括註解判斷、保留理由、待查項目、接受的根因修復與約束編碼提案,不是「所有註解歸零」。

準備

  • 明確指定範圍。原文未指定時以基底分支,預設 main,連同工作目錄差異為範圍。
  • 先標記必須保留的內容。包括專案要求的準確繁體中文功能註解、有效文件、TODO、license 與被註解的舊程式。
  • 備妥相關函式、呼叫端與變數讀寫證據。IMPORTANT 或「不可移除」不會單靠措辭自動成立或失效。
  • 確認專用代理與規則來源可取得。本次快取沒有 comment-sicko.md,不能據此重建完整例外清單。

操作步驟

  1. 派出範圍明確的註解審查。 Claude Code 原文使用 pstack:comment-sicko。先把專案保留規則列成硬限制。審查者初始任務不是修改應用程式邏輯。
  2. 核對報告與差異。 拒絕越界、擅改應用程式或刪除受保護內容的結果。對薄弱的保留或刪除理由,以 how 或 why 追查符號。外部依賴、平台、廠商或協定規則若已指出查證位置但尚未證實,保留為 HOLD。
  3. 處理接受的根因問題。 簡單且已授權的問題用最小修復。若需要新的形狀,先讓 architect 停在草圖,再依核准範圍實作。不能借「修根因」擴大到範圍外的所有相似位置。
  4. 提出約束編碼。 對可確認的限制,提出最便宜的型別、執行期、測試或 CI 檢查,互動時先等核准。即使編碼後,專案要求的準確功能註解與其他保護內容仍保留。
  5. 交付審核紀錄。 列出刪除數、恢復項目、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 變更都要在使用者授權內。本頁的保留規則也適用於自動或無人值守執行。

延伸閱讀與來源