Agentic QA · Skill de workflow

/pr-review-lead

Revisa el PR de automatización de otra persona como lo haría un QA Lead: cada observación apunta a una línea del diff o de la doctrina, la nota de 0 a 10 está calibrada al rigor que elegiste, y en GitHub no se publica nada hasta que digas que sí.

Primero elegís el rigor Toda observación con su cita Publica solo con tu OK final

Deck de la skill pr-review-lead. Actúa como un QA Lead o QA Architect que le da feedback a un par: un mentor que leyó la doctrina que este código documenta, leyó el diff y puede señalar de dónde sale cada afirmación. Sirve para PRs de este repo y de repos externos que le indiques como owner/repo#PR. Pulsá → para avanzar, S para modo presentador, O para overview, F para pantalla completa.

Decidir · 2 de 14

Es el PR terminado de otra persona?

Usala para

Dar feedback sobre el PR de un colega, en este repo o en un repo externo (owner/repo#PR, vía gh).
Obtener una revisión con puntaje y con evidencia contra la doctrina KATA y de QA.
Cumplir el verificador separado del stage Automation antes del merge.

Se activa también con "revisa este PR", "review this PR", "actúa de QA lead" o "evalúa este PR contra KATA".

No es para esto: va a

Revisar tu propio diff sin commitear, antes de abrir el PR	el flujo de code review por defecto (/code-review si está instalado)
Un veredicto ciego APPROVED / ESCALATED de dos jueces	/judgment-day
Abrir el PR, mergearlo, resolver conflictos	/git-flow-master
Un PR que de verdad necesita proceso a nivel framework	/framework-development

Con /judgment-day se complementan: podés correr las dos sobre el mismo PR. Lo propio de esta es el rastro de evidencia y el modelo de severidad calibrado.

Tabla tomada de la sección "When to use this vs. a sibling skill" del SKILL.md. Si el PR necesita un proceso de framework, la skill lo dice y te señala /framework-development; no encadena skills SDD por su cuenta.

Pipeline · 3 de 14

El verificador obligatorio del stage Automation

Stage Automation, dueño test-automation

test-automation

Plan → Code → Review

spec.md · automation-plan.md
código KATA con @atc

→

git-flow-master

Abre el PR

test-automation nunca
corre git

→

verificador · requerido

/pr-review-lead
o /judgment-day

sobre el diff, en un
contexto limpio

→

la persona firma

El merge

nada se mergea
solo

Por qué acá y solo acá

Automation es el único stage cuya autonomía llega a 3. Más cuerda a la entrada se paga con un control más duro a la salida: es el único stage con verificador separado obligatorio.

Saltearlo no es un atajo

No es opcional ni solo para cambios de alto riesgo. Saltear el verificador es una falla del Definition of Done de Review. Contexto limpio quiere decir una sesión o subagente sin memoria de cómo se escribió el código.

Fuentes: la tabla de contrato y el checklist de Automation en agentic-qa-core/references/stage-gates.md, y la Fase 3 de test-automation/SKILL.md ("Required separate verifier"). Elegís la que mejor encaje con el cambio: judgment-day corre dos jueces ciegos y solo aprueba si coinciden; pr-review-lead hace una revisión estilo QA Lead apoyada en la doctrina KATA.

Mapa · 4 de 14

Leer primero, opinar después, publicar al final

Antes de leer el diff

Paso 0

Rigor y alcance

Flexible · Standard · Strict
qué PR, qué repo

→

Paso 1

Cargar la doctrina

la del repo objetivo
si tiene una propia

Análisis: nada sale de la sesión

Paso 2

Reunir el PR

diffs reales, por archivo
si el PR es grande

→

Paso 3

Analizar con evidencia

tres buckets
cuatro severidades

→

Paso 4

Checkpoint

tabla · puntos fuertes
nota de 0 a 10

→

Paso 5

Triage con vos

vos decidís qué va
y con qué peso

Lo único visible afuera, y solo con tu OK

Paso 6

Borrador

elogio → constructivo
→ elogio

→

Paso 7

Confirmar y publicar

gh pr comment
tras un sí explícito

Así se veía una sesión real de revisión en este repo: leer primero las convenciones del repo objetivo, leer los diffs reales, triar los hallazgos con el usuario antes de escribir nada, dejar que recalibre la severidad, redactar y no publicar hasta que diga "dale". Los recuadros amarillos son los puntos donde decidís vos.

Paso 0 · 5 de 14

Antes de una sola línea de diff: qué tan estricto?

Nivel	Qué reporta	Desvíos de patrón en la nota
Flexible	Solo lo evidentemente mal o lo que daña la confiabilidad: bugs reales, secretos hardcodeados, datos frágiles, cobertura sin justificar. Un patrón distinto al de libro que funciona no es hallazgo.	No se reportan, salvo que también sean un riesgo de confiabilidad.
Standard recomendado	La misma vara de defectos reales, más los desvíos de doctrina como observación liviana: "el patrón documentado hace X, este PR hace Y".	Cero: son informativos, nunca restan.
Strict	Pasada literal contra cada archivo de doctrina aplicable. Un desvío es hallazgo aunque funcione. Igual separa Real de Patrón.	Poco, y con tope: no pueden pesar como un defecto real.

Lo que ya dijiste no se re-pregunta

Si la invocación ya trae el rigor ("revisalo estricto", "sé flexible"), no vuelve a preguntar. En la misma ronda confirma el alcance: qué PR (repo y número, el PR de la rama actual o un diff suelto) y si es este repo o uno externo.

El nivel es un lente, no una licencia

Strict baja el umbral de qué vale la pena reportar. No baja la vara de prueba: cada hallazgo necesita la misma evidencia en los tres niveles.

Fuente: Paso 0 del SKILL.md y la tabla "Strictness levels" de references/severity-and-scoring.md. La pregunta se hace con el prompt del harness. Este paso no es opcional: corre en cada invocación.

Paso 1 · 6 de 14

Contra qué doctrina se mide este PR?

Leída fresca, cada vez

Nunca revisa contra convenciones que recuerda de otra sesión ni contra "buenas prácticas" que no verificó que estén documentadas. Leer primero, opinar después.

Se amplía según el PR

Si el PR trae un reporte de bug suma defect-management-doctrine.md; si toca una decisión de arquitectura de test difícil de revertir, adr-doctrine.md.

Fork que no trae una regla

Si al repo le falta un archivo esperable pero corre tests con forma KATA, lo dice: "califico contra la versión del boilerplate; avisá si preferís saltear ese chequeo".

Fuente: Paso 1 y Dependencies del SKILL.md, y references/evidence-and-doctrine-lookup.md, que trae los comandos gh api exactos para sondear el repo externo. Las carpetas con forma de este boilerplate son una señal fuerte, no una prueba: el fork puede haber divergido. El set por defecto completo: kata-architecture, typescript-patterns y review-checklists de test-automation, más test-design-doctrine y defect-management-doctrine de agentic-qa-core.

Paso 2 · 7 de 14

Lee el código, nunca la descripción del PR

De dónde saca el diff

PR de este repo	gh pr view y gh pr diff sobre el repo de trabajo.
PR externo	gh pr view <N> --repo <owner>/<repo> para metadatos y commits; los patches por archivo con el endpoint paginado pulls/<N>/files.
PR muy grande	Si gh pr diff falla con too_large, pagina los patches archivo por archivo. Nunca se rinde y hojea la descripción.

Separa trabajo de ruido

Mira primero los titulares de los commits. A veces casi todo el diff es un sync de template o un update de vendor sin relación: te lo avisa en vez de revisarlo línea por línea.

PR con muchos archivos

Reparte la lectura en subagentes en paralelo, un archivo o grupo por subagente, con el briefing de 7 componentes. Un PR chico se lee inline: no vale el costo del despacho.

Afirmación no es evidencia

"CI verde" o "30/30 en verde" en la descripción se anota como afirmación del autor, salvo que pueda señalar la corrida real.

Fuente: Paso 2 del SKILL.md, la tabla de Subagent Dispatch Strategy y la sección "Reading the PR itself for evidence" de references/evidence-and-doctrine-lookup.md. Una afirmación bien respaldada del autor puede ir a Positivos ("documentó un criterio de estabilidad concreto"), pero nunca se presenta como hallazgo propio.

Paso 3 · 8 de 14

Cada hallazgo responde: de dónde sale?

Una línea de código

La ubicación en el diff que muestra el defecto, con la línea citada o parafraseada de cerca. De un PR sin checkout local, tal como aparece en el diff.

Una línea de doctrina

El archivo y la sección (AGENTS.md §N, doctrina.md §Sección) con la oración exacta. Nunca un vago "por nuestras convenciones".

O una opinión, dicha así

"Esto es una opinión general de buenas prácticas de QA, no está en la documentación de este repo." No hay cuarta opción.

Y cae en exactamente un bucket

Real / Confiabilidad	Bugs, credenciales hardcodeadas, datos que se rompen en silencio, problemas de escala, huecos de cobertura sin justificar. Pesa en todos los niveles.
Patrón / Desvío de doctrina	Funciona, pero se aparta de una convención documentada. Es una comparación, no un veredicto. Su peso depende del Paso 0.
Positivo	Lo bien hecho, con la misma evidencia. Siempre tiene algo: una revisión sin positivos en un PR que los tiene está mal calibrada.

Severidad dentro de Real y Patrón: Crítico, Mayor, Menor, Trivial (en el idioma del usuario).

Fuente: Paso 3 del SKILL.md y "The rule" y "Citation format" de references/evidence-and-doctrine-lookup.md. Disfrazar una opinión de regla del repo erosiona la confianza en todas las demás citas apenas el usuario detecta una. Positivos típicos: buen pensamiento de riesgo más allá de los criterios de aceptación, datos de prueba idempotentes, afirmaciones de estabilidad con evidencia, honestidad del autor sobre sus tradeoffs.

Puntaje · 9 de 14

Una nota que se pueda defender

Arranca en 10 y resta

Crítico real	-1.5 a -2.5	según el radio de impacto
Mayor real	-0.5 a -1
Menor real	-0.1 a -0.3
Patrón	0	en Flexible y Standard
Patrón en Strict	-0.1 a -0.2	con tope: solos no hunden la nota

Los positivos no suman: no compensan un defecto. Se reportan aparte para que el feedback no sea solo una lista de problemas. Cada nota va con una línea de justificación atada a los buckets.

El ejemplo que fijó la regla

Una primera pasada marcó como Crítico un @atc llamado desde otro @atc, que la doctrina prohíbe (.agents/instructions/agent-code-quickref.md). El usuario frenó: funciona, no es un error. Recalibrado a Standard quedó como comparación de patrón: misma cita, peso cero.

Lo que no se aflojó

En el mismo PR, dos casos dependían de datos preexistentes de un staging compartido, sin sembrarlos ellos mismos. Riesgo real de rotura silenciosa: siguió siendo Mayor.

Fuente: "Scoring rubric" y "Worked example" de references/severity-and-scoring.md. El radio de impacto importa: un secreto hardcodeado en un repo demo público es menos riesgo real que el mismo patrón en un repo con datos de usuarios reales, y la skill lo dice y pondera en consecuencia. Un PR con cero defectos reales y diez detalles de patrón tiene que quedar claramente arriba de la mitad.

Pasos 4 y 5 · 10 de 14

Vos decidís qué se envía

El checkpoint, en el chat

| # | Severidad | Ubicación | Observación (evidencia) | |---|-----------|--------------------|-------------------------| | 1 | Crítico | config/variables.ts | fallback de password | | | | | hardcodeado · Regla #1 | | 2 | Mayor | (todo el PR) | 97% del diff es un sync | | | | | de template ajeno | Puntos fuertes: - <positivo con su evidencia> Score: X.X / 10 · <justificación en una línea>

Nada sale de la sesión todavía. Es un punto de control, no un entregable.

Cómo reacciona a tu pushback

"Solo críticos y mayores"	Re-acota lo que va al borrador. No re-analiza.
"Eso no es error, es patrón"	Lo reclasifica, recalcula la nota y te pregunta si la nueva te cierra.
"No seamos tan duros con los patrones"	Es un cambio de rigor: re-recorre todos los hallazgos de Patrón y re-presenta la tabla antes de redactar.

No defiende su primera clasificación. Tu contexto (las normas del equipo, lo que vale la pena levantar) manda sobre la severidad de la primera pasada.

Fuente: Pasos 4 y 5 del SKILL.md y references/output-and-posting-flow.md. Que el usuario re-trie es lo esperado, no una falla de la primera pasada. No redacta especulativamente antes de que confirmes qué hallazgos van y una nota con la que estés cómodo: un borrador que no pediste es un borrador que hay que rehacer.

Pasos 6 y 7 · 11 de 14

Un borrador sándwich y un sí explícito

La forma por defecto

## Feedback · PR #<N>: <título> <Elogio específico, con evidencia> **1. <Hallazgo> (<severidad>).** qué, dónde, por qué importa, fix **2. ...** <notas de patrón, como comparación> **Score: X.X / 10** <Cierre positivo, mirando adelante>

Una fortaleza real en cada punta, no un cumplido de relleno. El comentario va en inglés salvo que pidas otro idioma para ese artefacto.

Qué cuenta como OK

"Postealo", "dale", "sí, postea", dicho sobre este borrador. Un "se ve bien" en medio de la discusión de severidades no alcanza. El silencio tampoco. Ante la duda, muestra el borrador completo otra vez y pregunta.

Cómo publica

Guarda el borrador en un archivo de scratch y corre gh pr comment <N> --body-file, con --repo <owner>/<repo> si es externo. Te devuelve la URL del comentario como prueba de que existe.

Varios PRs a la vez

Un sí para un PR no vale para el de al lado. Si aprobás solo una parte del lote, publica exactamente esa parte y te dice qué quedó pendiente.

Fuente: Pasos 6 y 7 del SKILL.md y references/output-and-posting-flow.md. Un comentario publicado en un PR es visible para otros y no se deshace barato: pide la misma confirmación que cualquier otra acción visible desde afuera. Si ya estableciste otro tono o estructura, usa el tuyo.

Salvaguardas · 12 de 14

Lo que nunca hace

#	Regla
R1	Publicar un comentario sin la confirmación explícita del Paso 7. Sin excepciones.
R2	Presentar una "buena práctica" como regla del repo sin poder señalar el archivo y la sección.
R3	Tratar un desvío de patrón como error, o dejar que mueva la nota, en Flexible o Standard.
R4	Asumir que un repo externo copia las convenciones de este sin cargar antes su propia doctrina.
R5	Entregar una revisión sin positivos sobre un PR que claramente los tiene.
R6	Delegar a un subagente la redacción o la publicación: el tono y la acción visible quedan en la sesión principal.
R7	Encadenar skills SDD. Revisar un PR no es evolucionar el framework: si hace falta, te señala /framework-development.

Sin adivinar: cita, o dice que es opinión.

Sin dramatizar: el patrón se compara, no se condena.

Sin publicar solo: lo visible afuera espera tu sí.

Reglas tomadas de las secciones Rules y Compact Rules del SKILL.md. R6 viene de la estrategia de despacho: los pasos 6 y 7 tienen decisiones de tono frente al usuario y una acción visible afuera, y ninguna de las dos se delega.

Entradas y salidas · 13 de 14

Qué lee, qué deja

Lee

Sus propias referencias: severity-and-scoring.md, evidence-and-doctrine-lookup.md, output-and-posting-flow.md.
AGENTS.md, las secciones que su router nombra, y la doctrina de test-automation/references/ y agentic-qa-core/references/ que el PR toque.
La doctrina propia del repo objetivo, cuando la tiene.
El PR mismo vía gh: metadatos, commits, patches por archivo.

Deja

En el chat: la tabla de hallazgos, los puntos fuertes y la nota con su justificación.
En el chat: el borrador del feedback para que lo leas entero.
En GitHub, solo después de tu sí: un comentario en el PR, y su URL como prueba.
En el repo: nada. No edita el código que revisa.

Requiere agentic-qa-core. Cuando el PR es grande carga además briefing-template.md, dispatch-patterns.md y orchestration-doctrine.md para repartir la lectura.

Fuente: Dependencies y Paso 7 del SKILL.md. El borrador se guarda en un archivo de scratch solo para evitar problemas de escape en la shell al publicar. La doctrina se lee fresca en cada invocación, nunca de memoria de una sesión anterior.

Cierre · 14 de 14

Invocación y handoffs

Cómo se invoca

Claude Code: /pr-review-lead, idealmente con el PR y el rigor en el mismo mensaje: "revisá owner/repo#42, nivel Standard".
OpenCode y Codex: cargá la skill pr-review-lead y nombrá el PR.

No tiene modos. También se activa con "revisa este PR" o "review this PR".

Antes

/test-automation: escribe el código KATA y corre sus tres verificadores.
/git-flow-master: abre el PR que se revisa.

Al lado y después

/judgment-day: la otra opción de verificador, o una segunda opinión con otra forma.
El merge lo firma una persona.
/framework-development: si el PR pide proceso de framework.

Lo que te llevás

Una revisión de QA Lead con rastro de evidencia · una nota calibrada al rigor que elegiste · positivos reales, no de cortesía · un comentario publicado solo cuando dijiste que sí.

Canon: .agents/skills/pr-review-lead/SKILL.md y sus references/. Su lugar en el pipeline lo fija agentic-qa-core/references/stage-gates.md.

Fin del recorrido. El mapa del slide 4 resume todo: elegir el rigor, cargar la doctrina correcta, leer los diffs reales, citar cada hallazgo, mostrar el checkpoint, triar con vos, redactar y publicar solo con tu sí.