no-comments

コメントなし

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

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

対象範囲

呼び出し元のファイルまたは差分を使用します。それらがない場合は、デフォルトのベースブランチ main に対する現在の差分（作業ツリーを含む）を使用します。

手順

1. persona contract を参照して論理ペルソナ comment-sicko を解決し、対象範囲を渡して起動します。稼働中のエージェントカタログにネイティブペルソナがある場合はそれを使用し、ない場合は選択した方法で同梱のブリーフィング全文を渡します。そのルールは一字一句そのまま保持します。起動には Skill ツールを pstack-harness とともに呼び出します。その Spawn a role セクションで役割を解決し、この CLI の起動呼び出しを組み立てます。
2. そのレポートと差分を調査します。アプリケーションコードの編集、対象範囲からの逸脱、例外保護された削除、誤った MUST KILL の理由、意図的に残されたコードを問題ありとして扱うフラグは却下します。私たちのコードに関する予想外の事柄へのフラグは、引き続き対応可能な状態にします。これらのコメントは復元しません。残すという判断は、変更できない事柄について述べている証拠がある場合に限り認めます。対象範囲内で見落とされた lint と TypeScript の抑制を監査します。正確性や安全性に関する抑制は、引き続き対応必須の MUST KILL とします。削除を復元するのは、厳密な例外と対象範囲に即した根拠がある場合に限ります。内容の薄い IMPORTANT や do not remove の削除指示または残置指示を受け入れる前に、そのシンボルについて how または why を指定して Skill ツールを呼び出します。削除指示が曖昧な場合は復元しません。残置指示の根拠が否定された場合、または曖昧なままの場合は削除します。却下したレポートを、その失敗内容を明示して一度だけ差し戻し、再実行します。2回目も却下し、未解決として報告して、このスキルの実行を失敗で終了します。
3. 受け入れた指摘のうち簡単に修正できるものは、不要な経路の削除、パラメーターの削除、または実際の API の使用によって直接修正します。修正に構造設計が必要な場合は、受け入れた指摘と周辺コードについて Skill ツールを一度だけ 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 のスケッチ、修正、仕組み化の提案、仕組み化した内容、未強制の制約、その他の未解決作業を報告します。