judgment-day

Activation Contract

Load this skill only when the user explicitly asks for Judgment Day, dual/adversarial review, or equivalent Spanish trigger (juzgar, que lo juzguen). Review a specific target: files, feature, PR, or architecture slice.

Within this QA boilerplate, this skill is cited by:

/test-automation — Review phase, as one of the two ways to satisfy its MANDATORY separate verifier (this skill OR /pr-review-lead), for every change, not only high-risk ones. That Review step counts as the explicit request above.
/git-flow-master — OPTIONAL pre-PR gate when the diff is large or touches shared fixtures / base classes
/framework-development — OPTIONAL pre-archive review of framework evolution diffs

Outside the /test-automation verifier slot it is never invoked automatically; users opt in via explicit trigger.

Inputs — read these first, in this order

Canonical reading order for any AI starting cold on a Judgment Day review. Read in order; stop earlier when the target is small enough that later inputs add no signal.

The diff / files / PR / architecture slice under review — the literal target the user named.
AGENTS.md — repo conventions, Critical Rules, behavioral layer (the judges must score against these, not generic best-practice).
.agents/skills/REGISTRY.md — skill registry; resolve which project skills apply to the target's file paths + task type, and inject the same Skills to load before work block into both judge prompts.
The change's spec / PR description / Jira ticket — the stated intent. Judges score against intent, not their imagined intent.
references/prompts-and-formats.md — judge prompts, fix prompts, warning rubric, verdict table format.
Prior judge outputs from earlier rounds (Round 2+ only) — to detect regressions or stale findings vs. new ones.

Hard Rules

Resolve project skills before launching agents: read skill registry, match skill paths by target files/task, and inject the same Skills to load before work block into both judge prompts and fix prompts.
Launch two blind judges in parallel with identical target and criteria; never review the code yourself.
Wait for both judges before synthesis; never accept a partial verdict.
Classify warnings as WARNING (real) only if normal intended use can trigger them; otherwise downgrade to INFO as WARNING (theoretical).
Ask before fixing Round 1 confirmed issues.
After any fix agent runs, immediately re-launch both judges in parallel before commit/push/done/session summary.
Terminal states are only JUDGMENT: APPROVED or JUDGMENT: ESCALATED.
After 2 fix iterations with remaining issues, ask the user whether to continue.

Decision Gates

Condition	Action
Target unclear	Ask for scope; do not launch judges.
No skill registry	Warn, proceed with generic criteria, and record `Skill Resolution: none`.
Both judges find same CRITICAL/real WARNING	Confirmed; ask/fix according to round rules.
One judge finds issue	Suspect; report and triage, do not auto-fix.
Judges contradict	Escalate for manual decision.
Round 2+ has only theoretical warnings/suggestions	Report as INFO; do not re-judge.

Execution Steps

Confirm target and optional custom criteria.
Resolve exact skill paths from registry or warn if missing.
Start Judge A and Judge B concurrently via delegation.
Synthesize findings into confirmed, suspect, contradiction, and INFO buckets.
Ask before Round 1 fixes; delegate a separate fix agent for confirmed approved fixes only.
Re-judge in parallel after fixes; repeat until approved, escalated, or user asks to stop.
Before any terminal action, verify every active Judgment Day has a terminal state.

Output Contract

Return ## Judgment Day — {target} with round number, verdict table, confirmed/suspect/contradiction counts, fixes applied, re-judgment result, Skill Resolution, and final JUDGMENT: APPROVED ✅ or JUDGMENT: ESCALATED ⚠️.

Anti-patterns — NEVER do these

J1. NEVER let the two judges see each other's verdicts before synthesis — blind review is the entire value proposition; cross-contamination collapses two judges into one.
J2. NEVER skip the re-judge step after fixes — fixes can regress other behavior; only a fresh dual verdict confirms the change actually landed clean.
J3. NEVER run judgment-day on a diff with > 30 files in a single pass — signal degrades past that size. Split into focused per-area reviews and synthesize manually.
J4. NEVER override a judge's reject without documenting WHY in the synthesis — silent overrides destroy the audit trail and the next reviewer cannot tell if the issue was triaged or missed.
J5. NEVER use judgment-day for trivial typo / format-only / autogenerated diffs — orchestration overhead (two judge agents + synthesis + re-judge loop) exceeds the value of the verdict.
J6. NEVER feed judges different prompts, different criteria, or different context — the blindness only works if both judges see the identical brief. Asymmetric briefs produce asymmetric verdicts that look like real disagreement but are artifacts.

References

references/prompts-and-formats.md — judge/fix prompts, warning rubric, verdict tables, and language snippets.