/preregister — Gerador de Documentos de Pré-registro

Produza um documento de pré-registro pronto para submissão. O usuário o envia para um repositório real (OSF / AsPredicted / AEA RCT Registry) — esta habilidade escreve o texto e a estrutura, mas não faz a submissão.

Por que pré-registrar

O pré-registro é um compromisso por escrito com suas hipóteses, design e plano de análise antes de ver os dados (ou, para análises observacionais, antes de analisar o desfecho já realizado). Ele separa os testes confirmatórios dos exploratórios e protege contra p-hacking, HARKing e caminhos de bifurcação (forking paths). Diferentes áreas usam repositórios distintos:

Ciência política, psicologia, ciências sociais em geral → OSF (osf.io/registries) é o padrão. AsPredicted (aspredicted.org) é um formulário curto popular para experimentos.
Experimentos de campo em economia → AEA RCT Registry (socialscienceregistry.org) é obrigatório para submissão em periódicos da AEA desde 2018.
Saúde pública / ensaios clínicos → ClinicalTrials.gov ou ISRCTN (NÃO são cobertos por esta habilidade — use o modelo do próprio repositório de ensaios clínicos).

Quando usar

Antes de lançar um experimento (laboratório, campo ou survey).
Antes de coletar dados observacionais de uma população-alvo para uma pergunta de pesquisa específica.
Antes de analisar dados aos quais você tem acesso, mas ainda não examinou para a hipótese focal.
Durante revisão e réplica (R&R) quando um revisor solicitar um plano de pré-análise por escrito.

Quando NÃO usar

Depois de ver os desfechos realizados e querer "pré-registrar retrospectivamente" — isso não é pré-registro. A habilidade se recusará se a descrição de entrada incluir resultados.
Para análises exploratórias — essas não precisam de pré-registro; precisam de rotulagem transparente.
Para meta-análises — use o PROSPERO diretamente, não este modelo.

Fluxo de trabalho

FASE 1 — Ler entradas

Dois modos de entrada:

--input <caminho> — uma especificação de pesquisa produzida por /interview-me (salva em quality_reports/specs/) ou qualquer arquivo Markdown estruturado. Leia a especificação e extraia: pergunta de pesquisa, hipóteses (direcionais!), fonte de dados, design, amostra, abordagem de análise. Se a especificação registrar um tipo de artigo (/interview-me escreve em uma linha **Tipo de artigo:**, por exemplo survey-experimento), use-o para influenciar a escolha do estilo.
Sem --input — solicite ao usuário uma descrição de 1 a 3 parágrafos do estudo e prossiga. Se a descrição omitir uma hipótese direcional, pergunte uma vez. Não invente.

Condições de recusa (devem ser verificadas antes de qualquer rascunho):

A descrição contém resultados realizados ("encontramos", "a estimativa é", "p =") → recuse com: "Pré-registro é prospectivo; esta descrição inclui resultados. Você quis dizer /responder-a-revisores ou escrever uma seção de métodos?"
A descrição não tem nenhuma hipótese testável (enquadramento puramente exploratório) → sinalize e pergunte se o usuário deseja a versão de análise exploratória do modelo OSF (ainda útil, mas não é um teste confirmatório registrado).

FASE 2 — Escolher o estilo

Padrão por área (usado quando --style não é fornecido):

Sinal da área	Estilo padrão
`Tipo de artigo: survey-experimento` ou contexto de ciência política / psicologia	`osf`
Experimento de campo em economia / rotulado como "RCT" / intervenção randomizada aprovada pelo IRB	`aea-rct`
Formulário rápido de 9 perguntas, experimento de laboratório em psicologia, pressão de tempo	`aspredicted`
Qualquer outro	`osf`

O usuário pode substituir com --style osf|aspredicted|aea-rct.

FASE 3 — Gerar o documento

Leia templates/preregistration-template.md. O modelo tem três seções de estilo; use apenas a seção correspondente ao estilo escolhido (não mescle — os repositórios diferem).

Comum a todos os estilos, o documento DEVE incluir:

Título e autores.
Data e versão.
Referência de volta à especificação fonte (se --input foi fornecido) para que a rastreabilidade seja mantida.

Seções específicas de cada estilo:

osf — Hipóteses (direcionais, numeradas) · Design · Plano de Amostragem · Variáveis · Plano de Análise · Critérios de Inferência · Exclusões de Dados · Tratamento de Dados Faltantes · Análises Exploratórias (claramente rotuladas como tal) · Outros.
aspredicted — 9 campos numerados conforme o formulário AsPredicted: (1) status da coleta de dados, (2) hipótese, (3) variável dependente chave, (4) condições, (5) análises, (6) outliers/exclusões, (7) tamanho da amostra + regra de parada, (8) qualquer outra coisa, (9) nome (estudo, não artigo).
aea-rct — Intervenção · Desfechos (primário, secundário) · Hipóteses primárias · Amostra (N alvo, elegibilidade, unidade de randomização, método de randomização) · Aprovação do IRB · Datas do ensaio · Cálculo de poder · Anexo do plano de pré-análise · Status (ainda não iniciado / em andamento / concluído).

Anote cada seção com um dos seguintes:

DEVE — o repositório exige; o documento não pode ser submetido sem isso.
DEVERIA — fortemente recomendado; revisores esperam.
PODE — opcional; inclua se relevante.

Reutilize a estrutura DEVE/DEVERIA/PODE de templates/requirements-spec.md. Para cada campo DEVE que a entrada não forneceu, escreva [ESCLARECER: <pergunta específica>] em vez de inventar conteúdo.

FASE 4 — Verificações cruzadas (antes de escrever no disco)

Recuse-se a marcar o documento como "pronto" se alguma destas falhar:

Direcionalidade da hipótese. Cada hipótese deve conter uma direção ("maior que", "aumenta", "prediz negativamente"; "nenhum efeito" é aceitável como afirmação direcional sob teste de equivalência). Rejeite "está associado a" sem um sinal.
Estimador nomeado. O plano de análise nomeia um estimador específico (OLS, logit, fixest::feols, lme4::lmer, ATT diferença-de-médias …) e uma variável de desfecho primário. Apenas "Regressão" é insuficiente.
Plano de amostragem numérico. N alvo, regra de parada ou alvo de cálculo de poder aparecem. "O máximo possível" não é um plano de amostragem. Para RCTs e designs prospectivos, siga o SKILL.md de /power-analysis (leia-o — a habilidade é invocada apenas pelo usuário, portanto não pode ser chamada daqui) para produzir o MDE / N-requerido e um parágrafo de poder pronto para colar neste campo.
Exclusões ex ante. Regras de outlier e exclusão são declaradas antes de ver os dados ("excluiremos observações com tempo de conclusão < 1 minuto"). "Lidaremos com outliers" de forma vaga falha.
Consistência interna. Se o design é randomizado, a unidade de randomização corresponde à unidade de análise OU o plano de análise aborda o agrupamento. Se observacional, a estratégia de identificação é declarada.

Para cada falha, o documento recebe um espaço reservado [ESCLARECER: …]; o documento é escrito no disco, mas sinalizado no resumo de saída como "INCOMPLETO — N itens DEVE não resolvidos".

FASE 5 — Verificação pós-voo

Se o documento citar literatura anterior na seção de fundamentação (por exemplo, "Com base em Hainmueller et al. 2014, esperamos …"), invoque /verify-claims através da ferramenta Agent para verificar essas citações. Passe o caminho do rascunho e uma lista de citações explícitas. O agente claim-verifier (contexto novo, nunca vê o rascunho) retorna APROVADO / PARCIAL / REPROVADO por citação. Exiba qualquer REPROVADO/PARCIAL no resumo de saída.

Pule o pós-voo se:

Não houver citações de literatura anterior no documento.
O usuário passar --no-verify (sinalizador herdado do pós-voo de /lit-review e /research-ideation).

FASE 6 — Saída

Escreva em quality_reports/preregistrations/YYYY-MM-DD_<slug>.md (ignorado pelo git — o pré-registro deve ter timestamp e ser enviado externamente, não versionado junto com o código).

Imprima no chat:

✓ Rascunho de pré-registro salvo: quality_reports/preregistrations/<arquivo>.md
  Estilo: <osf|aspredicted|aea-rct>
  Seções: <total> no total — <completas> completas, <esclarecer> com espaços reservados [ESCLARECER:]
  Citações verificadas: <APROVADO>/<PARCIAL>/<REPROVADO>  (ou "nenhuma citação para verificar")
  Próximo: revise os espaços reservados [ESCLARECER:], preencha e envie para <url-do-repositorio>

Inclua a URL do repositório: OSF → osf.io/registries, AsPredicted → aspredicted.org, AEA RCT → socialscienceregistry.org.

Referências cruzadas

templates/preregistration-template.md — os três modelos de estilo consumidos por esta habilidade.
templates/requirements-spec.md — linguagem de anotação DEVE/DEVERIA/PODE reutilizada aqui.
.claude/skills/interview-me/SKILL.md — produz a especificação consumida por esta habilidade via --input.
.claude/skills/power-analysis/SKILL.md — seguido (não invocado) para fornecer o MDE / N-requerido + parágrafo de poder para o campo de plano de amostragem (RCTs).
.claude/skills/verify-claims/SKILL.md — Fase 5 invoca esta habilidade para verificação de citações.
.claude/references/discipline-cards.md — padrões de área que orientam a seleção de --style.
.claude/rules/replication-protocol.md — pré-registro é o compromisso prospectivo; protocolo de replicação é o contrato retrospectivo.

Exemplos

Exemplo 1 — Experimento de survey em ciência política a partir de uma especificação

Usuário diz: "Pré-registre este estudo" (com --input quality_reports/specs/2026-04-15_efeitos-prime.md) Ações:

Ler especificação; **Tipo de artigo:** survey-experimento → estilo padrão osf.
Extrair 2 hipóteses direcionais, MTurk N=1200, OLS com dummies de tratamento.
Gerar documento OSF, todas as seções DEVE preenchidas, 1 PODE deixado em branco.
Nenhuma citação de literatura anterior além da especificação — pular pós-voo. Resultado: Salvo em quality_reports/preregistrations/2026-04-15_efeitos-prime.md. Usuário envia para OSF.

Exemplo 2 — Experimento de campo em economia, AEA RCT Registry

Usuário diz: "Rascunhe um pré-registro AEA RCT para o piloto de transferência de renda" (com --style aea-rct --input quality_reports/specs/2026-03-10_piloto-tc.md) Ações:

Ler especificação; unidade de randomização = aldeia, desfecho primário = consumo.
Gerar campos AEA RCT. Número do IRB ausente na especificação → [ESCLARECER: número de aprovação do IRB].
Verificação cruzada: estimador (OLS com erros robustos para clusters), desfecho primário declarado, regra de exclusão (intenção-de-tratar) declarada. Aprovado.
Nenhuma citação de literatura anterior — pular pós-voo. Resultado: Documento escrito. Resumo de saída sinaliza 1 item [ESCLARECER:] a preencher antes da submissão na AEA.

Exemplo 3 — Descrição livre, formulário curto AsPredicted

Usuário diz: "Pré-registre meu próximo experimento de priming, estilo AsPredicted" (sem --input) Ações:

Solicitar a descrição de 1 a 3 parágrafos.
Usuário fornece um parágrafo; hipótese carece de direção → perguntar uma vez: "Direção?"
Usuário esclarece; preencher os 9 campos AsPredicted.
Regra de parada do tamanho da amostra omitida → [ESCLARECER: N alvo ou regra de parada]. Resultado: Formulário curto escrito; um DEVE [ESCLARECER:] sinalizado; usuário informado para preencher antes de colar no AsPredicted.

Solução de problemas

"Descrição contém resultados" — por design. Mova os resultados para um texto de métodos + resultados; pré-registro é prospectivo.

Pós-voo de citação falha com REPROVADO — claim-verifier não conseguiu encontrar um artigo citado na WebSearch / corpus. Ou a citação é real, mas o verificador não a encontrou (comum com trabalhos muito recentes / atrás de paywall — cite explicitamente com URL), ou a citação é alucinada. Inspecione manualmente antes do envio.

Repositórios diferentes pedindo coisas diferentes — use o modelo do próprio repositório se o mapeamento desta habilidade for muito grosseiro. Os três estilos cobrem ~90% dos pré-registros em ciências sociais; casos de borda (PROSPERO, ClinicalTrials.gov, ISRCTN) precisam do formulário nativo do repositório.

Diretório de saída não existe — quality_reports/preregistrations/.gitkeep deve existir em um fork novo; se estiver faltando, a habilidade criará o diretório antes de escrever.

MarcoGarcian/preregister

O que é preregister?

Perguntar na sua IA favorita

Documentação