judgment-day

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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
  • 用户明确要求"judgment day"、"judgment-day"或等效触发短语
  • 重大功能实现完成后,合并代码之前
  • 需要对代码、功能或架构进行高可信度审查时
  • 单一审查者可能遗漏边缘情况或存在盲区时
  • 生产环境出现bug的成本高于两轮审查的成本时

Critical Patterns

核心模式

Pattern 0: Skill Resolution (BEFORE launching judges)

模式0:技能解析(启动审查Agent之前)

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
    .atl/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.
遵循技能解析协议
_shared/skill-resolver.md
),在启动任何子Agent之前:
  1. 获取技能注册表:搜索engram(
    mem_search(query: "skill-registry", project: "{project}")
    )→ 备用方案:从项目根目录读取
    .atl/skill-registry.md
    → 如果都没有则跳过
  2. 确定目标文件/范围 —— 审查Agent将审查哪些代码?
  3. 通过以下方式匹配注册表中精简规则的相关技能:
    • 代码上下文:目标文件的扩展名/路径(例如:
      .go
      → go-testing;
      .tsx
      → react-19, typescript)
    • 任务上下文:"review code" → 框架/语言技能;"create PR" → branch-pr技能
  4. 构建包含匹配精简规则的
    ## Project Standards (auto-resolved)
  5. 将此块注入到两个审查Agent的提示词和修复Agent的提示词中(所有提示词中的内容完全相同)
这确保审查Agent依据项目特定标准进行审查,而非仅遵循通用最佳实践。
如果不存在注册表:向用户发出警告("未找到技能注册表 —— 审查Agent将在无项目特定标准的情况下进行审查。运行
skill-registry
来解决此问题。"),然后仅进行通用审查。

Pattern 1: Parallel Blind Review

模式1:并行盲审

  • 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
  • 通过
    delegate
    启动两个子Agent(异步、并行 —— 绝不能串行)
  • 每个Agent接收相同的目标,但独立工作
  • 两个Agent互不了解对方 —— 不存在交叉干扰
  • 两者使用相同的审查标准,但可能发现不同的问题
  • 编排者绝不能自行进行审查 —— 你的职责仅为协调

Pattern 2: Verdict Synthesis

模式2:结论综合

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).
编排者(而非子Agent)在两次
delegation_read
调用都返回结果后对比审查结果:
Confirmed   → 两个Agent均发现的问题          → 高可信度,立即修复
Suspect A   → 仅审查Agent A发现的问题         → 需要分类处理
Suspect B   → 仅审查Agent B发现的问题         → 需要分类处理
Contradiction → 两个Agent对同一问题存在分歧 → 标记为需人工决策
以结构化结论表格呈现审查结果(参见输出格式)。

Pattern 3: Fix and Re-judge

模式3:修复与重新审查

  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 ✅

  1. 如果存在已确认的问题 → 委托修复Agent(单独委托)
  2. 修复Agent完成后 → 重新并行启动两个审查Agent(遵循相同的盲审协议,使用新的委托实例)
  3. 最多2次修复迭代。如果仍未通过 → 结论:升级处理 —— 向用户提交完整历史记录
  4. 如果两个审查Agent均返回无问题 → 结论:批准 ✅

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)
├── Issues found (confirmed, suspect, or contradictions)?
│   └── Delegate Fix Agent with confirmed issues list
│       ▼
│       Wait for Fix Agent to complete
│       ▼
│       Re-launch Judge A + Judge B in parallel (Round 2)
│       ▼
│       Synthesize verdict
│       │
│       ├── Clean → JUDGMENT: APPROVED ✅
│       │
│       └── Still issues → Delegate Fix Agent again (Round 3 / iteration 2)
│           ▼
│           Re-launch Judge A + Judge B in parallel (Round 3)
│           ▼
│           Synthesize verdict
│           │
│           ├── Clean → JUDGMENT: APPROVED ✅
│           └── Still issues → JUDGMENT: ESCALATED ⚠️ (report to user)

用户要求"judgment day"
├── 目标是否为特定文件/功能/组件?
│   ├── 是 → 继续
│   └── 否 → 要求用户指定范围后再继续
解析技能(模式0):读取注册表 → 根据代码+任务上下文匹配 → 构建Project Standards块
并行启动审查Agent A和审查Agent B(delegate,异步)—— 注入Project Standards
等待两者完成(调用delegation_read获取两者结果)
综合结论
├── 未发现问题?
│   └── 结论:批准 ✅(到此结束)
├── 发现问题(已确认、疑似或分歧)?
│   └── 向修复Agent委托已确认问题列表
│       ▼
│       等待修复Agent完成
│       ▼
│       重新并行启动审查Agent A和审查Agent B(第2轮)
│       ▼
│       综合结论
│       │
│       ├── 无问题 → 结论:批准 ✅
│       │
│       └── 仍存在问题 → 再次委托修复Agent(第3轮/第2次迭代)
│           ▼
│           重新并行启动审查Agent A和审查Agent B(第3轮)
│           ▼
│           综合结论
│           │
│           ├── 无问题 → 结论:批准 ✅
│           └── 仍存在问题 → 结论:升级处理 ⚠️(向用户报告)

Sub-Agent Prompt Templates

子Agent提示词模板

Judge Prompt (use for BOTH Judge A and Judge B — identical)

审查Agent提示词(同时用于审查Agent A和B —— 完全相同)

You are an adversarial code reviewer. Your ONLY job is to find problems.
你是一名对抗式代码审查者。你的唯一任务是找出问题。

Target

审查目标

{describe target: files, feature, architecture, component}
{if compact rules were resolved in Pattern 0, inject the following block — otherwise OMIT this entire section}
{describe target: files, feature, architecture, component}
{if compact rules were resolved in Pattern 0, inject the following block — otherwise OMIT this entire section}

Project Standards (auto-resolved)

Project Standards (auto-resolved)

{paste matching compact rules blocks from the skill registry}
{paste matching compact rules blocks from the skill registry}

Review Criteria

审查标准

  • Correctness: Does the code do what it claims? Are there logical errors?
  • Edge cases: What inputs or states aren't handled?
  • Error handling: Are errors caught, propagated, and logged properly?
  • Performance: Any N+1 queries, inefficient loops, unnecessary allocations?
  • Security: Any injection risks, exposed secrets, improper auth checks?
  • Naming & conventions: Does it follow the project's established patterns AND the Project Standards above? {if user provided custom criteria, add here}
  • 正确性:代码是否实现了预期功能?是否存在逻辑错误?
  • 边缘情况:哪些输入或状态未被处理?
  • 错误处理:错误是否被捕获、传递并正确记录?
  • 性能:是否存在N+1查询、低效循环、不必要的内存分配?
  • 安全性:是否存在注入风险、泄露的密钥、不恰当的权限校验?
  • 命名与规范:是否遵循项目既定模式以及上述项目标准? {if user provided custom criteria, add here}

Return Format

返回格式

Return a structured list of findings ONLY. No praise, no approval.
Each finding:
  • Severity: CRITICAL | WARNING | SUGGESTION
  • File: path/to/file.ext (line N if applicable)
  • Description: What is wrong and why it matters
  • Suggested fix: one-line description of the fix (not code, just intent)
Always include at the end: Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}
If you find NO issues, return: VERDICT: CLEAN — No issues found.
仅返回结构化的问题列表。不得包含表扬、批准内容。
每个问题需包含:
  • 严重程度:CRITICAL | WARNING | SUGGESTION
  • 文件:path/to/file.ext(如有适用,标注行号N)
  • 描述:问题是什么以及为何重要
  • 建议修复方案:一行描述修复意图(无需代码,仅说明目的)
始终在末尾添加:Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}
如果未发现任何问题,返回: VERDICT: CLEAN — No issues found.

Instructions

说明

Be thorough and adversarial. Assume the code has bugs until proven otherwise. Your job is to find problems, NOT to approve. Do not summarize. Do not praise.
undefined
审查需全面且具有对抗性。在被证明无bug之前,假设代码存在问题。 你的任务是找出问题,而非批准。不得总结,不得表扬。
undefined

Fix Agent Prompt

修复Agent提示词

You are a surgical fix agent. You apply ONLY the confirmed issues listed below.
你是一名精准修复Agent。仅需修复以下列出的已确认问题。

Confirmed Issues to Fix

需修复的已确认问题

{paste the confirmed findings table from the verdict synthesis}
{if compact rules were resolved in Pattern 0, inject the following block — otherwise OMIT this entire section}
{paste the confirmed findings table from the verdict synthesis}
{if compact rules were resolved in Pattern 0, inject the following block — otherwise OMIT this entire section}

Project Standards (auto-resolved)

Project Standards (auto-resolved)

{paste matching compact rules blocks from the skill registry}
{paste matching compact rules blocks from the skill registry}

Context

上下文

  • Original review criteria: {paste same criteria used for judges}
  • Target: {same target description}
  • 原始审查标准:{粘贴用于审查Agent的相同标准}
  • 目标:{相同的目标描述}

Instructions

说明

  • Fix ONLY the confirmed issues listed above
  • Do NOT refactor beyond what is strictly needed to fix each issue
  • Do NOT change code that was not flagged
  • After each fix, note: file changed, line changed, what was done
Return a summary:
  • 仅修复上述列出的已确认问题
  • 不得进行超出修复问题严格所需的重构
  • 不得修改未被标记的代码
  • 每次修复后,记录:修改的文件、修改的行号、执行的操作
返回总结:

Fixes Applied

Fixes Applied

  • [file:line] — {what was fixed}
Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}

---
  • [file:line] — {修复内容}
Skill Resolution: {injected|fallback-registry|fallback-path|none} — {details}

---

Output Format

输出格式

markdown
undefined
markdown
undefined

Judgment Day — {target}

Judgment Day — {target}

Round {N} — Verdict

第{N}轮 — 结论

FindingJudge AJudge BSeverityStatus
Missing null check in auth.go:42CRITICALConfirmed
Race condition in worker.go:88WARNINGSuspect (A only)
Naming mismatch in handler.go:15SUGGESTIONSuspect (B only)
Error swallowed in db.go:201CRITICALConfirmed
Confirmed issues: 2 CRITICAL Suspect issues: 1 WARNING, 1 SUGGESTION Contradictions: none
问题描述审查Agent A审查Agent B严重程度状态
auth.go:42中缺少空值校验CRITICAL已确认
worker.go:88中存在竞态条件WARNING疑似(仅A发现)
handler.go:15中命名不匹配SUGGESTION疑似(仅B发现)
db.go:201中错误被吞掉CRITICAL已确认
已确认问题: 2个CRITICAL 疑似问题: 1个WARNING,1个SUGGESTION 分歧问题: 无

Fixes Applied (Round {N})

第{N}轮修复内容

  • auth.go:42
    — Added nil check before dereferencing user pointer
  • db.go:201
    — Propagated error instead of silently returning nil
  • auth.go:42
    — 添加空值校验后再解引用用户指针
  • db.go:201
    — 传递错误而非静默返回nil

Round {N+1} — Re-judgment

第{N+1}轮 — 重新审查

  • Judge A: PASS ✅ — No issues found
  • Judge B: PASS ✅ — No issues found

  • 审查Agent A:通过 ✅ — 未发现问题
  • 审查Agent B:通过 ✅ — 未发现问题

JUDGMENT: APPROVED ✅

结论:批准 ✅

Both judges pass clean. The target is cleared for merge.
undefined
两个审查Agent均通过审查。目标已通过,可进行合并。
undefined

Escalation Format (after 2 failed iterations)

升级处理格式(2次迭代失败后)

markdown
undefined
markdown
undefined

Judgment Day — {target}

Judgment Day — {target}

JUDGMENT: ESCALATED ⚠️

结论:升级处理 ⚠️

After 2 fix iterations, both judges still report issues. Manual review required before proceeding.
经过2次修复迭代后,两个审查Agent仍报告存在问题。 需人工审查后再继续。

Remaining Issues

剩余问题

FindingJudge AJudge BSeverity
{description}CRITICAL
问题描述审查Agent A审查Agent B严重程度
{描述}CRITICAL

History

历史记录

  • Round 1: {N} confirmed issues found
  • Fix 1: applied {list}
  • Round 2: {N} issues remain
  • Fix 2: applied {list}
  • Round 3: {N} issues remain → escalated
Recommend: human review of the remaining issues above before re-running judgment day.

---
  • 第1轮:发现{N}个已确认问题
  • 第1次修复:应用了{列表}
  • 第2轮:剩余{N}个问题
  • 第2次修复:应用了{列表}
  • 第3轮:剩余{N}个问题 → 升级处理
建议:在重新运行judgment day之前,对上述剩余问题进行人工审查。

---

Skill Resolution Feedback

技能解析反馈

After every delegation that returns a result, check the
**Skill Resolution**
field in each judge/fix-agent response:
  • injected
    → skills were passed correctly ✅
  • fallback-registry
    ,
    fallback-path
    , or
    none
    → skill cache was lost (likely compaction). Re-read the registry immediately and inject compact rules in all subsequent delegations.
This is a self-correction mechanism. Do NOT ignore fallback reports.

每次委托返回结果后,检查每个审查Agent/修复Agent响应中的
**Skill Resolution**
字段:
  • injected
    → 技能已正确传递 ✅
  • fallback-registry
    fallback-path
    none
    → 技能缓存丢失(可能是压缩导致)。立即重新读取注册表,并在所有后续委托中注入精简规则。
这是一种自我修正机制。请勿忽略备用方案报告。

Language

语言支持

  • Spanish input → Rioplatense: "Juicio iniciado", "Los jueces están trabajando en paralelo...", "Los jueces coinciden", "Juicio terminado — Aprobado", "Escalado — necesita revisión humana"
  • English input: "Judgment initiated", "Both judges are working in parallel...", "Both judges agree", "Judgment complete — Approved", "Escalated — requires human review"

  • 西班牙语输入 → 拉普拉塔西班牙语:"Juicio iniciado", "Los jueces están trabajando en paralelo...", "Los jueces coinciden", "Juicio terminado — Aprobado", "Escalado — necesita revisión humana"
  • 英语输入:"Judgment initiated", "Both judges are working in parallel...", "Both judges agree", "Judgment complete — Approved", "Escalated — requires human review"

Rules

规则

  • The orchestrator NEVER reviews code itself — it only launches judges, reads results, and synthesizes
  • Judges MUST be launched as
    delegate
    (async) so they run in parallel
  • The Fix Agent is a separate delegation — never use one of the judges as the fixer
  • If user provides custom review criteria, include them in BOTH judge prompts (identical)
  • If target scope is unclear, stop and ask before launching — partial reviews are useless
  • Max 2 fix iterations — on the third failure, escalate with full report, do not loop forever
  • Always wait for BOTH judges to complete before synthesizing — never accept a partial verdict
  • Suspect findings (only one judge) are reported but NOT automatically fixed — triage and escalate to user if needed

  • 编排者绝不能自行审查代码 —— 仅负责启动审查Agent、读取结果和综合结论
  • 审查Agent必须通过
    delegate
    启动(异步),以实现并行运行
  • 修复Agent是单独的委托 —— 绝不能将任一审查Agent用作修复者
  • 如果用户提供自定义审查标准,需将其添加到两个审查Agent的提示词中(完全相同)
  • 如果目标范围不明确,停止操作并询问用户后再启动 —— 部分审查毫无意义
  • 最多2次修复迭代 —— 第三次失败时,提交完整报告并升级处理,不得无限循环
  • 必须等待两个审查Agent都完成后再综合结论 —— 绝不能接受部分结论
  • 疑似问题(仅一个审查Agent发现)需报告但不得自动修复 —— 如需处理需分类后升级给用户

Commands

命令

bash
undefined
bash
undefined

No CLI commands — this is a pure orchestration protocol.

无CLI命令 —— 这是一个纯编排协议。

Execution happens via delegate() and delegation_read() tool calls.

通过delegate()和delegation_read()工具调用执行。

undefined
undefined