作業内容が届く前に、エージェントが取るショートカットを発見します。

緑色になるためにスキップされたテスト、隠されたエラー、残されたスタブ、無視された型チェック。Anti-slopはエージェントが行ったすべての変更をチェックし、各発見事項とともに開発者エージェントに送り返します。

タスクチェックアウト時のクーポンコード適用処理レビュー中
品質ゲート
開発者品質ゲート2を試行合格
Anti-slop
新たなコード負債を許さない合格
0件がブロック中 · 0件が新規導入 · 1件が変更済み · 14件は既存のまま
開発者品質ゲート1を試行ブロック済み · 開発者へ送信
Anti-slop
新たなコード負債を許さない修復が必要
2件がブロック中 · 2件が新規導入 · 1件が変更済み · 14件は既存のまま
  • テストがスキップされているsrc/checkout/coupon.test.ts:88it.skip('rejects an expired coupon', …)
  • エラーが飲み込まれているsrc/checkout/apply-coupon.ts:41} catch {}
発見された問題
  • 修正済みテストがスキップされているAnti-slop
  • 修正済みエラーが飲み込まれているAnti-slop

タスクビューはCoroidポータルの再現です。そこに表示されるタスク、ファイル、発見事項は例示用です。

ルール
106
ファミリー
13
デフォルトでブロックするルール
44
変更をブロックする既存の発見事項
0

検出対象となる項目

ルールはファミリーに分かれています。各ルールはブロック、警告、または記録のみを行い、オーナーは組織またはプロジェクトごとに設定を変更できます。

テスト
焦点を絞られたまたはスキップされたテスト、削除されたテスト、削除または弱められたアサーション、失敗しないテスト、不安定なテストを隠すリトライ。
  • .only
  • .skip
  • expect(true).toBe(true)
抑制
新しいlint無効化、無視された型エラー、anyへのキャスト、カバレッジ対象外のコード。
  • @ts-ignore
  • as any
  • eslint-disable
ビルドおよびCI
削除されたテストステップや失敗を許容する設定、カバレッジ閾値の引き下げ、テストなしで通過するテスト実行、スキップされたコミットフック、ビルド出力のコミット。
  • continue-on-error: true
  • --passWithNoTests
テスト証拠
何も実行されなかったテスト実行、前回の成功時より少ないテスト数、完了と報告された部分実行、新しい実行として扱われたキャッシュ結果。
  • Tests: 0 total
  • --onlyChanged
本番コード
プレースホルダー実装、デバッグコード、「実際の実装では」といった注釈、人向けの指示、モックデータ、テストコードをインポートする本番コード。
  • throw new Error('Not implemented')
  • debugger;
エラー処理
エラーが隠されたりデフォルト値の背後に置かれたり、失敗時にアクセスを許可する権限チェック、制限なしのリトライ。
  • except: pass
  • .catch(() => {})
セキュリティ
ハードコーディングされたシークレット、TLS検証の無効化、認証ガードの削除、資格情報を伴うワイルドカードCORS、および文字列から構築されるSQL。
  • rejectUnauthorized: false
  • verify=False
アーキテクチャ
新しいインポートサイクル、宣言した境界を越えるインポート、重複したブロック、変更で未使用になったコード、廃止されたパターンの新しいコピー。
依存関係
ロックファイルなしのマニフェスト変更、すでに存在する機能を担う第二のライブラリ、バージョン指定なしの更新、仕様で要求されていないアップグレード。
  • "latest"
キャッシング
テナントを含まないキャッシュキー、有効期限がないメモリ内キャッシュ、コード実行時に読み込むべきビルド時の値。
コメント
次の行を繰り返すコメント、編集内容の説明、曖昧な表現、または隣接するコードと矛盾する記述。
  • // Updated to
  • // should work
変更範囲
仕様で指定されていないファイル、書式のみの変更、タスクで要求されていない名前の変更。
エージェントの処理経路
エージェントが実行中に行った操作。例えば、失敗したテストを削除したり、期待値を実際の実行結果に合わせて変更したりすること。

変更によって新たに生じた問題のみがブロックされます。

ほとんどのリポジトリには既にこれらのパターンが存在します。Anti-slopは各発見事項を発生元別に分類するため、既存の技術負債が無関係な作業を妨げることはありません。

新規導入
この変更で新たに発生したもの。ブロッキングルールに違反する発見事項がある場合、変更内容は開発者エージェントに戻されます。
変更対象
既に存在し、変更で編集される行や関数内にあるもの。記録され、変更管理のルールに従って修正されます。
既存の負債
リポジトリ内の他の場所にあるもの。Factory内で技術負債として記録され、特定のルールに違反する箇所を修正するタスクを作成できます。

コードを移動させただけでは新規導入とはみなされません。コピーした場合のみ新規導入とみなされます。

変更が及ぶ範囲はご自身で決定できます。

変更管理ルールにより、開発者エージェントが作業中に整理できる範囲が決まります。

  1. 精密な修正仕様で要求される範囲のみ。その他の問題は報告されるだけで、修正されません。
  2. バランスの取れた修正デフォルト変更で触れる行にある小さな問題も同時に修正します。
  3. 修復型修正変更で編集される関数内にある発見事項も同時に整理します。

開発者エージェントも同じルールに従って作業します。

Anti-slopは最終的な判定に留まらず、エージェントが変更を作成する際にルールを適用し、それを無視することはできません。

  1. エージェントは変更管理ルールと隔離されたパターンを基に作業を開始し、各パターンには代替となる内容が設定されています。
  2. 編集後すぐに迅速なルールを適用し、QA実行前にブロッキングな問題を修正するためのチャンスが1回与えられます。
  3. エージェントは自身の検出結果を承認できません。エージェントがテストが誤りだと判断して変更を行った場合、その変更を承認するのはレビュー担当者でなければなりません。
  4. リポジトリ内のファイル .coroid/anti-slop.yml にルールを追加したり生成されたパスを除外したりできます。このファイルは変更のベースから読み込まれるため、変更によって自身のルールが緩和されることはありません。

既に稼働中のエージェントにも同じルールを適用できます。

自社のコーディングエージェントを利用するエンジニアも、組織のルールを適用できます。

AGENTS.md snippet
プロジェクトの変更規律、隔離されたパターン、および最も重要なルールを含む、エージェント向けの指示セクションをダウンロードできます。
Coroid MCP server
anti_slop_rules には公開されたポリシーが記載され、anti_slop_scan は同期されたプロジェクトのブランチをスキャンします。どちらも読み取り専用です。
プルリクエストに対するCoroid Check
pull request のチェック機能を有効にすると、開発者が作成する GitHub のプルリクエストに対して同じチェックが実行され、各問題が該当行にマークされます。

まずは当社のコードでテストを実施しました。

Coroid は1人の人間と100個のエージェントによって構築されたため、他の誰かのリポジトリで使用される前に、まず Coroid 自身のリポジトリで anti-slop が実行されました。

すべてのソースファイルのスキャン

エージェントが作成したと仮定して、Coroidのリポジトリ内にある全ての11,536ソースファイルをスキャンしました。その結果、ルールが誤って検出したパターンが6件見つかりました。これらを修正したことで、ブロッキングとなる検出件数は5,366から2,253へと減少しました。

依然被ブロックされるのは、ルールが検出すべき対象です。例えば、通知コードに残された次のような注記:「実際の実装では、ユーザーのFCMトークンを取得します。」

モデルが判定するルール

2つのルールにより、モデルは1行ずつ評価されます。1つ目はコード内で既に排除されている事象を防ぐためのチェック、もう1つは隣接するコードと矛盾するコメントです。これらはあくまで助言に過ぎません。 600実際にマージされた変更から抽出された候補行の中で、誤検知されたのは なし誤って判定され、そのコストは最大で $0.0015スキャンごとに。

Quality Control機能で有効に設定できます。

オーナーと管理者は、組織のデフォルト設定または個別のプロジェクトで anti-slop を有効にできます。次回そのプロジェクトを実行すると、これが適用されます。

  1. 品質管理機能を開き、組織のデフォルト設定またはプロジェクトを選択します。
  2. Anti-slopを有効にします。これによりポリシーに5つの要件が追加されます。
  3. 変更の適用範囲とブロック対象となるグループを指定します。無効にしても次回以降もこの設定は保持されます。

追加される5つの要件

  • 変更内容は引き続きテストで検証されます
  • 未完了のコードやテスト専用のコードが本番環境にデプロイされることはありません
  • 新たな構造的負債は発生しません
  • 変更内容は指定された範囲内に留まり、このコードベースのスタイルに沿って記述されます
  • 新しい依存関係は実在し、信頼できるものです
Anti-slopガイドを読む
品質管理
各プロジェクトでチェック対象を選択できます。設定変更は即座に新規作業に適用されます。
ストアフロント独自の設定
タスクQA、プルリクエスト、リリース検証の際に実行されます。
すべての変更に対するチェック
チェックに失敗した変更は、誰もレビューする前に開発者に戻されます。
  • アンチスロップテストが弱まったり、エラーが無視されたり、プレースホルダーが配信されたり、構造的負債が増加した場合に変更内容を差し戻します。
  • 単体テストすべての変更に対して、リポジトリ内のユニットテストを検出して実行します。
  • ブラウザテスト2件のうち3件デフォルト設定と異なる変更内容に対してブラウザー上での操作を実行します。
  • 翻訳デフォルト設定と異なる変更された文字列が翻訳されているか、およびプレースホルダーや複数形の表現が一致しているかを確認します。
  • リポジトリチェック書式設定、ファイルサイズ、マイグレーション、統合テスト、セキュリティスキャンなど、独自のコマンドを実行します。
QA
  • 徹底したQA徹底的QAプロセスでは仕様に基づいて実際の証拠やスクリーンショットを収集します。この機能が無効な場合は標準的なQAが適用されます。

すでに検証済みの成果物を確認しましょう。

1つのプロジェクトでanti-slopを有効にし、実行前に返される内容を確認できます。