no-comments について
no-comments は、対象ファイルや差分を調べ、不要と判断したコメントを削除して、採用した指摘に対処する pstack スキルです。報告を検証し、作業範囲を守る手順を重視します。
主な機能
- 01対象ファイルや差分のレビュー
- 02独立したコメントレビューの委任
- 03指摘の検証と却下報告の再実行
- 04採用した指摘コメントの削除
- 05修正内容と未解決事項の報告
活用シーン
- 01作業ツリーの差分にあるコメントの確認
- 02lint と TypeScript の抑制指定の監査
- 03制約を確認した上でのコメント削除
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/no-commentsを入力して読み込まれたか確認します。
同梱ファイルreferences/comment-sicko.md
詳細
コメントなし
Comment Sicko を起動します。承認された指摘に対応します。
Comment Sicko の新鮮な視点を尊重してください。
対象範囲
呼び出し元のファイルまたは差分を使用します。それらが指定されていない場合は、既定の main ブランチをベースに、作業ツリーを含む現在の差分を使用します。
手順
subagent_type: "comment-sicko"を指定してTaskを起動します。対象範囲を渡します。poteto-mode スキルの Subagents セクションに従い、各サブエージェントの推論レベルと速度（fast または standard）を選択します。そのルールを繰り返さないでください。使用しているハーネスに comment-sicko がサブエージェントとして登録されていない場合（pstack プラグインを使う Cursor 以外のすべてのハーネス）、代わりに一般サブエージェントを起動します。Claude Code ではAgent（subagent_type: general-purpose）、OpenCode ではtask（subagent_type: general）、Codex ではspawn_agentを使用します。プロンプトにはreferences/comment-sicko.mdの内容をそのまま使い、その後に対象範囲を指定します。Pi の拡張機能なしの場合のように、使用しているハーネスにサブエージェントツールがない場合は、新たに対象範囲を確認する際に、そのプロンプトを自分で実行します。- 報告と差分を確認します。アプリケーションコードの編集、対象範囲外への逸脱、例外によって保護された削除、誤った
MUST KILLの理由、意図的に残されているコードを問題ありとするフラグは却下します。こちらのコードに関する予期しない点を示すフラグは、引き続き対処可能な状態に整えます。それらのコメントは復元しません。残すコメントは、変更できないものに関する証拠がある場合に限ります。スコープ内の lint 抑制や TypeScript 抑制に見落としがないか監査します。正確性や安全性に関する抑制は、引き続き対処対象のMUST KILLとします。正確な例外と対象範囲内の根拠がある場合に限り、削除を復元します。根拠の薄いIMPORTANTやdo not removeの削除指摘または残す指摘を承認する前に、対象のシンボルに対して/howまたは/whyを実行します。削除指摘が曖昧な場合は復元しません。残す指摘に反証がある場合、または依然として曖昧な場合は、外部ルールに関するREVIEWの残す指摘を除き、削除します。外部ルールに関するREVIEWの残す指摘は、誰かがそのルールを確認するまで維持します。未解決として報告します。却下した報告は、失敗した理由を明示して1回だけ差し戻し、再実行します。再実行も却下した場合は、却下した指摘だけを元に戻し、未解決として報告したうえで、承認済みの指摘に進みます。 - 承認された軽微な指摘は、不要なパスの削除、パラメーターの削除、または実際の API の使用により直接修正します。修正に設計が必要な場合は、承認済みの項目と周辺コードを対象に
/architectを1回実行します。スケッチの段階で止めます。設計は Architect に任せます。実装は手順4で行います。 - 対象範囲内で、根本原因に対する最小限の修正を実装します。指摘された回避策はすべて削除します。根本原因が対象範囲外にある場合は、対象範囲内で最小限の修正を行い、残りは未解決として報告します。principle-fix-root-causes と principle-redesign-from-first-principles の各スキルは、意図を示すためだけに使用します。どちらも対象範囲を広げたり、範囲外の事例を修正したりする根拠にはなりません。症状を抑えるためのガードを追加してはいけません。
- 制約を示すコメントには
do not remove、do not change wording、またはtalk to X before changingと記されています。変更できないものに関する残す指摘は維持します。対象範囲内で最も低コストな型、ランタイム、テスト、または CI lint による対応を提案します。対話型の場合は承認を待ちます。無人実行および eval では、呼び出し元による事前承認が必要です。承認された場合は、制約を仕組みとして実装してから削除します。そうでない場合は削除し、制約を未解決として報告して、対象範囲外の作業案を示します。 - 削除件数、復元したコメント、
REVIEWの残す指摘、再実行の回数、Architect のスケッチ、修正、制約の実装提案、実装した制約、未強制の制約、その他の未解決作業を報告します。
コメント
Markdown 対応