/preregister — Générateur de document de pré-enregistrement

Produit un document de pré-enregistrement prêt à être déposé dans un registre. L'utilisateur le téléverse vers un registre réel (OSF / AsPredicted / AEA RCT Registry) — cette compétence rédige le texte et la structure, elle ne soumet rien.

Pourquoi pré-enregistrer

Le pré-enregistrement est un engagement écrit sur vos hypothèses, votre design et votre plan d'analyse avant de voir les données (ou, pour les analyses observationnelles, avant d'analyser le résultat réalisé). Il sépare les tests confirmatoires des tests exploratoires et vous protège contre le p-hacking, le HARKing et les chemins de bifurcation. Différents domaines utilisent différents registres :

Science politique, psychologie, sciences sociales générales → OSF (osf.io/registries) est le choix par défaut. AsPredicted (aspredicted.org) est un formulaire court populaire pour les expériences.
Expériences de terrain en économie → AEA RCT Registry (socialscienceregistry.org) est obligatoire pour la soumission aux revues AEA depuis 2018.
Santé publique / essais cliniques → ClinicalTrials.gov ou ISRCTN (NON couverts par cette compétence — utilisez le modèle du registre d'essai lui-même).

Quand l'utiliser

Avant de lancer une expérience (laboratoire, terrain ou sondage).
Avant de collecter des données observationnelles sur une population cible pour une question de recherche spécifique.
Avant d'analyser des données auxquelles vous avez accès mais que vous n'avez pas encore examinées pour l'hypothèse focale.
Pendant une révision et resoumission lorsqu'un évaluateur demande un plan d'analyse écrit.

Quand NE PAS l'utiliser

Après avoir vu les résultats réalisés et vouloir « pré-enregistrer rétrospectivement » — ce n'est pas du pré-enregistrement. La compétence refusera si la description d'entrée inclut des résultats.
Pour des analyses exploratoires — celles-ci n'ont pas besoin de pré-enregistrement ; elles nécessitent un étiquetage transparent.
Pour des méta-analyses — utilisez PROSPERO directement, pas ce modèle.

Flux de travail

PHASE 1 — Lecture des entrées

Deux modes d'entrée :

--input <chemin> — un cahier des charges de recherche produit par /interview-me (sauvegardé sous quality_reports/specs/) ou tout fichier Markdown structuré. Lisez le cahier des charges et extrayez : question de recherche, hypothèses (directionnelles !), source de données, design, échantillon, approche d'analyse. Si le cahier des charges mentionne un type d'article (/interview-me l'écrit sur une ligne **Paper type:**, par ex. survey-experiment), utilisez-le pour orienter le choix du style.
Pas de --input — invitez l'utilisateur à fournir une description de l'étude en 1 à 3 paragraphes, puis poursuivez. Si la description omet une hypothèse directionnelle, demandez une fois. N'inventez pas.

Conditions de refus (à vérifier avant toute rédaction) :

La description contient des résultats réalisés (« nous avons trouvé », « l'estimation est », « p = ») → refusez avec : « Le pré-enregistrement est prospectif ; cette description inclut des résultats. Vouliez-vous dire /respond-to-referees ou rédiger une section méthodes ? »
La description n'a aucune hypothèse testable (cadrage purement exploratoire) → signalez-le et demandez si l'utilisateur souhaite la version analyse exploratoire du modèle OSF (toujours utile, mais pas un test confirmatoire enregistré).

PHASE 2 — Choix du style

Valeur par défaut selon le domaine (utilisée quand --style n'est pas fourni) :

Signal de domaine	Style par défaut
`Paper type: survey-experiment` ou contexte science politique / psychologie	`osf`
Expérience de terrain en éco / étiqueté « RCT » / intervention randomisée approuvée par un comité d'éthique	`aea-rct`
Demande de formulaire rapide en 9 questions, expérience de labo en psychologie, contrainte de temps	`aspredicted`
Tout autre cas	`osf`

L'utilisateur peut remplacer avec --style osf|aspredicted|aea-rct.

PHASE 3 — Génération du document

Lisez templates/preregistration-template.md. Le modèle a trois sections de style ; utilisez uniquement la section correspondant au style choisi (ne fusionnez pas — les registres diffèrent).

Communs à tous les styles, le document DOIT inclure :

Titre et auteurs.
Date et version.
Renvoi vers le cahier des charges source (si --input a été fourni) pour garantir la traçabilité.

Sections spécifiques au style :

osf — Hypothèses (directionnelles, numérotées) · Design · Plan d'échantillonnage · Variables · Plan d'analyse · Critères d'inférence · Exclusions de données · Gestion des données manquantes · Analyses exploratoires (clairement étiquetées comme telles) · Autre.
aspredicted — 9 champs numérotés selon le formulaire AsPredicted : (1) statut de la collecte de données, (2) hypothèse, (3) variable dépendante clé, (4) conditions, (5) analyses, (6) valeurs aberrantes/exclusions, (7) taille d'échantillon + règle d'arrêt, (8) autre chose, (9) nom (étude pas article).
aea-rct — Intervention · Résultats (primaires, secondaires) · Hypothèses primaires · Échantillon (N cible, éligibilité, unité de randomisation, méthode de randomisation) · Approbation IRB · Dates de l'essai · Calcul de puissance · Pièce jointe du plan d'analyse · Statut (pas encore en cours / en cours / terminé).

Annotez chaque section avec l'une des mentions suivantes :

MUST — requis par le registre ; le document ne peut pas être soumis sans cela.
SHOULD — fortement recommandé ; les évaluateurs s'y attendent.
MAY — optionnel ; inclure si pertinent.

Réutilisez le cadre MUST/SHOULD/MAY de templates/requirements-spec.md. Pour chaque MUST que l'entrée n'a pas fourni, écrivez [CLARIFY: <question spécifique>] plutôt que d'inventer du contenu.

PHASE 4 — Vérifications croisées (avant écriture sur le disque)

Refusez de marquer le document « prêt » si l'une de ces vérifications échoue :

Directionnalité des hypothèses. Chaque hypothèse doit contenir une direction (« supérieur à », « augmente », « prédit négativement », « aucun effet » est acceptable comme affirmation directionnelle dans le cadre des tests d'équivalence). Rejetez « est associé à » sans signe.
Estimateur nommé. Le plan d'analyse nomme un estimateur spécifique (OLS, logit, fixest::feols, lme4::lmer, ATT différence-des-moyennes…) et une variable de résultat primaire. « Régression » seul est insuffisant.
Plan d'échantillonnage numérique. Le N cible, la règle d'arrêt ou l'objectif de calcul de puissance apparaissent. « Autant que possible » n'est pas un plan d'échantillonnage. Pour les RCT et les designs prospectifs, suivez le SKILL.md de /power-analysis (lisez-le — la compétence n'est invoquée que par l'utilisateur, donc elle ne peut pas être appelée d'ici) pour produire le MDE / N requis et un paragraphe de puissance prêt à être copié pour ce champ.
Exclusions a priori. Les règles concernant les valeurs aberrantes et les exclusions sont énoncées avant de voir les données (« nous exclurons les observations avec un temps de complétion < 1 minute »). Un vague « nous traiterons les valeurs aberrantes » échoue.
Cohérence interne. Si le design est randomisé, l'unité de randomisation correspond à l'unité d'analyse OU le plan d'analyse traite de l'agrégation. Si observationnel, la stratégie d'identification est énoncée.

Pour chaque échec, le document reçoit un espace réservé [CLARIFY: …] ; le document est écrit sur le disque mais signalé dans le résumé de sortie comme « INCOMPLET — N éléments MUST non résolus ».

PHASE 5 — Vérification post-vol

Si le document cite de la littérature antérieure dans la section de justification (par ex., « En nous appuyant sur Hainmueller et al. 2014, nous nous attendons à … »), invoquez /verify-claims via l'outil Agent pour vérifier ces citations. Passez le chemin du brouillon et une liste des citations explicites. L'agent claim-verifier (contexte frais, ne voit jamais le brouillon) retourne PASS / PARTIAL / FAIL par citation. Signalez tout FAIL/PARTIAL dans le résumé de sortie.

Sautez la vérification post-vol si :

Aucune citation de la littérature antérieure dans le document.
L'utilisateur passe --no-verify (drapeau hérité du post-vol de /lit-review et /research-ideation).

PHASE 6 — Sortie

Écrivez dans quality_reports/preregistrations/YYYY-MM-DD_<slug>.md (gitignoré — le pré-enregistrement est destiné à être horodaté et téléversé en externe, pas commité avec le code).

Affichez dans le chat :

✓ Brouillon de pré-enregistrement sauvegardé : quality_reports/preregistrations/<fichier>.md
  Style : <osf|aspredicted|aea-rct>
  Sections : <nombre> total — <complètes> complètes, <à_clarifier> avec espaces réservés [CLARIFY:]
  Citations vérifiées : <PASS>/<PARTIAL>/<FAIL>  (ou « aucune citation à vérifier »)
  Suite : révisez les espaces réservés [CLARIFY:], remplissez, puis téléversez sur <url-du-registre>

Incluez l'URL du registre : OSF → osf.io/registries, AsPredicted → aspredicted.org, AEA RCT → socialscienceregistry.org.

Références croisées

templates/preregistration-template.md — les trois modèles de style que cette compétence consomme.
templates/requirements-spec.md — langage d'annotation MUST/SHOULD/MAY réutilisé ici.
.claude/skills/interview-me/SKILL.md — produit le cahier des charges que cette compétence consomme via --input.
.claude/skills/power-analysis/SKILL.md — suivi (non invoqué) pour fournir le MDE / N requis + paragraphe de puissance pour le champ du plan d'échantillonnage (RCT).
.claude/skills/verify-claims/SKILL.md — la Phase 5 l'invoque pour la vérification post-vol des citations.
.claude/references/discipline-cards.md — valeurs par défaut par domaine qui guident la sélection de --style.
.claude/rules/replication-protocol.md — le pré-enregistrement est l'engagement vers l'avant ; le protocole de réplication est le contrat vers l'arrière.

Exemples

Exemple 1 — Expérience par sondage en science politique à partir d'un cahier des charges

L'utilisateur dit : « Pré-enregistre cette étude » (avec --input quality_reports/specs/2026-04-15_priming-effects.md) Actions :

Lire le cahier des charges ; **Paper type:** survey-experiment → style par défaut osf.
Extraire 2 hypothèses directionnelles, MTurk N=1,200, OLS avec indicatrices de traitement.
Générer le document OSF, toutes les sections MUST remplies, 1 MAY laissée vide.
Aucune citation de la littérature antérieure au-delà du cahier des charges — ignorer la vérification post-vol. Résultat : Sauvegardé dans quality_reports/preregistrations/2026-04-15_priming-effects.md. L'utilisateur téléverse sur OSF.

Exemple 2 — Expérience de terrain en économie, AEA RCT Registry

L'utilisateur dit : « Rédige un pré-enregistrement AEA RCT pour le pilote de transfert monétaire » (avec --style aea-rct --input quality_reports/specs/2026-03-10_ct-pilot.md) Actions :

Lire le cahier des charges ; unité de randomisation = village, résultat primaire = consommation.
Générer les champs AEA RCT. Numéro IRB manquant dans le cahier des charges → [CLARIFY: numéro d'approbation IRB].
Vérification croisée : estimateur (OLS robuste aux clusters), résultat primaire énoncé, règle d'exclusion (intention-de-traiter) énoncée. Réussi.
Aucune citation de la littérature antérieure — ignorer la vérification post-vol. Résultat : Document écrit. Le résumé de sortie signale 1 élément [CLARIFY:] à remplir avant la soumission à AEA.

Exemple 3 — Description libre, formulaire court AsPredicted

L'utilisateur dit : « Pré-enregistre ma prochaine expérience d'amorçage, style AsPredicted » (pas de --input) Actions :

Demander la description en 1 à 3 paragraphes.
L'utilisateur fournit un paragraphe ; l'hypothèse manque de direction → demander une fois : « Direction ? »
L'utilisateur clarifie ; remplir les 9 champs AsPredicted.
Règle d'arrêt de la taille d'échantillon omise → [CLARIFY: N cible ou règle d'arrêt]. Résultat : Formulaire court écrit ; un MUST [CLARIFY:] signalé ; l'utilisateur est invité à le remplir avant de le coller dans AsPredicted.

Dépannage

« La description contient des résultats » — par conception. Déplacez les résultats dans un compte rendu méthodes + résultats ; le pré-enregistrement est prospectif.

La vérification post-vol des citations échoue avec FAIL — claim-verifier n'a pas trouvé un article cité dans WebSearch / corpus. Soit la citation est réelle mais le vérificateur l'a manquée (courant avec des travaux très récents / payants — citez explicitement avec URL), soit la citation est hallucinée. Inspectez manuellement avant de téléverser.

Différents registres demandent des choses différentes — utilisez le modèle propre du registre si le mappage de cette compétence est trop grossier. Les trois styles couvrent ~90 % des pré-enregistrements en sciences sociales ; les cas limites (PROSPERO, ClinicalTrials.gov, ISRCTN) nécessitent le formulaire natif du registre.

Le répertoire de sortie n'existe pas — quality_reports/preregistrations/.gitkeep devrait exister sur un fork frais ; s'il manque, la compétence créera le répertoire avant d'écrire.

MarcoGarcian/preregister

Qu'est-ce que preregister ?

Demander à votre IA préférée

Documentation