judgment-day
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseWhen 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 () before launching ANY sub-agent:
_shared/skill-resolver.md- Obtain the skill registry (engram → from the project root → skip if none)
.atl/skill-registry.md - Identify the target files/scope — what code will the judges review?
- Match relevant skills from the registry's Compact Rules by:
- Code context: file extensions/paths of the target (e.g., → react-19, typescript)
.tsx - Task context: "review code" → framework/language skills; "create PR" → branch-pr skill
- Code context: file extensions/paths of the target (e.g.,
- Build a block with the matching compact rules
## Project Standards (auto-resolved) - 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 to fix this.") and proceed with generic review only.
skill-registry在启动任何子Agent之前,请遵循Skill Resolver Protocol():
_shared/skill-resolver.md- 获取技能注册表(从项目根目录的engram → 获取→若无则跳过)
.atl/skill-registry.md - 确定目标文件/范围——审查Agent将审查哪些代码?
- 通过以下方式匹配注册表中精简规则的相关技能:
- 代码上下文:目标文件的扩展名/路径(例如→ react-19, typescript)
.tsx - 任务上下文:“review code”→框架/语言技能;“create PR”→branch-pr技能
- 代码上下文:目标文件的扩展名/路径(例如
- 构建包含匹配精简规则的区块
## Project Standards (auto-resolved) - 将此区块注入到两个审查Agent的提示语以及修复Agent的提示语中(所有提示语中的该区块完全相同)
这确保审查Agent依据项目特定标准进行审查,而非仅遵循通用最佳实践。
若不存在注册表:向用户发出警告(“未找到技能注册表——审查Agent将在无项目特定标准的情况下进行审查。运行命令解决此问题。”),然后仅进行通用审查。
skill-registryPattern 1: Parallel Blind Review
模式1:并行盲审
- Launch TWO sub-agents via (async, parallel — never sequential)
delegate - 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
- 通过启动两个子Agent(异步、并行——绝不能串行)
delegate - 每个Agent接收相同的目标但独立工作
- 两个Agent互不知情——不存在交叉干扰
- 两者使用相同的审查标准,但可能发现不同的问题
- 协调者绝不能自行进行审查——你的职责仅为协调
Pattern 2: Verdict Synthesis
模式2:结论综合
The orchestrator (NOT a sub-agent) compares results after both calls return:
delegation_readConfirmed → 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 decisionPresent findings as a structured verdict table (see Output Format).
协调者(而非子Agent)在两个调用均返回结果后对比审查结果:
delegation_readConfirmed → 两个Agent均发现的问题 → 高可信度,立即修复
Suspect A → 仅审查Agent A发现的问题 → 需要分类处理
Suspect B → 仅审查Agent B发现的问题 → 需要分类处理
Contradiction → 两个Agent对同一问题存在分歧 → 标记为需人工决策以结构化结论表格呈现审查结果(参见输出格式)。
Pattern 3: Fix and Re-judge
模式3:修复与重新审查
- If confirmed issues exist → delegate a Fix Agent (separate delegation)
- After Fix Agent completes → re-launch both judges in parallel (same blind protocol, fresh delegates)
- Max 2 fix iterations. If still failing → JUDGMENT: ESCALATED — report to user with full history
- If both judges return clean → JUDGMENT: APPROVED ✅
- 若存在已确认问题→委托修复Agent(单独委托)
- 修复Agent完成后→重新并行启动两个审查Agent(遵循相同盲审协议,使用新的委托实例)
- 最多2次修复迭代。若仍未通过→审查结论:升级处理——向用户提交完整历史记录
- 若两个审查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}
{若在模式0中解析出精简规则,则注入以下区块——否则省略整个此部分}
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查询、低效循环、不必要的内存分配?
- 安全性:是否存在注入风险、暴露的密钥、不恰当的权限检查?
- 命名与规范:是否遵循项目既定模式以及上述Project Standards? {若用户提供自定义审查标准,添加于此}
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。
你的任务是发现问题,而非批准代码。不得总结,不得表扬。
undefinedFix 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}
{若在模式0中解析出精简规则,则注入以下区块——否则省略整个此部分}
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}
- 原始审查标准:{paste same criteria used for judges}
- 目标:{same target description}
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
已应用的修复
- [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
undefinedmarkdown
undefinedJudgment Day — {target}
Judgment Day — {target}
Round {N} — Verdict
第{N}轮——审查结论
| Finding | Judge A | Judge B | Severity | Status |
|---|---|---|---|---|
| Missing null check in auth.go:42 | ✅ | ✅ | CRITICAL | Confirmed |
| Race condition in worker.go:88 | ✅ | ❌ | WARNING | Suspect (A only) |
| Naming mismatch in handler.go:15 | ❌ | ✅ | SUGGESTION | Suspect (B only) |
| Error swallowed in db.go:201 | ✅ | ✅ | CRITICAL | Confirmed |
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}轮已应用的修复
- — Added nil check before dereferencing user pointer
auth.go:42 - — Propagated error instead of silently returning nil
db.go:201
- — 解引用用户指针前添加空值检查
auth.go:42 - — 传播错误而非静默返回nil
db.go:201
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均通过审查。目标已获准合并。
undefinedEscalation Format (after 2 failed iterations)
升级处理格式(2次修复迭代失败后)
markdown
undefinedmarkdown
undefinedJudgment 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
剩余问题
| Finding | Judge A | Judge B | Severity |
|---|---|---|---|
| {description} | ✅ | ✅ | CRITICAL |
| 问题 | 审查Agent A | 审查Agent B | 严重程度 |
|---|---|---|---|
| {description} | ✅ | ✅ | 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:应用了{list}
- 第2轮:剩余{N}个问题
- 修复2:应用了{list}
- 第3轮:剩余{N}个问题 → 升级处理
建议:在重新启动judgment day之前,人工审查上述剩余问题。
---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 (async) so they run in parallel
delegate - 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
undefinedbash
undefinedNo CLI commands — this is a pure orchestration protocol.
无CLI命令——这是一个纯协调协议。
Execution happens via delegate() and delegation_read() tool calls.
通过delegate()和delegation_read()工具调用执行。
undefinedundefined