Judgment Day
Run two parallel blind judge sub-agents on the same implementation, merge findings, fix issues, and re-judge until both pass or escalate after two iterations.
Overview
Judgment Day is an agent skill most often used in Ship (also Build) that runs parallel blind dual-judge reviews, synthesizes findings, fixes issues, and re-judges until both pass or escalates after two iterations.
Install
npx skills add https://github.com/fearovex/claude-config --skill judgment-dayWhat is this skill?
- Launches two independent blind judge sub-agents in parallel on the same review target
- Synthesizes conflicting findings, applies fixes, and re-judges with a two-iteration cap before escalation
- Resolves applicable project skills via Skill Resolver Protocol before any judge runs
- Explicit triggers: judgment day, dual review, review adversarial, and Spanish equivalents
- Procedural format v1.1 under Apache-2.0 for repeatable high-confidence review
- Maximum 2 review-fix-rejudge iterations before escalation
- Metadata version 1.1
Adoption & trust: 1 installs on skills.sh; 1 GitHub stars; 3/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
A single reviewer—or you rushing a merge—can miss edge cases, architecture gaps, or correlated blind spots right before production.
Who is it for?
Solo builders shipping sizable implementations who want structured dual review with fix-and-rejudge loops before merging to main.
Skip if: Trivial one-line edits, tasks where you have not defined review scope, or situations where you cannot run parallel sub-agents or apply fixes in the repo.
When should I use this skill?
User says judgment day, judgment-day, review adversarial, dual review, doble review, juzgar, or que lo juzguen; or after significant implementations before merging when single-reviewer blind spots are costly.
What do I get? / Deliverables
You get a synthesized pass from two independent judges after applied fixes, or a clear escalation when two review iterations still fail—so merge decisions rest on adversarial consensus.
- Synthesized dual-judge findings
- Applied fixes from failed review rounds
- Pass from both judges or escalation after iteration cap
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Judgment Day is shelved under Ship because its primary trigger is pre-merge, high-stakes review when a wrong blind spot is more expensive than extra review rounds. Review subphase matches adversarial dual-judge synthesis and fix loops aimed at merge readiness rather than initial implementation or deployment.
Where it fits
After finishing a large API or agent feature, run Judgment Day on the touched modules before opening the merge PR.
Invoke when the user says que lo juzguen to force parallel judges on the PR diff scope.
Use findings from dual judges to harden tests or edge-case handling discovered only under adversarial review.
Stress-test a prototype architecture document or spike implementation before committing to full build.
How it compares
Use instead of a single generic code-review chat when you need blind parallel judges and an enforced re-review loop before merge.
Common Questions / FAQ
Who is judgment-day for?
Judgment Day is for indie developers and small teams using agentic IDEs who want adversarial, dual-blind review before merging significant code or architecture changes.
When should I use judgment-day?
Use it in Ship/review when you say judgment day or dual review; after large Build implementations; before merge when bug cost exceeds review time; whenever one reviewer might miss edge cases.
Is judgment-day safe to install?
It orchestrates sub-agents and may modify code during fix loops—review the Security Audits panel on this page and run it on branches with backups or PRs, not directly on untested production.
SKILL.md
READMESKILL.md - Judgment Day
**Triggers**: "judgment day", "judgment-day", "review adversarial", "dual review", "doble review", "juzgar", "que lo juzguen". ## When to Use - User explicitly asks for "judgment day", "judgment-day", or equivalent trigger phrases - After significant implementations before merging - When high-confidence review of code, features, or architecture is needed - When a single reviewer might miss edge cases or have blind spots - When the cost of a production bug is higher than the cost of two review rounds ## Critical Patterns ### Pattern 0: Skill Resolution (BEFORE launching judges) Follow the **Skill Resolver Protocol** (`_shared/skill-resolver.md`) before launching ANY sub-agent: 1. Obtain the skill registry: search engram (`mem_search(query: "skill-registry", project: "{project}")`) → fallback to `.agent-config/skill-registry.md` from the project root → skip if none 2. Identify the target files/scope — what code will the judges review? 3. Match relevant skills from the registry's **Compact Rules** by: - **Code context**: file extensions/paths of the target (e.g., `.go` → go-testing; `.tsx` → react-19, typescript) - **Task context**: "review code" → framework/language skills; "create PR" → branch-pr skill 4. Build a `## Project Standards (auto-resolved)` block with the matching compact rules 5. Inject this block into BOTH Judge prompts AND the Fix Agent prompt (identical for all) This ensures judges review against project-specific standards, not just generic best practices. **If no registry exists**: warn the user ("No skill registry found — judges will review without project-specific standards. Run `skill-registry` to fix this.") and proceed with generic review only. ### Pattern 1: Parallel Blind Review - Launch **TWO** sub-agents via `delegate` (async, parallel — never sequential) - Each agent receives the **same target** but works **independently** - **Neither agent knows about the other** — no cross-contamination - Both use identical review criteria but may find different issues - NEVER do the review yourself as the orchestrator — your job is coordination only ### Pattern 2: Verdict Synthesis The **orchestrator** (NOT a sub-agent) compares results after both `delegation_read` calls return: ``` Confirmed → found by BOTH agents → high confidence, fix immediately Suspect A → found ONLY by Judge A → needs triage Suspect B → found ONLY by Judge B → needs triage Contradiction → agents DISAGREE on the same thing → flag for manual decision ``` Present findings as a structured verdict table (see Output Format). ### Pattern 3: Fix and Re-judge 1. If **confirmed issues** exist → delegate a **Fix Agent** (separate delegation) 2. After Fix Agent completes → re-launch **both judges in parallel** (same blind protocol, fresh delegates) 3. **Max 2 fix iterations.** If still failing → JUDGMENT: ESCALATED — report to user with full history 4. If both judges return clean → JUDGMENT: APPROVED ✅ --- ## Decision Tree ``` User asks for "judgment day" │ ├── Target is specific files/feature/component? │ ├── YES → continue │ └── NO → ask user to specify scope before proceeding │ ▼ Resolve skills (Pattern 0): read registry → match by code + task context → build Project Standards block ▼ Launch Judge A + Judge B in parallel (delegate, async) — with Project Standards injected ▼ Wait for both to complete (delegation_read both) ▼ Synthesize verdict │ ├── No issues found? │ └── JUDGMENT: APPROVED ✅ (stop here) │ ├