MarcoGarcian/preregister

/preregister — Generador de Documentos de Prerregistro

Produce un documento de prerregistro listo para ser enviado a un registro. El usuario lo sube a un registro real (OSF / AsPredicted / AEA RCT Registry) — este skill redacta el texto y la estructura, no envía nada a ningún sitio.

Por qué prerregistrar

El prerregistro es un compromiso por escrito con tus hipótesis, diseño y plan de análisis antes de ver los datos (o, para análisis observacionales, antes de analizar el resultado obtenido). Separa las pruebas confirmatorias de las exploratorias y te protege contra p-hacking, HARKing y caminos de bifurcación. Diferentes campos usan diferentes registros:

• Ciencias políticas, psicología, ciencias sociales en general → OSF (osf.io/registries) es el predeterminado. AsPredicted (aspredicted.org) es un formulario corto popular para experimentos.
• Experimentos de campo en economía → AEA RCT Registry (socialscienceregistry.org) es obligatorio para el envío a revistas AEA desde 2018.
• Salud pública / ensayos clínicos → ClinicalTrials.gov o ISRCTN (NO cubiertos por este skill — usa la plantilla propia del registro de ensayos).

Cuándo usarlo

• Antes de lanzar un experimento (de laboratorio, campo o encuesta).
• Antes de recopilar datos observacionales sobre una población objetivo para una pregunta de investigación específica.
• Antes de analizar datos a los que tienes acceso pero que aún no has examinado para la hipótesis principal.
• Durante revisión y réplica (R&R) cuando un revisor solicita un plan de preanálisis por escrito.

Cuándo NO usarlo

• Después de haber visto los resultados obtenidos y quieres "prerregistrar retrospectivamente" — eso no es prerregistro. El skill se negará si la descripción de entrada incluye resultados.
• Para análisis exploratorios — esos no necesitan prerregistro; necesitan un etiquetado transparente.
• Para metaanálisis — usa PROSPERO directamente, no esta plantilla.

Flujo de trabajo

FASE 1 — Leer las entradas

Dos modos de entrada:

1. --input <ruta> — una especificación de investigación producida por /interview-me (guardada en quality_reports/specs/) o cualquier archivo Markdown estructurado. Lee la especificación y extrae: pregunta de investigación, hipótesis (¡direccionales!), fuente de datos, diseño, muestra, enfoque de análisis. Si la especificación registra un tipo de artículo (/interview-me lo escribe en una línea **Paper type:**, p. ej. survey-experiment), úsalo para sesgar la elección de estilo.
2. Sin --input — pide al usuario una descripción de 1 a 3 párrafos del estudio, luego continúa. Si la descripción omite una hipótesis direccional, pregunta una vez. No fabriques.

Condiciones de rechazo (deben verificarse antes de cualquier redacción):

• La descripción contiene resultados obtenidos ("encontramos", "la estimación es", "p =") → rechazar con: "El prerregistro es prospectivo; esta descripción incluye resultados. ¿Querías decir /respond-to-referees o redactar una sección de métodos?"
• La descripción no tiene ninguna hipótesis comprobable (marco puramente exploratorio) → señalarlo y preguntar si el usuario quiere la versión de análisis exploratorio de la plantilla OSF (aún útil, pero no es una prueba confirmatoria registrada).

FASE 2 — Elegir el estilo

Valor predeterminado por campo (se usa cuando no se proporciona --style):

Señal de campo	Estilo predeterminado
**Paper type:** survey-experiment o contexto de ciencias políticas / psicología	osf
Experimento de campo en economía / etiquetado "RCT" / intervención aleatorizada aprobada por IRB	aea-rct
Solicitud de formulario rápido de 9 preguntas, experimento psicológico de laboratorio, presión de tiempo	aspredicted
Cualquier otra cosa	osf

El usuario puede anular con --style osf|aspredicted|aea-rct.

FASE 3 — Generar el documento

Lee templates/preregistration-template.md. La plantilla tiene tres secciones de estilo; usa solo la sección que coincida con el estilo elegido (no las combines — los registros difieren).

Común a todos los estilos, el documento DEBE incluir:

• Título y autores.
• Fecha y versión.
• Referencia a la especificación fuente (si se proporcionó --input) para que la trazabilidad permanezca.

Secciones específicas de cada estilo:

• osf — Hipótesis (direccionales, numeradas) · Diseño · Plan de Muestreo · Variables · Plan de Análisis · Criterios de Inferencia · Exclusiones de Datos · Manejo de Datos Faltantes · Análisis Exploratorios (claramente etiquetados como tales) · Otros.
• aspredicted — 9 campos numerados según el formulario de AsPredicted: (1) estado de recopilación de datos, (2) hipótesis, (3) variable dependiente clave, (4) condiciones, (5) análisis, (6) valores atípicos/exclusiones, (7) tamaño de muestra + regla de parada, (8) cualquier otra cosa, (9) nombre (estudio no artículo).
• aea-rct — Intervención · Resultados (primarios, secundarios) · Hipótesis primarias · Muestra (N objetivo, elegibilidad, unidad de aleatorización, método de aleatorización) · Aprobación IRB · Fechas del ensayo · Cálculo de potencia · Adjunto del plan de preanálisis · Estado (aún no en marcha / en curso / completado).

Anota cada sección con uno de:

• DEBE — el registro lo requiere; el documento no se puede enviar sin ello.
• DEBERÍA — muy recomendado; los revisores lo esperan.
• PUEDE — opcional; incluir si es relevante.

Reutiliza el marco DEBE/DEBERÍA/PUEDE de templates/requirements-spec.md. Para cada DEBE que la entrada no haya proporcionado, escribe [CLARIFY: <pregunta específica>] en lugar de inventar contenido.

FASE 4 — Verificaciones cruzadas (antes de escribir en disco)

Rechazar marcar el documento como "listo" si falla alguna de estas:

• Direccionalidad de la hipótesis. Cada hipótesis debe contener una dirección ("mayor que", "aumenta", "predice negativamente", "sin efecto" es aceptable como afirmación direccional bajo pruebas de equivalencia). Rechazar "está asociado con" sin un signo.
• Estimador nombrado. El plan de análisis nombra un estimador específico (MCO, logit, fixest::feols, lme4::lmer, ATT diferencia de medias …) y una variable de resultado primaria. Solo "Regresión" es insuficiente.
• Plan de muestra numérico. Aparecen N objetivo, regla de parada o objetivo de cálculo de potencia. "El máximo posible" no es un plan de muestra. Para RCTs y diseños prospectivos, sigue la SKILL.md de /power-analysis (léela — el skill solo se invoca por el usuario, por lo que no se puede llamar desde aquí) para producir el MDE / N requerido y un párrafo de potencia listo para pegar en este campo.
• Exclusiones ex ante. Las reglas de valores atípicos y exclusión se declaran antes de ver los datos ("excluiremos observaciones con tiempo de finalización < 1 minuto"). "Ya nos ocuparemos de los valores atípicos" es insuficiente.
• Consistencia interna. Si el diseño es aleatorizado, la unidad de aleatorización coincide con la unidad de análisis O el plan de análisis aborda el agrupamiento. Si es observacional, se declara la estrategia de identificación.

Para cada fallo, el documento recibe un marcador de posición [CLARIFY: …]; el documento se escribe en disco pero se marca en el resumen de salida como "INCOMPLETO — N elementos DEBE sin resolver".

FASE 5 — Verificación posterior al vuelo

Si el documento cita literatura previa en la sección de fundamentos (p. ej., "Basándonos en Hainmueller et al. 2014, esperamos …"), invoca /verify-claims a través de la herramienta Agent para verificar esas citas. Pasa la ruta del borrador y una lista de citas explícitas. El agente claim-verifier (contexto nuevo, nunca ve el borrador) devuelve PASÓ / PARCIAL / FALLÓ por cada cita. Muestra cualquier FALLÓ/PARCIAL en el resumen de salida.

Saltar la verificación posterior al vuelo si:

• No hay citas de literatura previa en el documento.
• El usuario pasa --no-verify (bandera heredada de la verificación posterior al vuelo de /lit-review y /research-ideation).

FASE 6 — Salida

Escribir en quality_reports/preregistrations/YYYY-MM-DD_<slug>.md (en gitignore — el prerregistro debe tener marca de tiempo y cargarse externamente, no confirmarse junto con el código).

Imprimir en el chat:

✓ Borrador de prerregistro guardado: quality_reports/preregistrations/<archivo>.md
  Estilo: <osf|aspredicted|aea-rct>
  Secciones: <total> en total — <completas> completas, <clarify> con marcadores [CLARIFY:]
  Citas verificadas: <PASÓ>/<PARCIAL>/<FALLÓ>  (o "sin citas para verificar")
  Siguiente: revisa los marcadores [CLARIFY:], complétalos, luego súbelo a <url-del-registro>

Incluir la URL del registro: OSF → osf.io/registries, AsPredicted → aspredicted.org, AEA RCT → socialscienceregistry.org.

Referencias cruzadas

• templates/preregistration-template.md — las tres plantillas de estilo que consume este skill.
• templates/requirements-spec.md — lenguaje de anotación DEBE/DEBERÍA/PUEDE reutilizado aquí.
• .claude/skills/interview-me/SKILL.md — produce la especificación que consume este skill vía --input.
• .claude/skills/power-analysis/SKILL.md — se sigue (no se invoca) para proporcionar el MDE / N requerido + párrafo de potencia para el campo del plan de muestra (RCTs).
• .claude/skills/verify-claims/SKILL.md — La Fase 5 lo invoca para la verificación posterior al vuelo de citas.
• .claude/references/discipline-cards.md — valores predeterminados de campo que impulsan la selección de --style.
• .claude/rules/replication-protocol.md — el prerregistro es el compromiso hacia adelante; el protocolo de replicación es el contrato hacia atrás.

Ejemplos

Ejemplo 1 — Experimento de encuesta en ciencias políticas a partir de una especificación

El usuario dice: "Prerregistra este estudio" (con --input quality_reports/specs/2026-04-15_priming-effects.md) Acciones:

1. Leer la especificación; **Paper type:** survey-experiment → estilo predeterminado osf.
2. Extraer 2 hipótesis direccionales, MTurk N=1.200, MCO con dummies de tratamiento.
3. Generar documento OSF, todas las secciones DEBE completas, 1 PUEDE dejada en blanco.
4. Sin citas de literatura previa más allá de la especificación — saltar verificación posterior al vuelo. Resultado: Guardado en quality_reports/preregistrations/2026-04-15_priming-effects.md. El usuario lo sube a OSF.

Ejemplo 2 — Experimento de campo en economía, AEA RCT Registry

El usuario dice: "Redacta un prerregistro AEA RCT para el piloto de transferencia de efectivo" (con --style aea-rct --input quality_reports/specs/2026-03-10_ct-pilot.md) Acciones:

1. Leer la especificación; unidad de aleatorización = aldea, resultado primario = consumo.
2. Generar campos AEA RCT. Número IRB faltante en la especificación → [CLARIFY: número de aprobación IRB].
3. Verificación cruzada: estimador (MCO robusto para clústeres), resultado primario declarado, regla de exclusión (intención de tratar) declarada. Pasó.
4. Sin citas de literatura previa — saltar verificación posterior al vuelo. Resultado: Documento escrito. El resumen de salida marca 1 elemento [CLARIFY:] para completar antes del envío a AEA.

Ejemplo 3 — Descripción de forma libre, formulario corto AsPredicted

El usuario dice: "Prerregistra mi próximo experimento de priming, estilo AsPredicted" (sin --input) Acciones:

1. Solicitar la descripción de 1 a 3 párrafos.
2. El usuario proporciona un párrafo; la hipótesis carece de dirección → preguntar una vez: "¿Dirección?"
3. El usuario aclara; completar los 9 campos de AsPredicted.
4. Regla de parada de tamaño de muestra omitida → [CLARIFY: N objetivo o regla de parada]. Resultado: Formulario corto escrito; un DEBE [CLARIFY:] marcado; se informa al usuario que debe completarlo antes de pegarlo en AsPredicted.

Solución de problemas

"La descripción contiene resultados" — por diseño. Mueve los resultados a un informe de métodos y resultados; el prerregistro es prospectivo.

La verificación posterior al vuelo de citas falla con FALLÓ — claim-verifier no pudo encontrar un artículo citado en WebSearch / corpus. O la cita es real pero el verificador no la encontró (común con trabajos muy recientes / tras muros de pago — cita explícitamente con URL), o la cita es alucinada. Inspecciona manualmente antes de subir.

Diferentes registros piden cosas diferentes — usa la plantilla propia del registro si el mapeo de este skill es demasiado grueso. Los tres estilos cubren ~90% de los prerregistros en ciencias sociales; los casos límite (PROSPERO, ClinicalTrials.gov, ISRCTN) necesitan el formulario nativo del registro.

El directorio de salida no existe — quality_reports/preregistrations/.gitkeep debería existir en un fork nuevo; si falta, el skill creará el directorio antes de escribir.