no-comments

コメントなし

Comment Sicko を起動します。受け入れた指摘に対応します。

Comment Sicko の新鮮な視点を尊重してください。

対象範囲

呼び出し元のファイルまたは差分を使用します。それ以外の場合は、デフォルトの main ブランチをベースとした現在の差分を、作業ツリーも含めて使用します。

手順

1. subagent_type: "comment-sicko" を指定して Task を起動します。対象範囲を渡します。各サブエージェントの推論レベルと高速または標準の実行速度は、poteto-mode スキルの「Subagents」セクションに従って選びます。そのルールを繰り返して伝えてはいけません。お使いのハーネスに comment-sicko がサブエージェントとして登録されていない場合（pstack プラグインを備えた Cursor 以外のすべてのハーネス）は、代わりに汎用サブエージェントを起動します。Claude Code では Agent（subagent_type: general-purpose）、OpenCode では task（subagent_type: general）、Codex では spawn_agent を使います。そのプロンプトには references/comment-sicko.md の内容をそのまま指定し、その後に対象範囲を渡します。Pi の拡張機能なしの場合のように、ハーネスにサブエージェント用ツールがない場合は、そのプロンプトを使って対象範囲を自分で改めて確認します。
2. 報告と差分を確認します。アプリケーションコードの編集、対象範囲外への逸脱、例外で保護された削除、誤った MUST KILL の理由、意図的に残されたコードを問題視する指摘は却下します。こちらのコードにある想定外の点への指摘は、対応可能な内容に整えます。そうしたコメントは復元しません。残す判断は、変更できない対象についての内容であることを証明できる場合に限ります。対象範囲内で見落とされた lint と TypeScript の抑制も監査します。正確性または安全性に関わる抑制は、引き続き対応必須の MUST KILL とします。削除を復元するのは、厳密な例外と対象範囲内の根拠がある場合に限ります。内容の薄い IMPORTANT または do not remove の削除要求や残す判断を受け入れる前に、そのシンボルに対して /how または /why を実行します。削除要求が曖昧なら、復元しません。残す判断が反証された場合、または依然として曖昧な場合は、削除します。却下した報告を、失敗した理由を明示して元に戻し、再実行します。2回目も却下する場合は、未解決として報告し、/no-comments を失敗とします。
3. 受け入れた簡単な指摘は、不要な経路の削除、パラメーターの削除、または実際の API の使用によって直接修正します。修正に形状の設計が必要な場合は、受け入れた指摘と周辺コードを対象に /architect を1回実行します。スケッチの段階で止めます。形状設計は Architect が行います。実装は手順4で行います。
4. 対象範囲内で根本原因に対する最小限の修正を実装します。名前が挙がった回避策はすべて削除します。根本原因が対象範囲外にある場合は、対象範囲内で最小限の修正を行い、残りを未解決として報告します。principle-fix-root-causes と principle-redesign-from-first-principles の各スキルは、意図を導くためだけに使用します。どちらも対象範囲を広げたり、その範囲外にある箇所を修正したりする許可にはなりません。症状を抑えるだけのガードは追加しないでください。
5. 制約に関するコメントに do not remove、do not change wording、または talk to X before changing とある場合は、変更できない対象についての残す判断を維持します。対象範囲内で最も低コストの型、ランタイム、テスト、または CI lint を提案します。対話形式では承認を待ちます。無人実行と評価実行では、呼び出し元から事前承認を得ている必要があります。承認された場合は、制約をコード化してからコメントを削除します。そうでない場合はコメントを削除し、制約を未解決として報告して、対象範囲外で必要な作業の概要を示します。
6. 削除数、復元したコメント、再実行回数、Architect のスケッチ、修正内容、制約のコード化提案、実施したコード化、未適用の制約、その他の未解決事項を報告します。