no-comments について
no-commentsは、Comment Sickoというサブエージェントにコメントのレビューを委任し、指定されたファイルや差分の範囲内で採用した指摘に対応するコードレビュー用スキルです。抑制設定や制約も確認し、修正内容と未完了の作業を報告します。
主な機能
- 01Comment Sickoへのレビュー委任
- 02指定ファイルや差分の確認
- 03採用した指摘の範囲チェック
- 04lintとTypeScriptの抑制設定の監査
- 05修正と未完了作業の報告
活用シーン
- 01コード差分内のコメントのレビュー
- 02対応可能な問題コメントの削除
- 03範囲内のlint抑制設定の確認
- 04レビュー指摘と残作業の追跡
インストール
コマンドをコピーしてターミナルで実行します。
$
npx skills add https:/インストール後、Claude Code で/no-commentsを入力して読み込まれたか確認します。
同梱ファイルagents/openai.yamlreferences/comment-sicko.md
詳細
コメントなし
太字またはバッククォートで記されたスキル名、あるいは /<name> として実行するスキル名は、このスキルのディレクトリと同階層にある ../<name>/SKILL.md ファイルを指します。接頭辞なしで記された原則名は、../principle-<name>/SKILL.md を指します。そのファイルを読み、指示に従ってください。pstack のスキルのほとんどはユーザー専用なので、スキルツールでは読み込めません。すべての delegate_task 呼び出しには、../poteto-mode/SKILL.md の「Subagents」セクションにある既定の設定を適用してください。
Comment Sicko を起動してください。承認された指摘に対処してください。
Comment Sicko の新鮮な視点を優先してください。
対象範囲
呼び出し元が指定したファイルまたは差分を使用してください。指定がなければ、デフォルトの main ブランチを基準とする現在の差分（作業ツリーを含む）を使用してください。
手順
~/.config/pstack/pstack-models.mdに記載された「judgment and prose」モデル（ファイルまたは行が見つからない場合は親のモデル）を使って、Comment Sickoというタイトルのdelegate_task子エージェントを起動します。その依頼の冒頭には、references/comment-sicko.mdの内容をそのまま貼り付け、続けて how と why の SKILL.md ファイルの絶対パスと、「/howまたは/whyを実行する前に、その SKILL.md をすべて読み、指示に従うこと」という文言を記載し、その後に対象範囲を記載します。poteto-mode スキルの「Subagents」セクションに従い、各サブエージェントの推論レベルと高速または標準の速度を選択してください。ルールを言い換えて再掲しないでください。- 報告と差分を確認します。アプリケーションコードの編集、対象範囲外への逸脱、例外で保護された削除、誤った
MUST KILLの理由、意図的に残されたコードを問題視するフラグは却下してください。コードの予期しない動作に対するフラグは、対処可能な内容に整えてください。そのようなコメントは復元しないでください。「残す」という判断を認めるのは、変更できない対象についてのコメントだと証明できる場合に限ります。スコープ内で見落とされた lint と TypeScript の抑制を監査してください。正確性または安全性に関する抑制は、対処可能なMUST KILLのままにしてください。削除の復元は、厳密な例外とスコープ内の根拠がある場合に限ります。内容の薄いIMPORTANTまたはdo not removeの削除指摘や存続指摘を受け入れる前に、そのシンボルについて/howまたは/whyを実行してください。削除指摘が曖昧な場合は復元しないでください。存続指摘が否定された場合、または依然として曖昧な場合は削除してください。却下した報告は、失敗内容を明示して、新しいdelegate_taskで再実行してください。2回目も却下した場合は、未解決として報告し、/no-commentsを失敗にしてください。 - 承認された指摘のうち単純なものは、不要なパスの削除、パラメーターの削除、または実際の API の使用によって直接修正してください。修正に構造の検討が必要なものがある場合は、承認された指摘と周辺コードを対象に
/architectを1回実行してください。提案内容の確認で止めてください。構造設計は Architect が行います。実装は手順4で行います。 - 対象範囲内で、根本原因に対する最小限の修正を実装してください。指摘された回避策はすべて削除してください。根本原因が対象範囲外にある場合は、対象範囲内で最小限の修正を行い、残りを未解決として報告してください。principle-fix-root-causes と principle-redesign-from-first-principles のスキルは、意図を定めるための指針に限ります。対象範囲を広げたり、その外にある事例を修正したりする根拠にはなりません。症状を抑えるためのガードを追加しないでください。
- 制約コメントには
do not remove、do not change wording、またはtalk to X before changingと記載されています。変更できない対象についてのコメントは残してください。対象範囲内で最も低コストな型、実行時、テスト、または CI の lint を提案してください。対話形式での承認を待ってください。無人実行および評価では、呼び出し元による事前承認が必要です。承認された場合は制約をコード化してからコメントを削除してください。承認されなかった場合はコメントを削除し、制約を未解決として報告し、対象範囲外の作業案を示してください。 - 削除数、復元したコメント、再実行、Architect の提案、修正、コード化の提案、コード化した内容、強制されていない制約、その他の未解決事項を報告してください。
コメント
Markdown 対応