no-comments

コメントなし

Comment Sicko を起動します。承認された指摘に対応してください。

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

対象範囲

呼び出し元のファイルまたは差分を使用します。それ以外の場合は、デフォルトブランチ（git merge-base HEAD origin/HEAD、なければ main または master）との現在の差分を作業ツリーも含めて使用します。Git がない場合は、このセッションで変更されたファイルを使用します。

手順

1. Comment Sicko という名前の review サブエージェントを 1 つ起動します。~/.config/ox/models.md の review 行を使用し、モデルとエフォートをサブエージェントツールに渡します。その行が inherit、存在しない、またはファイルの # harness 行に別のハーネスが記載されている場合は、どちらも省略して、サブエージェントを現在のモデルで実行します。ファイルがない場合は、ユーザーに /setup-ox models の実行も提案します。サブエージェントへの指示は COMMENT-SICKO.md をそのまま貼り付けた後、対象範囲を示します。ルールを言い換えてはいけません。ハーネスにサブエージェントツールがない場合は、その旨を伝え、そのファイルを指示として自分でレビューします。
2. 報告と差分を確認します。アプリケーションコードの編集、対象範囲外の変更、例外で保護された削除、誤った MUST KILL の理由、残すべき意図的なコードを問題ありとする指摘は却下します。当プロジェクトの予期しない実装に関する指摘は、対応可能な形に整えます。それらのコメントは復元しません。残す判断は、変更できない対象についての証拠がある場合に限ります。見落とした対象範囲内の抑制指定（---@diagnostic disable、eslint-disable、@ts-ignore、@ts-expect-error）を監査します。正確性または安全性に関する抑制は、引き続き対応必須の MUST KILL とします。正確な例外と対象範囲内の根拠がある場合に限り、削除を復元します。根拠の薄い IMPORTANT や do not remove の削除・維持を承認する前に、自分でシンボルを追跡し、呼び出し元と、コメントが追加された時期や理由を git log -L または git blame で確認します。削除指摘が曖昧な場合は復元しません。維持が反証された場合、または依然として曖昧な場合は削除します。却下した報告は、失敗内容を明示して新しいサブエージェントに再実行させます。2 回目も却下し、未解決として報告し、no-comments を失敗とします。
3. 些細な承認済み指摘は、不要な経路の削除、パラメーターの削除、実際の API の使用によって直接修正します。修正に構造が必要な場合は、承認済み指摘と周辺コードについて一度だけ概要を作成します。データ構造と、それを変更する関数を示します。その概要を作成したら止めます。実装は手順 4 で行います。
4. 対象範囲内で、根本原因を解消する最小限の修正を実装します。名前が挙がった回避策はすべて削除します。根本原因が対象範囲外にある場合は、対象範囲内で最小限の修正を適用し、残りを未解決として報告します。「根本原因の修正」と「第一原理からの再設計」の原則（principles を指定して Skill ツールを呼び出す）は、方針の参考にのみ使います。対象範囲を広げたり、その範囲外の事例を修正したりする根拠にはなりません。症状だけを抑えるガードを追加してはいけません。
5. 制約コメントには do not remove、do not change wording、または talk to X before changing と書かれています。変更できない対象についての維持指示は残します。それ以外は、対象範囲内で最も低コストな型、実行時チェック、テスト、または CI lint で制約を表現し、コメントを削除します。対象範囲内に表現方法がない場合はコメントを削除し、制約を未解決として報告し、対象範囲外で必要な作業の概要を示します。
6. 削除数、復元したコメント、再実行、概要、修正、制約の表現方法、未強制の制約、その他の未解決作業を報告します。