no-comments

コメントなし

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

Comment Sicko の新鮮な視点を尊重します。

対象範囲

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

手順

1. subagent_type: "comment-sicko" を指定して Task を起動します。対象範囲を渡します。各サブエージェントの推論レベルと速度（高速または標準）は、poteto-mode スキルの「Subagents」セクションに従って選びます。そのルールを言い直してはいけません。
2. 報告と差分を確認します。アプリケーションコードの編集、対象範囲外への逸脱、例外で保護された削除、誤った MUST KILL の理由、意図的に残されたコードを問題ありとするフラグは却下します。こちらのコードに関する予想外の点への指摘は、対応可能な状態に保ちます。そうしたコメントは復元しません。保持するコメントは、変更できない事項に関するものだと証明できる場合に限り残します。見落とされた対象範囲内の lint 抑制と TypeScript 抑制を監査します。正確性または安全性に関する抑制は、引き続き対応が必要な MUST KILL とします。削除されたコメントを復元するのは、正確な例外と対象範囲内の根拠がある場合に限ります。根拠の薄い IMPORTANT または do not remove の削除指摘や保持指摘を受け入れる前に、そのシンボルに対して /how または /why を実行します。削除指摘が曖昧な場合は復元しません。保持指摘が反証された場合、または依然として曖昧な場合は削除します。却下した報告を、失敗内容を明示して一度だけ差し戻し、再実行します。2回目も却下する場合は、未解決として報告し、/no-comments を失敗とします。
3. 受け入れた単純な指摘は、不要なパスの削除、パラメーターの除去、または実際の API の使用によって直接修正します。修正に設計が必要な場合は、受け入れた指摘一式と周辺コードを対象に /architect を一度だけ実行します。スケッチの提示までで止めます。設計は Architect が行います。実装は手順4で行います。
4. 対象範囲内で、根本原因を最小限の修正で解消します。指摘された回避策はすべて削除します。根本原因が対象範囲外にある場合は、対象範囲内で最小限の修正を行い、残りを未解決として報告します。principle-fix-root-causes と principle-redesign-from-first-principles のスキルは、意図の指針としてのみ使用します。いずれも対象範囲を広げたり、その範囲外の箇所を修正したりする許可にはなりません。症状を抑えるためのガードを追加してはいけません。
5. 制約を示すコメントに「削除しない」「文言を変更しない」「変更前に X に相談する」とある場合は、変更できない事項に関する保持コメントを残します。対象範囲内で最も低コストな型、ランタイム、テスト、または CI lint による強制手段を提示します。対話型の場合は承認を待ちます。無人実行および評価では、呼び出し元の事前承認が必要です。承認された場合は、強制手段を実装してからコメントを削除します。それ以外の場合はコメントを削除し、制約を未解決として報告し、対象範囲外で必要な作業をスケッチします。
6. 削除数、復元したコメント、再実行、Architect のスケッチ、修正、強制手段の提案、実装した強制手段、未強制の制約、その他の未解決作業を報告します。