yonathan-boop/Claude

antislop-code

Anti Slop: AIコーディングエージェントのためのルール。Code Commentsスキル

antislopシステムの一部。antislop.md（コア）と一緒に読んでください。このスキルは、汎用的なAIらしいコメント（装飾的、自明の再述、固い、うるさい）をフィルタリングし、本当の情報を持つコメントを保持します。コアルールを番号で参照し、重複や再ナンバリングは行いません。コードコメントを作成・編集するタスクの際にロードしてください。

このスキルの使い方

• antislop.mdと一緒に、コードコメントに触れるタスクがあれば常にロードします。コアはメカニズム（目的テスト、3つのティア、Delivery Gate）を保持し、このスキルはコメント固有の詳細を保持します。
• 各エントリは同じ形を持ちます：Tell（パターン）、Why（なぜスロップと読まれるか）、Fix（代わりに何をするか）、そして該当するコアルールをR-XXとして引用します。
• スコープガードレール： このスキルはコメントのみを変更します。実行可能コード、識別子、インポート、フォーマット、インデント、空白、制御フロー、またはロジックを決して変更しないでください。迷ったら、コードには触れないでください。
• コアのDelivery Gateはゲートのままです。このファイルの最後にある「Code Comment Checklist」は、それと一緒に実行するコメント固有の補足です。

何も追加しないコメント

装飾的な区切り線

• Tell: 繰り返し文字、ALL CAPSラベル、またはセクション名の周りのボックス描画から構築されたバナーコメント：// =======================（Authenticationの周り）、// -------- WORKFLOW --------、または/* ---- ROUTES ---- */ヘッダー。
• Why: 装飾自体がメッセージです。=や-で囲まれたラベルは、情報を追加せずに「AIが作った」ことを示し、ALL CAPSは叫んでいるように読まれます。
• Fix: 単一のプレーンな行に置き換えるか、ラベルが何も追加しない場合は完全に削除します（R-31）。

自明の再述

• Tell: 次の行や宣言が既に示していることを繰り返すコメント、例：let count = 0の上の// Initialize the variable、class User {}の上の// User class、function validateUser()の上の// Validate user、またはconst userAge = 25; // User age is 25。
• Why: 読み込み負荷を2倍にするだけで、何も追加しません。コードが既にそれを言っています。コメントはただ繰り返しているだけです。
• Fix: 削除し、コード行はそのままにします。

ワークフローのナレーション

• Tell: フローをステップバイステップでナレーションするコメント、例：// Step 1: Validate input、// Step 2: Process request、// Step 3: Return response、または// First...、// Next...、// Finally...。
• Why: 制御フローはコード自体で見えます。番号を振ることは、説明ではなくチェックリストとして読まれます。
• Fix: 削除します。フローが本当に追いにくい場合、それはコメントの問題ではなく、構造の問題です。

空のラベル

• Tell: 情報の背後にない汎用的なラベル：// Main logic、// Core logic、// Business logic、// Helper function、// Entry point、// Error handling、または// Note: This is important. / // Important: Please read.
• Why: ラベルはカテゴリを名付けているのであって、事実を名付けているのではありません。「Main logic」は、読者がコードから推測できないことを何も教えてくれません。
• Fix: ラベルが具体的な情報を持たない限り削除します。「Note: retries happen only on 5xx」は価値がありますが、「Note: this is important」は価値がありません。

曖昧なプレースホルダー

• Tell: 何をするかを言わずに将来の作業を約束するコメント：// TODO: Improve this、// Future improvements、// Additional optimization can be added here、// Add more validation。
• Why: 曖昧なTODOはノイズです。タスク（何を、なぜ）ではなく、感情（これはより良くなる可能性がある）を名付けています。
• Fix: 削除します。TODOは、行動に移せる十分なコンテキストを持つ具体的なタスクを名付ける場合にのみ保持します。

シグネチャのエコー

• Tell: シグネチャだけを再述するドキュメント、例：名前とパラメータが全てを既に示している関数に対して、@param price The price.と@returns Total price.を繰り返すJSDocブロック。
• Why: シグネチャをエコーするドキュメントは、長さを追加するだけで、理解を追加しません。読者は新しいことを何も学びません。
• Fix: エコーを簡略化するか削除します。ビジネスルール、エッジケース、前提条件、アルゴリズム、制限、副作用、API動作、またはセキュリティへの影響を説明するドキュメントは保持します。本当のドキュメントを決して削除しないでください。

装飾的な絵文字

• Tell: コメント内で装飾として使用される絵文字、例：// ✅ Validationや// 🚀 Performance。
• Why: 絵文字はコード内では視覚的なノイズであり、特定のセット（✅、🚀、🔒）はAIのデフォルト語彙です。
• Fix: プレーンな英語に置き換えるか、ラベルが何も追加しない場合は削除します。

終了マーカー

• Tell: ブロックの終わりだけをマークするコメント、例：} // end if、# End of function、または// End processOrder。
• Why: 閉じ括弧は既にブロックを終わらせています。マーカーは習慣から存在しており、必要性からではありません。
• Fix: 削除します。まれに、長いファイルで終了マーカーが本当に混乱を防ぐ場合にのみ、習慣としてではなく、必要な場所に保持します。

どう読まれるべきか

過剰説明コメント

• Tell: 数行にわたって続き、理由、コンテキスト、履歴を積み重ねて、一行に収まる事実を説明する一つのコメント：スタブがPATHにあること、どのリリースで回避策が導入されたか、そして以前何が壊れていたかを説明する4行のブロック。すべての文は真実です。長さが特徴です。
• Why: 人間はメモを残し、生成器は事例を書きます。一行の事実を段落にパディングしたり、「なぜならX、だからY、そしてZ」というチェーンを構築したり、課題番号とそれを修正したバージョンを引用したりすることは、他のどのAIパターンと同じ飾りであり、重要な一行を重要でない行の下に埋もれさせます。
• Fix: 制約だけに削減します：一行、最大で二行、決して三行以上は避けます。プラットフォームの罠、静かな失敗、プロトコルルール、パフォーマンスコストは保持します。課題番号、バージョン履歴、推論チェーンは削除します。

行ごとのナレーション

• Tell: すべての些細なステートメントにコメントがあり、各行を書かれたとおりにナレーションする：// Initialize count、次に// Loop items、次に// Get item、次に// Increment、次に// Return result。
• Why: すべての行がコメントされている場合、どのコメントも重要ではありません。読者は意味のあるものを見つけるためにそれぞれを確認しなければなりません。
• Fix: 行ごとに一つではなく、論理ブロックごとに一つの簡潔なコメントを書きます。ブロックにコメントが必要ない場合は、何も書きません。

固いまたはうるさい言い回し

• Tell: 形式的、長い、または叫んでいるように聞こえるコメント：「This function is responsible for validating whether the supplied credentials are valid before continuing with the authentication process」、または大文字の// MAIN LOGIC。
• Why: 形式的でうるさい言い回しは、エンジニアが次の人にメモを残しているのではなく、生成されたように読まれます。
• Fix: 自然な開発者の声で、短い文（先頭だけ大文字）の行を書きます：// Validate credentials before issuing a token. 良いコメントは「何を」ではなく「なぜ」を説明し、短く保ちます。

禁止ではない（これらは保持する）

以下のことを説明するコメントは決して削除しないでください：

• ビジネスロジックと意図
• アーキテクチャ上の決定
• セキュリティに関する考慮事項
• パフォーマンスのトレードオフ
• 並行処理の動作
• プロトコルの詳細
• API契約
• 回避策
• エッジケースと前提条件
• ライセンスおよび法的通知

残すべき例：

// Stripe may retry webhook deliveries for up to three days.
// Ignore duplicate events using the event ID.

コメントは、コードが既に示していない何か（理由、制約、非自明な動作）を説明するときに、その場所に値します。

場所に値することは、何が残るかを示すだけで、どれだけ長く続くかを示すものではありません。回避策メモは、回避策についての一行であり、それに関する段落ではありません。上記の例が二行なのは、二つの事実が本物だからであり、二行が目標だからではありません。このリストは、コメントが本来受けるべきでないレビューを生き残る最も一般的な理由です：内容が正当に価値があるため、長さが精査されないのです。価値は長さではありません。

Code Comment Checklist

タスクがコメントに触れる場合、コアのDelivery Gateと一緒にこれらを実行してください。すべての回答が はい でなければなりません：

• すべてのコメントは、コードが既に示していない情報を追加していますか？(R-31)
• コメントは装飾的な区切り線、ALL CAPSバナー、ボックス描画ヘッダーを避けていますか？
• コメントは自明な行、宣言、シグネチャの再述を避けていますか？
• コメントはステップバイステップのワークフローナレーションを避けていますか？
• コメントはタスクを名付けない空ラベルや曖昧なTODOを避けていますか？
• コメントは装飾的な絵文字や終了マーカーを避けていますか？
• コメント密度は行ごとではなく、論理ブロックごとに一つですか？
• すべてのコメントは一行、または二行目が新しい事実を運ぶ場合のみ二行ですか？
• 残ったコメントは短く、自然で、文の先頭だけ大文字で書かれていますか？
• スコープガードレールが守られていますか：コメントのみ変更され、コードは未変更ですか？