no-comments

コメントなし

Codex では、このスキルを実行する前に、スキルごとの注記も含めてプラットフォームのマッピングを読んでください。

GitHub Copilot では、このスキルを実行する前に、スキルごとの注記も含めてプラットフォームのマッピングを読んでください。

Muse では、このスキルを実行する前に、スキルごとの注記も含めてプラットフォームのマッピングを読んでください。

comment-sicko を起動してください。受け入れた指摘に対応してください。

comment-sicko の新鮮な視点を優先してください。

対象範囲

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

手順

1. subagent_type: "pstack:comment-sicko" を指定して Agent を起動してください。対象範囲を渡してください。各サブエージェントの推論レベルは、poteto-mode スキルの Subagents セクションに従って選んでください。そのルールを言い直さないでください。
2. レポートと差分を確認してください。アプリケーションコードの編集、対象範囲からの逸脱、例外保護された削除、誤った MUST KILL の理由、意図的に残されたコードを問題ありと扱うフラグは却下してください。自分たちのコードに対する予想外の変更を指摘するフラグは、対応可能な状態に保ってください。そうしたコメントは復元しないでください。keep を残せるのは、変更できないものについてのコメントであることを証明できる場合に限ります。対象範囲内で見落とされた lint 抑制と TypeScript 抑制を監査してください。正確性または安全性に関する抑制は、引き続き対応必須の MUST KILL としてください。削除を復元するのは、正確な例外と対象範囲に限定した根拠がある場合に限ります。根拠の薄い IMPORTANT または do not remove の削除指摘や keep を受け入れる前に、そのシンボルに対して /how または /why を実行してください。削除の可否が曖昧なら、復元しないでください。keep の根拠が覆された場合、または依然として曖昧な場合は、削除してください。却下したレポートが1件なら、却下理由を明示してやり直してください。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 とある場合は、そのまま残してください。変更できないものについての keep は残してください。最も安価な、対象範囲内の型、ランタイム、テスト、または CI lint による対応を提案してください。対話形式での承認を待ってください。無人実行および評価では、呼び出し元の事前承認が必要です。承認された場合は、制約をコード化してから削除してください。それ以外の場合は削除し、制約を未解決として報告し、対象範囲外の作業を概要として示してください。
6. 削除数、復元したコメント、再実行、Architect のスケッチ、修正、コード化の提案、コード化した制約、未適用の制約、その他の未解決事項を報告してください。