judgment-daylisted

## 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 ### Cost Gate Judgment-day is the most expensive review in the toolkit (two blind judges + fix agent + re-judge rounds). Do not make it the default reflex: routine or small changes get the cheap single-reviewer check formalized as **Light Mode** below. Reserve the dual protocol for high-risk changes, large diffs, or SDD verification gates. An explicit user request always runs what was asked. ## Protocol Only the orchestrator runs this protocol; it coordinates and synthesizes but NEVER reviews code itself. Judge and fix delegates work only on the scoped input they receive — they never coordinate rounds, synthesize buckets, decide escalation, or ask the user anything. If the target scope is unclear, stop and ask before launching — partial reviews are useless. ### Pattern 0: Skill Resolution (before launching judges) Resolve project standards before launching ANY sub-agent. In OpenCode installs, the `skill-registry` plugin generates `.ai/atl/skill-registry.md` on session start. 1. Read `.ai/atl/skill-registry.md` from the project root if it exists; skip registry injection if it does not. 2. Identify