Agentic QA · Skill de revisión

/judgment-day

Dos jueces revisan el mismo cambio en paralelo, sin ver lo que encontró el otro. Lo que señalan los dos se arregla y se vuelve a juzgar; el veredicto final es APPROVED o ESCALATED, nunca "más o menos".

Solo con disparo explícito Dos jueces ciegos en paralelo T2 vendorizada · Apache-2.0

Deck de la skill judgment-day. La idea central: la ceguera de los jueces es todo el valor. Si un juez ve el veredicto del otro, dos revisiones colapsan en una. Pulsá → para avanzar, S para modo presentador, O para overview, F para pantalla completa.

Cuándo usarla · 2 de 13

Un veredicto binario sobre algo concreto

Lo que querés	Con qué
Un veredicto ciego APPROVED / ESCALATED sobre un diff, una feature, un PR o una porción de arquitectura	/judgment-day
Feedback sobre el PR de un colega, con severidad calibrada y cada hallazgo citando doctrina	/pr-review-lead
Revisar tus propios cambios sin commitear antes de abrir el PR	el flujo de code review por defecto (/code-review si está instalado)
Un typo, un cambio de formato o un archivo autogenerado	nada: dos jueces, síntesis y re-juicio cuestan más de lo que vale el veredicto
Un diff de más de 30 archivos	partirlo en revisiones por área y sintetizar a mano: pasado ese tamaño la señal se degrada

Objetivo poco claro

Si no está claro qué se juzga, la skill pregunta el alcance y no lanza a ningún juez. Archivos, feature, PR o porción de arquitectura: algo que se pueda nombrar.

Nunca automática

Se carga solo cuando la pedís: "judgment day", "dual review", "adversarial review", "juzgar", "que lo juzguen".

Filas 2 y 3 salen de la tabla "When to use this vs. a sibling skill" de pr-review-lead. Filas 4 y 5 son los anti-patrones J5 y J3 del SKILL.md de judgment-day. El disparo explícito es el Activation Contract.

Origen · 3 de 13

Una skill vendorizada, con su licencia

Frontmatter del SKILL.md (extracto)

name: judgment-day license: Apache-2.0 complementary_categories: [meta-skill] metadata: kind: workflow author: gentleman-programming vendored_from: "https://github.com/ Gentleman-Programming/gentle-ai"

Tier T2: vendorizada

Copiada desde gentle-ai y commiteada en .agents/skills/judgment-day/. La licencia y la atribución viajan en el frontmatter; metadata.vendored_from apunta al upstream.

Sin dependencia del upstream

El instalador no corre gentle-ai: conecta Engram con engram setup. Esta skill tampoco necesita gentle-ai: ya está en el repo.

Dos etiquetas, dos preguntas

El tier dice de dónde viene (T2). El kind dice qué hace (workflow). Una no implica la otra.

Fuentes: frontmatter de .agents/skills/judgment-day/SKILL.md; agentic-qa-core/references/skill-composition-strategy.md (tier T2, "No upstream dependency", las tres etiquetas independientes); .agents/instructions/agent-skills-and-mcps.md (Memory install scope). La versión upstream también está en el frontmatter; no la copiamos acá porque cambia.

Mapa · 4 de 13

Juzgar, sintetizar, arreglar y volver a juzgar

Los seis pasos de "Execution Steps" del SKILL.md; el séptimo es una verificación: antes de cualquier acción terminal, toda Judgment Day activa tiene que tener estado terminal. Los únicos estados terminales son APPROVED y ESCALATED.

Pasos 1 y 2 · 5 de 13

Los jueces puntúan contra este repo

Qué se lee, en este orden

El diff, archivos, PR o porción que nombraste: el objetivo literal.
AGENTS.md: convenciones y Critical Rules, no "buenas prácticas" genéricas.
.agents/skills/REGISTRY.md: qué skills del repo aplican a esos archivos.
La intención declarada: spec, descripción del PR o ticket.
references/prompts-and-formats.md: prompts y formatos.
Desde la ronda 2: lo que dijeron los jueces antes.

Un solo bloque de skills

Del registro sale un bloque Skills to load before work. Va idéntico al prompt de cada juez y al del agente de fix.

Se juzga la intención declarada

Los jueces comparan contra lo que el cambio dice querer hacer, no contra lo que ellos imaginan que debería hacer.

Sin registro

Avisa, sigue con criterios genéricos y lo deja escrito: Skill Resolution: none.

Orden de lectura: sección "Inputs" del SKILL.md, que permite cortar antes cuando el objetivo es chico. La resolución de skills es la primera Hard Rule. Cada respuesta de juez y de fix termina con una línea Skill Resolution: paths-injected, fallback-registry, fallback-path o none.

Paso 3 · Juzgar · 6 de 13

Dos jueces, un mismo brief

Lo que recibe cada juez

"Sos un revisor adversarial. Tu único trabajo es encontrar problemas." Mismo objetivo, mismo bloque de skills y estos criterios:

Correctness: errores lógicos, comportamiento que no coincide
Edge cases: estados, entradas o límites de plataforma que faltan
Error handling: propagación, logging, recuperación
Performance: N+1, loops de más, asignaciones excesivas
Security: inyección, secretos, límites de autenticación
Naming/conventions: los estándares del proyecto

Más los criterios propios que hayas pedido.

Lo que devuelve

Solo hallazgos, sin elogios. Cada uno con severidad, archivo (y línea), qué está mal y por qué importa, y el fix en una línea. Si no hay nada: VERDICT: CLEAN.

El orquestador no revisa

La sesión que coordina nunca revisa el código ella misma. Lanza a los dos jueces a la vez, por delegación, y espera a ambos: un veredicto parcial no se acepta.

Ciegos de verdad

Un brief distinto por juez produce veredictos distintos que parecen desacuerdo real y son un artefacto del brief.

El prompt completo está en references/prompts-and-formats.md, "Judge Prompt". Hard rules: lanzar dos jueces ciegos en paralelo, nunca revisar el código uno mismo, esperar a ambos antes de sintetizar. Anti-patrones J1 (nunca mostrar un veredicto al otro juez) y J6 (nunca prompts, criterios o contexto distintos).

Paso 3 · Juzgar · 7 de 13

Cuatro severidades y una regla que las separa

CRITICAL

Un problema que bloquea. Si los dos jueces lo encuentran, está confirmado y hay que resolverlo para aprobar.

WARNING (real)

El uso normal y previsto puede dispararlo. Confirmado, también bloquea la aprobación.

WARNING (theoretical)

Solo se dispara por un camino forzado, malicioso o imposible. Baja a INFO: se reporta, no bloquea.

SUGGESTION

Una mejora posible. Puede quedar pendiente sin impedir el veredicto.

Criterio de aprobación desde la ronda 1

Cero CRITICAL confirmados y cero WARNING (real) confirmados. Las advertencias teóricas y las sugerencias pueden quedar.

La regla real vs teórica es una Hard Rule y también está en el prompt de cada juez. La distinción importa porque decide qué bloquea: un hallazgo teórico tratado como real dispara un ciclo de fix que no hacía falta.

Paso 4 · Sintetizar · 8 de 13

Qué pasa cuando los jueces coinciden o no

Situación	Qué hace la skill
Los dos encuentran el mismo CRITICAL o WARNING real	Confirmado. Se pregunta o se arregla según la ronda.
Lo encuentra un solo juez	Sospechoso. Se reporta y se clasifica; nunca se arregla solo.
Los jueces se contradicen	Escala a una decisión manual tuya.
Ronda 2 o más, solo advertencias teóricas o sugerencias	Se reportan como INFO; no se vuelve a juzgar.

La tabla de veredicto (formato)

Hallazgo	Juez A	Juez B	Severidad	Estado
Falta un null check en el handler	✅	✅	CRITICAL	Confirmado
Caso borde de un volumen raíz en Windows	❌	✅	WARNING (theoretical)	INFO
Un nombre que no sigue la convención	✅	❌	SUGGESTION	Sospechoso

Tabla de "Decision Gates" del SKILL.md y la "Verdict Table" de references/prompts-and-formats.md, con los ejemplos traducidos. Si la síntesis descarta el rechazo de un juez, tiene que escribir por qué (anti-patrón J4): un descarte silencioso borra la pista de auditoría.

Pasos 5 y 6 · Arreglar · 9 de 13

Un fix sin re-juicio no cuenta

Ronda 1

Te pregunta

antes de arreglar lo confirmado

→

Fix

Agente aparte

solo los hallazgos que aprobaste

→

En seguida

Re-juicio en paralelo

A y B, antes de commit, push o cierre

→

2 iteraciones

Te pregunta otra vez

si quedan problemas: seguimos?

Lo que tiene permitido el agente de fix

Arreglar solo los issues confirmados.
Nada de refactor más allá del fix; código no señalado, intacto.
Si el mismo patrón se repite en los archivos que toca, lo arregla en todas sus apariciones.
Devuelve archivo, línea y resumen de cada fix.

Por qué re-juzgar siempre

Un fix puede romper otra cosa. Solo un veredicto doble, nuevo, confirma que el cambio quedó limpio.

Cómo termina

Solo en JUDGMENT: APPROVED o JUDGMENT: ESCALATED, o cuando vos pedís parar.

Hard rules: preguntar antes de los fixes de la ronda 1; relanzar a los dos jueces en paralelo inmediatamente después de cualquier fix y antes de commit, push, cierre o session summary; después de 2 iteraciones de fix con problemas pendientes, preguntar si continuar. Instrucciones del agente: "Fix Agent Prompt" en references/prompts-and-formats.md. Anti-patrón J2: nunca saltear el re-juicio.

Salida · 10 de 13

Un informe con veredicto final

Forma del informe (esquema)

## Judgment Day · {objetivo} Ronda: {n} | Hallazgo | Juez A | Juez B | Severidad | Estado | | ... | ✅ | ✅ | CRITICAL | Confirmado | Confirmados: {n} · Sospechosos: {n} Contradicciones: {n} Fixes aplicados: {resumen} Re-juicio: {resultado} Skill Resolution: {modo} · {detalle} JUDGMENT: APPROVED ✅ o JUDGMENT: ESCALATED ⚠️

Qué te dice

En qué ronda terminó, qué encontró cada juez, cuánto quedó confirmado, sospechoso o en contradicción, qué se arregló y qué dijo el re-juicio.

En español

"Juicio iniciado" · "Los jueces trabajan en paralelo" · "Los jueces coinciden" · "Juicio terminado, aprobado" · "Escalado, necesita revisión humana".

Nada queda abierto

Antes de cualquier acción terminal, toda Judgment Day activa tiene que tener uno de los dos estados finales.

"Output Contract" del SKILL.md y "Language Snippets" de references/prompts-and-formats.md. El esquema usa placeholders entre llaves: no es la salida de una revisión real.

En el pipeline · 11 de 13

Otras skills la citan

Skill anfitriona	Cuándo	Obligatoria?
/test-automation	Fase 3 Review del stage Automation, antes del merge, sobre el diff y en contexto limpio	Un verificador separado es requerido: /pr-review-lead o /judgment-day, el que mejor encaje. Saltarlo es una falla del DoD.
/git-flow-master	Antes del PR, si el diff pasa las 400 líneas o toca scaffolding compartido (bases KATA, fixtures, schemas OpenAPI)	Opcional: la skill te lo ofrece y vos decidís
/shift-left-testing	El refinamiento va a una Story de alto riesgo	Opcional, nunca auto-invocada
Cambio de compact rule de una skill	Es un cambio de briefing para cada subagente	Gate opcional (skill-refinement-protocol.md)

Con /pr-review-lead se complementan

Nada impide correr /judgment-day sobre el mismo PR después, por una segunda opinión con otra forma. /pr-review-lead aporta las citas de doctrina y la severidad calibrada; esta skill, el veredicto ciego y doble.

Por qué Automation lo exige

Es el único stage con un verificador separado obligatorio. Más cuerda a la entrada se paga con un control más duro a la salida.

Fuentes: test-automation/SKILL.md, Phase 3 "Required separate verifier"; agentic-qa-core/references/stage-gates.md (Automation: verificador "required"); git-flow-master/SKILL.md, "Optional pre-PR adversarial gate"; shift-left-testing/SKILL.md, tabla de skills relacionadas; agentic-qa-core/references/skill-refinement-protocol.md; pr-review-lead/SKILL.md, "When to use this vs. a sibling skill". Decks hermanos: ../test-automation/how-it-works.es.html y ../git-flow-master/how-it-works.es.html.

Salvaguardas · 12 de 13

Lo que la skill nunca hace

Regla	Por qué
Mostrarle a un juez el veredicto del otro antes de la síntesis	la revisión ciega es todo el valor; contaminada, dos jueces valen por uno
Darles prompts, criterios o contexto distintos	un brief asimétrico fabrica un desacuerdo que no existe
Saltear el re-juicio después de un fix	un fix puede romper otra cosa; solo un veredicto doble nuevo lo descarta
Descartar el rechazo de un juez sin escribir por qué	el próximo revisor no puede saber si se analizó o se perdió
Juzgar más de 30 archivos en una pasada	la señal se degrada; se parte por área
Juzgar un typo, un formato o un diff autogenerado	la orquestación cuesta más que el veredicto
Arreglar algo sin preguntar en la ronda 1, o arreglar un sospechoso	solo lo confirmado y aprobado por vos pasa al agente de fix
Arrancar sola	se carga con disparo explícito o cuando la cita una skill anfitriona

Anti-patrones J1 a J6 del SKILL.md, más las Hard Rules (preguntar antes de los fixes de la ronda 1) y la tabla de Decision Gates (un sospechoso no se arregla solo). La carga solo por disparo o cita está en el Activation Contract y en skill-composition-strategy.md (fila T2).

Cierre · 13 de 13

Invocación y dónde leer más

Cómo se invoca

Claude Code: /judgment-day más el objetivo.
OpenCode y Codex: cargá la skill judgment-day y nombrá el objetivo.

En los tres hosts la disparan "judgment day", "dual review", "adversarial review" o "juzgar". No tiene modos.

Qué lee

El objetivo que nombraste · AGENTS.md · .agents/skills/REGISTRY.md · la intención del cambio (spec, PR, ticket) · los veredictos de rondas anteriores.

Qué deja

El informe ## Judgment Day en el chat con su veredicto final · los fixes aprobados aplicados en tu árbol de trabajo, ya re-juzgados.

Canon

.agents/skills/judgment-day/SKILL.md (contrato, reglas, gates, anti-patrones) y references/prompts-and-formats.md (prompts de juez y de fix, regla de severidad, tabla de veredicto). Upstream: gentle-ai, Apache-2.0.

Relacionadas: /test-automation la exige como verificador (o /pr-review-lead, la otra opción) ·/git-flow-master la ofrece antes del PR · /shift-left-testing la sugiere para Stories de alto riesgo.

Fin del recorrido. El mapa del slide 4 lo resume: dos jueces ciegos, una síntesis que separa lo confirmado de lo sospechoso, fixes solo con tu OK y siempre un re-juicio. La skill no tiene "## Mode routing": se invoca por nombre más el objetivo.