no-comments

コメントなし

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

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

対象範囲

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

手順

1. subagent_type: "Comment Sicko" を指定して Task を起動します。対象範囲を渡します。そのルールを言い直してはいけません。
2. レポートと diff を確認します。アプリケーションコードへの編集、対象範囲からの逸脱、例外で保護された削除、誤った 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. 制約コメントには do not remove、do not change wording、または talk to X before changing と記載されています。変更できないものに関する残置判断はそのままにします。対象範囲内で最も低コストな型、実行時、テスト、または CI lint を提案します。対話的な承認を待ちます。無人実行および評価では、呼び出し元による事前承認が必要です。承認された場合は、制約をコード化してから削除します。承認されない場合は削除し、制約を未対応として報告し、範囲外の作業を簡潔に示します。
6. 削除数、復元したコメント、再実行、architect のスケッチ、修正、コード化の提案、コード化した制約、未適用の制約、その他の未対応事項を報告します。