judgment-day について
Claude Code向けの、2人の判定役が並行して行う対抗的なコードレビュー用スキルです。レビュー前にプロジェクト固有の規則を解決し、修正役を別に委任して、判定を記録しレビュー証明を作成します。
主な機能
- 012人の判定役による並列レビュー
- 02修正エージェントの分離
- 03レビュー前のプロジェクト規則解決
- 04判定の保存と証明の作成
活用シーン
- 01対抗的なコードレビュー
- 02プロジェクト規則に沿った変更確認
- 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)に従ってください。
- スキルレジストリを取得します。engram を検索し(
mem_search(query: "skill-registry", project: "{project}"))、見つからない場合はプロジェクトルートの.agent-config/skill-registry.mdを使用します。どちらもなければスキップします。 - 対象ファイル/スコープを特定します。審査担当者がレビューするコードを確認します。
- レジストリの Compact Rules から、以下の方法で関連するスキルを照合します。
- コードのコンテキスト:対象ファイルの拡張子/パス(例:
.go→ go-testing、.tsx→ react-19、typescript) - タスクのコンテキスト:「コードのレビュー」→ フレームワーク/言語のスキル、「PR の作成」→ branch-pr スキル
- コードのコンテキスト:対象ファイルの拡張子/パス(例:
- 一致するコンパクトルールを含む
## Project Standards (auto-resolved)ブロックを作成します。 - このブロックを両方の審査担当者のプロンプトと修正エージェントのプロンプトに、同一の内容で挿入します。
これにより、審査担当者は一般的なベストプラクティスだけでなく、プロジェクト固有の標準に照らしてレビューできます。
レジストリがない場合:ユーザーに「スキルレジストリが見つかりませんでした。審査担当者はプロジェクト固有の標準なしでレビューします。修正するには 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→ スキルキャッシュが失われています(おそらくコンパクションが発生)。ただちにレジストリを読み直し、以降のすべての委任にコンパクトルールを挿入します。
これは自己修正の仕組みです。フォールバックの報告を無視しないでください。