panel-de-revisión-de-artículos

¿Qué hace panel-de-revisión-de-artículos?

Versión: 1.0

Produce hasta tres archivos de revisión junto al borrador de una publicación técnica, cada uno escrito por una persona experta diferente: un experto en dominio (precisión de las afirmaciones técnicas), un editor (estructura, claridad, audiencia, adecuación a la plataforma) y un estadístico (si los datos respaldan las conclusiones). Cada archivo sigue la misma estructura de Bueno / Incorrecto / Necesita más explicación para que el autor pueda actuar sobre ella. La fuente de verdad son los datos brutos, scripts y notas en la carpeta del borrador, nunca el resumen que el propio borrador hace de ellos.

Reglas críticas (leer primero)

1. Lee toda la carpeta antes de escribir una palabra. El borrador, sus notas, borradores del primer comentario, publicaciones hermanas, scripts de referencia y archivos de resultados brutos. Una revisión que solo lee el borrador no puede detectar un borrador que cita incorrectamente sus datos.
2. Verifica cada número que el borrador mencione. Recalcúlalo a partir de los datos brutos o márcalo como no verificado. Cita el archivo y el valor: results_gc.json: 173 → 166 MB.
3. "Incorrecto" significa incorrecto, no una preferencia de estilo. Una afirmación sin evidencia en la carpeta, un número que contradice los datos, una conclusión que el análisis no respalda, o una frase que la plataforma mostrará incorrectamente. El gusto personal va en "Necesita más explicación".
4. Cada elemento "Incorrecto" lleva una solución concreta: redacción alternativa, el comando que probaría la afirmación, o la eliminación.
5. Cada lente se mantiene en su área. Haz referencia cruzada a los otros archivos ("la precisión técnica está en REVIEW-…-JVM.md") en lugar de repetir sus hallazgos.
6. Lente de estadística: analiza, no evalúes a ojo. Ejecuta scripts/paired_stats.py sobre los datos brutos. Nunca concluyas "ruido" o "sin efecto" sin un IC y una cifra del efecto mínimo detectable.
7. Respeta el presupuesto de longitud. Cuenta los caracteres del borrador frente al límite de la plataforma (LinkedIn: 3000) y di qué debe costar cada adición.
8. Señala la confidencialidad. Nombres internos, identificadores de tickets, hosts, datos de clientes o de producción: indica que necesitan aprobación de Comunicaciones/Legal. Nunca pongas datos restringidos (miembros, reclamaciones, salud, credenciales) en una revisión o una búsqueda.

Tabla de lectura previa

Fuente	Ruta	Qué extraer
El borrador	el archivo que el usuario nombre	Cada afirmación factual, cada número, cada comando, el gancho (primeros ~210 caracteres), el CTA, el conteo de caracteres
Notas del autor	*.md hermanos (notas de datos, primer comentario, publicaciones hermanas)	Las salvedades y correcciones propias del autor que el borrador omitió; texto repetido entre publicaciones hermanas
Scripts de referencia	*.py, *.sh, Dockerfiles en la carpeta	Orden de ejecución (aleatorizado? bloqueado?), qué mide realmente cada métrica y cuándo se muestrea
Resultados brutos	*.json, *.csv, *.log	Los números para recalcular; tamaño del bloque para emparejamiento
Guía del lente de dominio	references/domain-lens.md	La lista de verificación del dominio; la sección JVM es el dominio trabajado
Guía del lente editorial	references/editorial-lens.md	Reglas de la plataforma (markdown de LinkedIn, pliegue, límite) y lista de verificación de estructura
Guía del lente de estadística	references/statistics-lens.md	La receta de análisis y las banderas metodológicas estándar
Lecciones pasadas	~/.claude/skill-memory/article-review-panel.md (crearlo si falta)	Comentarios de ejecuciones anteriores; aplicarlos antes de redactar

Flujo de trabajo

Fase 1. Inventario

Enumera la carpeta. Lee el borrador y cada archivo de notas, script y resultados. Cuenta los caracteres del borrador. Construye una lista de afirmaciones: cada número y cada aserción factual, con su línea.

Fase 2. Elegir lentes

Por defecto, los tres. Ejecuta solo el lente que el usuario nombre ("actúa como estadístico"). Para el lente de dominio, toma el campo del usuario ("JVM", "Kubernetes", "Postgres") o infiérelo del borrador y di cuál elegiste.

Fase 3. Verificar

Recalcula cada afirmación a partir de los datos brutos. Para puntos de referencia, ejecuta:

python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> --list
python3 ${CLAUDE_SKILL_DIR}/scripts/paired_stats.py --file <results.json> \
  --block-size <variantes por ronda> --pair <A>:<B> [--pair ...] --metrics <m1,m2>

Busca en la carpeta evidencia de cada afirmación cualitativa ("no arranca", "ignorado silenciosamente"). Sin evidencia significa "Incorrecto: no probado", con el comando de prueba.

Fase 4. Escribir un archivo por lente

Escribe en la carpeta del borrador, nombrado REVIEW-<NOMBRE-BORRADOR>-<LENTE>.md con LENTE en JVM/<DOMINIO>, EDITORIAL, ESTADÍSTICA. Sigue el formato de salida a continuación y la guía del lente en references/.

Fase 5. Calificar e informar

Ejecuta evals.md mediante un subagente calificador con un contexto limpio (dale solo evals.md, el borrador y los archivos de revisión). Corrige cada fallo y vuelve a calificar. Luego informa al usuario: una línea por lente con el elemento "Incorrecto" principal y las rutas. Añade cualquier nueva lección que el usuario dé a ~/.claude/skill-memory/article-review-panel.md (la más nueva primero; créalo si falta).

Formato de salida

# Revisión de <archivo del borrador>: <nombre del lente>

Visión del revisor: <persona>. <Qué se comprobó contra qué.>

## Veredicto

<2–4 frases: publicable o no, lo más sólido, el recuento de correcciones obligatorias.>

## Bueno

- **<Afirmación destacada>.** <Evidencia, con archivo y número.>

## Incorrecto: <debe corregirse antes de publicar | las conclusiones no se derivan de los datos>

### 1. <Declaración del defecto en una línea>

<Qué dice el borrador, qué dicen los datos, por qué importa.>

Sugerencia de corrección: <redacción, comando o eliminación>.

## Necesita más explicación

### N. <Tema>

<Qué falta y una línea sugerida.>

## Puntos menores

- **<Etiqueta>:** <una o dos frases>.

El archivo de estadística añade una sección Cómo se realizó el análisis después del encabezado y una lista de Re-ejecuciones recomendadas al final.

Ejemplo resuelto

Entrada:

actúa como un ingeniero JVM experimentado y revisa POST-1-DEFAULT-CDS-EN.md en ~/aot-exploration/linkedin-cds, luego como editor, luego como estadístico

Pasos que sigue Claude:

1. Lee la publicación, DADOS-POST.md, el borrador del primer comentario, la publicación 2, bench*.py y results*.json. Cuenta 2623 de 3000 caracteres.
2. Lente de dominio: confirma que ZGC mapea classes_nocoops.jsa; no encuentra ningún archivo que mencione AOTCache, por lo que la afirmación "la JVM ni siquiera arranca" se marca como Incorrecta con un comando de prueba.
3. Lente editorial: el gancho de 87 caracteres cabe arriba del pliegue; cuatro comandos entre comillas invertidas se renderizarán literalmente en LinkedIn (Incorrecto).
4. Lente de estadística: ve random.shuffle(order) dentro del bucle de rondas, por lo que ejecuta paired_stats.py --block-size 12. El cambio agrupado es −2.1% [−3.2%, −1.5%], por lo que "eso es ruido" es Incorrecto. El "+2%" provino de comparar medianas no emparejadas.
5. Escribe tres archivos REVIEW-POST-1-*.md, los califica con evals.md, informa.

Salida (archivo de estadística, extracto):

### 1. "Tiempo de arranque: −4% a +2%. Eso es ruido." no es lo que dicen los datos

| Configuración | Cambio emparejado | IC 95% | Más rápido con CDS | p exacta |
|---|---|---|---|---|
| Serial | −69 ms | [−104, −49] | **10/10** | **0.002** |
| **Agrupado, 50 pares** | **−2.1%** | **[−3.2%, −1.5%]** | **39/50** | n/a |

La conclusión correcta es "un efecto real pero pequeño: aproximadamente el 2%, o 20–70 ms",
no "ruido".

La salida completa de los tres archivos de esta ejecución se resume en references/examples.md.

Archivos de referencia

• references/domain-lens.md: lista de verificación del experto en dominio; dominio trabajado de JVM/CDS/AOT.
• references/editorial-lens.md: lista de verificación del editor y reglas de la plataforma LinkedIn.
• references/statistics-lens.md: receta de análisis y banderas metodológicas estándar.
• references/examples.md: la ejecución de la publicación CDS, hallazgo por hallazgo.
• evals.md: comprobaciones de aprobado/fallo. Ejecutar mediante un calificador con contexto limpio antes de entregar.
• ~/.claude/skill-memory/article-review-panel.md: registro de lecciones, la más nueva primero, privado de esta máquina (ver memory.md). Leer antes de redactar.

Scripts

• scripts/paired_stats.py: análisis emparejado A/B solo con la biblioteca estándar (Wilcoxon exacto, cambio de signo, Hodges-Lehmann, IC bootstrap, MDE, cambio agrupado, comprobaciones de deriva y orden). --list muestra variantes y métricas; --self-test ejecuta 8 comprobaciones.

Cuándo NO usar esta habilidad

• Revisar código, una rama o un PR. Usa diegourban:gh-pr-review, diegourban:branch-review o /code-review.
• Verificar el comportamiento real de una base de código. Usa diegourban:fact-checker.
• Escribir o reescribir la publicación en sí. Mantén una conversación directa; esta habilidad solo revisa.
• Una presentación o diapositivas. Revisa el contenido con esta habilidad solo si el usuario lo solicita; crea con create-slide-deck.