mcpField
J
judgment-day

judgment-day

github.com/fearovex-labsテスト・品質54 回インストール
リポジトリ

judgment-day について

Claude Code向けの、2人の判定役が並行して行う対抗的なコードレビュー用スキルです。レビュー前にプロジェクト固有の規則を解決し、修正役を別に委任して、判定を記録しレビュー証明を作成します。

主な機能

  1. 012人の判定役による並列レビュー
  2. 02修正エージェントの分離
  3. 03レビュー前のプロジェクト規則解決
  4. 04判定の保存と証明の作成

活用シーン

  1. 01対抗的なコードレビュー
  2. 02プロジェクト規則に沿った変更確認
  3. 03レビュー結果の証明としての記録

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/fearovex-labs/agent-config --skill judgment-day

インストール後、Claude Code で/judgment-dayを入力して読み込まれたか確認します。

詳細

トリガー:「judgment day」、「judgment-day」、「review adversarial」、「dual review」、「doble review」、「juzgar」、「que lo juzguen」。



Claude の実行配線

このメモでは、上記のツールに依存しないロジックを Claude Code ハーネスに結び付けます。ここに記載されているのは、ほかのツールには移植できない実行レイヤーです。

両方の審査担当者と修正エージェントのモデルルーティングは、core/agents/sdd-orchestrator/logic.md の MODEL-ROUTING フェンスに従います(バランス型ティア → fable)。

パターン 0:スキルの解決(審査担当者の起動前)

サブエージェントを起動する前に、必ず Skill Resolver Protocol(_shared/skill-resolver.md)に従ってください。

  1. スキルレジストリを取得します。engram を検索し(mem_search(query: "skill-registry", project: "{project}"))、見つからない場合はプロジェクトルートの .agent-config/skill-registry.md を使用します。どちらもなければスキップします。
  2. 対象ファイル/スコープを特定します。審査担当者がレビューするコードを確認します。
  3. レジストリの Compact Rules から、以下の方法で関連するスキルを照合します。
    • コードのコンテキスト:対象ファイルの拡張子/パス(例:.go → go-testing、.tsx → react-19、typescript)
    • タスクのコンテキスト:「コードのレビュー」→ フレームワーク/言語のスキル、「PR の作成」→ branch-pr スキル
  4. 一致するコンパクトルールを含む ## Project Standards (auto-resolved) ブロックを作成します。
  5. このブロックを両方の審査担当者のプロンプトと修正エージェントのプロンプトに、同一の内容で挿入します。

これにより、審査担当者は一般的なベストプラクティスだけでなく、プロジェクト固有の標準に照らしてレビューできます。

レジストリがない場合:ユーザーに「スキルレジストリが見つかりませんでした。審査担当者はプロジェクト固有の標準なしでレビューします。修正するには skill-registry を実行してください。」と警告し、一般的なレビューのみを実施します。

判定記録の永続化

中立的な「最終判定を過去の作業のストレージに保存する」というルールは、engram では mem_save(type は decision、topic_key: judgment-day/{target-slug}/verdict、capture_prompt: false)に該当します。クリーンな APPROVED 判定も含め、毎回実行します。

レビュー証明書の発行(判定後)

最終判定を記録したら、レビュー対象の内容を証明するレビュー証明書を発行します。リポジトリのルートから Bash を一度呼び出します。

node core/hooks/_shared/receipt-mint.js --minter judgment-day --verdict <PASS|PASS_WITH_WARNINGS|FAIL>

判定結果を証明書の判定に対応付けます。APPROVED 判定は PASS、未解決の警告を含む承認は PASS_WITH_WARNINGS、却下は FAIL です。毎回発行します。FAIL の証明書も証拠となるため、レビューが通過したと決めつけずに、バリデーターがその判定を提示します。

--files を指定しない場合、証明書は現在ステージングされているパスを対象とします。レビュー対象とステージング済みの内容が異なる場合は、--files a.js,b.js を渡してください。 ベストエフォートで対応します。発行に失敗した場合は報告して処理を続行します。判定が変わることはありません。

委任の仕組み
  • 審査担当者は並列のサブエージェントとして起動します(非同期。Agent ツールを使い、1 つのメッセージ内で複数回呼び出します)。逐次実行はしないでください。
  • オーケストレーターは両方の結果を読み取り、パターン 2 に従って統合します。オーケストレーター自身がレビューを行ってはいけません。
  • 修正エージェントへの委任は別途行います。審査担当者を修正担当として再利用してはいけません。
スキル解決のフィードバック

結果を返す委任のたびに、各審査担当者/修正エージェントの応答にある **Skill Resolution** フィールドを確認します。

  • injected → スキルが正しく渡されています ✅
  • fallback-registry、fallback-path、または none → スキルキャッシュが失われています(おそらくコンパクションが発生)。ただちにレジストリを読み直し、以降のすべての委任にコンパクトルールを挿入します。

これは自己修正の仕組みです。フォールバックの報告を無視しないでください。

コメント