Mmcp.market

preregister skill

by pedrohcgs·pedrohcgs/claude-code-my-workflow·1.6k stars·MIT

Draft a structured preregistration document (OSF, AsPredicted, or AEA RCT Registry style) from a research spec or free-form study description. Output is a Markdown file with hypotheses, design, sampling plan, analysis plan, exclusions, and inference criteria — annotated with MUST / SHOULD / MAY clarity flags. Use when user says "preregister", "draft a preregistration", "OSF preregistration", "AsPredicted", "AEA RCT registry", "PAP", "preanalysis plan", or before launching an experiment / data collection / analysis on data the analyst has not yet seen. NOT a registry submission tool — produces a document the user uploads to OSF / AsPredicted / AEA themselves.

A100/100content scan

Is the preregister skill safe?

Clean: nothing in its files matched our rules. We read 1 file in the folder on 2026-09-28.

No findings.

Install the preregister skill

A skill is a folder. Copy it into your agent's skills folder and the agent loads it when the task matches its description.

git clone --depth 1 https://github.com/pedrohcgs/claude-code-my-workflow.git /tmp/claude-code-my-workflow
mkdir -p ~/.claude/skills
cp -r /tmp/claude-code-my-workflow/.claude/skills/preregister ~/.claude/skills/preregister
available in every project

In the Claude apps, zip the folder and upload it from the Skills settings. The folder on GitHub

The instructions your agent would load

SKILL.md as published, without the frontmatter. Read it on GitHub

/preregister — Preregistration Document Generator

Produce a registry-ready preregistration document. The user uploads it to a real registry (OSF / AsPredicted / AEA RCT Registry) — this skill writes the prose and structure, it does not submit anywhere.

Why preregister

Preregistration is a written commitment to your hypotheses, design, and analysis plan before you see the data (or, for observational analyses, before you analyse the realised outcome). It separates confirmatory tests from exploratory tests and protects you from p-hacking, HARKing, and forking-paths. Different fields use different registries:

  • Political science, psychology, broad social science → OSF (osf.io/registries) is the default. AsPredicted (aspredicted.org) is a popular short form for experiments.
  • Economics field experiments → AEA RCT Registry (socialscienceregistry.org) is mandatory for AEA journal submission since 2018.
  • Public health / clinical trials → ClinicalTrials.gov or ISRCTN (NOT covered by this skill — use the trial-registry's own template).

When to use

  • Before launching an experiment (lab, field, or survey).
  • Before collecting observational data on a target population for a specific RQ.
  • Before analysing data you have access to but haven't yet examined for the focal hypothesis.
  • During R&R when a referee asks for a written preanalysis plan.

When NOT to use

  • After you've seen the realised outcomes and want to "preregister retrospectively" — that is not preregistration. The skill will refuse if the input description includes results.
  • For exploratory analyses — those don't need preregistration; they need transparent labelling.
  • For meta-analyses — use PROSPERO directly, not this template.

Workflow

PHASE 1 — Read inputs

Two input modes:

  1. --input — a research spec produced by /interview-me (saved under qualityreports/specs/) or any structured Markdown file. Read the spec and extract: research question, hypotheses (directional!), data source, design, sample, analysis approach. If the spec records a paper type (/interview-me writes it on a Paper type:** line, e.g. survey-experiment), use it to bias the style choice.
  2. No --input — prompt the user for a 1–3 paragraph description of the study, then proceed. If the description omits a directional hypothesis, ask once. Do not fabricate.

Refusal conditions (must be checked before any drafting):

  • Description contains realised results ("we found", "the estimate is", "p =") → refuse with: "Preregistration is forward-looking; this description includes results. Did you mean /respond-to-referees or to write a methods section?"
  • Description has no testable hypothesis at all (pure exploratory framing) → flag and ask whether the user wants the exploratory analysis version of the OSF template (still useful, but not a registered confirmatory test).

PHASE 2 — Pick the style

Default per field (used when --style is not given):

User can override with --style osf|aspredicted|aea-rct.

PHASE 3 — Generate the document

Read templates/preregistration-template.md. The template has three style sections; only use the section matching the chosen style (don't merge — registries differ).

Common to all styles, the document MUST include:

  • Title and authors.
  • Date and version.
  • Pointer back to the source spec (if --input was given) so traceability survives.

Style-specific sections:

  • osf — Hypotheses (directional, numbered) · Design · Sampling Plan · Variables · Analysis Plan · Inference Criteria · Data Exclusions · Missing Data Handling · Exploratory Analyses (clearly labelled as such) · Other.
  • aspredicted — 9 numbered fields per the AsPredicted form: (1) data collection status, (2) hypothesis, (3) key dependent variable, (4) conditions, (5) analyses, (6) outliers/exclusions, (7) sample size + stopping rule, (8) anything else, (9) name (study not paper).
  • aea-rct — Intervention · Outcomes (primary, secondary) · Primary hypotheses · Sample (target N, eligibility, randomization unit, randomization method) · IRB approval · Trial dates · Power calc · Pre-analysis plan attachment · Status (not yet on the air / ongoing / completed).

Annotate each section with one of:

  • MUST — registry requires this; the document cannot be submitted without it.
  • SHOULD — strongly recommended; reviewers expect it.
  • MAY — optional; include if relevant.

Re-use the MUST/SHOULD/MAY framework from templates/requirements-spec.md. For each MUST that the input did not supply, write [CLARIFY: ] rather than fabricating content.

PHASE 4 — Cross-checks (before writing to disk)

Refuse to mark the document "ready" if any of these fails:

  • Hypothesis directionality. Each hypothesis must contain a direction ("higher than", "increases", "negatively predicts", "no effect" is acceptable as a directional claim under equivalence-testing). Reject "is associated with" without a sign.
  • Estimator named. Analysis plan names a specific estimator (OLS, logit, fixest::feols, lme4::lmer, ATT difference-in-means …) and a primary outcome variable. "Regression" alone is insufficient.
  • Sample plan numeric. Target N, stopping rule, or power-calc target appear. "As many as possible" is not a sample plan. For RCTs and prospective designs, follow /power-analysis's SKILL.md (read it — the skill is user-invoked only, so it cannot be called from here) to produce the MDE / required-N and a ready-to-paste power paragraph for this field.
  • Exclusions ex ante. Outlier and exclusion rules are stated before the data is seen ("we will exclude observations with completion time < 1 minute"). Vague "we'll deal with outliers" fails.
  • Internal consistency. If the design is randomised, the unit of randomisation matches the unit of analysis OR the analysis plan addresses clustering. If observational, identification strategy is stated.

For each failure, the document gets a [CLARIFY: …] placeholder; the document is written to disk but flagged in the output summary as "INCOMPLETE — N MUST items unresolved".

PHASE 5 — Post-flight verification

If the document cites prior literature in the rationale section (e.g., "Building on Hainmueller et al. 2014, we expect …"), invoke /verify-claims via the Agent tool to fact-check those citations. Pass the draft path and a list of explicit citations. The claim-verifier agent (fresh context, never sees the draft) returns PASS / PARTIAL / FAIL per citation. Surface any FAIL/PARTIAL in the output summary.

Skip post-flight if:

  • No prior-literature citations in the document.
  • User passes --no-verify (flag inherited from /lit-review and /research-ideation post-flight).

PHASE 6 — Output

Write to qualityreports/preregistrations/YYYY-MM-DD.md (gitignored — preregistration is meant to be timestamped and uploaded externally, not committed alongside code).

Print to chat:

✓ Preregistration draft saved: quality_reports/preregistrations/<file>.md
  Style: <osf|aspredicted|aea-rct>
  Sections: <count> total — <complete> complete, <clarify> with [CLARIFY:] placeholders
  Citations verified: <PASS>/<PARTIAL>/<FAIL>  (or "no citations to verify")
  Next: review the [CLARIFY:] placeholders, fill in, then upload to <registry-url>

Include the registry URL: OSF → osf.io/registries, AsPredicted → aspredicted.org, AEA RCT → socialscienceregistry.org.

Cross-references

  • templates/preregistration-template.md — the three style templates this skill consumes.
  • templates/requirements-spec.md — MUST/SHOULD/MAY annotation language re-used here.
  • .claude/skills/interview-me/SKILL.md — produces the spec this skill consumes via --input.
  • .claude/skills/power-analysis/SKILL.md — followed (not invoked) to supply the MDE / required-N + power paragraph for the sample-plan field (RCTs).
  • .claude/skills/verify-claims/SKILL.md — Phase 5 invokes this for citation post-flight.
  • .claude/references/discipline-cards.md — field defaults that drive --style selection.
  • .claude/rules/replication-protocol.md — preregistration is the forward commitment; replication-protocol is the backward contract.

Examples

Example 1 — Poli-sci survey experiment from a spec

User says: "Preregister this study" (with --input qualityreports/specs/2026-04-15priming-effects.md) Actions:

Result: Saved to qualityreports/preregistrations/2026-04-15priming-effects.md. User uploads to OSF.

  1. Read spec; Paper type: survey-experiment → default style osf.
  2. Extract 2 directional hypotheses, MTurk N=1,200, OLS with treatment dummies.
  3. Generate OSF document, all MUST sections filled, 1 MAY left blank.
  4. No prior-lit citations beyond the spec — skip post-flight.

Example 2 — Econ field experiment, AEA RCT Registry

User says: "Draft an AEA RCT preregistration for the cash-transfer pilot" (with --style aea-rct --input qualityreports/specs/2026-03-10ct-pilot.md) Actions:

Result: Document written. Output summary flags 1 [CLARIFY:] item to fill before AEA submission.

  1. Read spec; randomization unit = village, primary outcome = consumption.
  2. Generate AEA RCT fields. IRB number missing in spec → [CLARIFY: IRB approval number].
  3. Cross-check: estimator (cluster-robust OLS), primary outcome stated, exclusion rule (intent-to-treat) stated. Pass.
  4. No prior-lit cites — skip post-flight.

Example 3 — Free-form description, AsPredicted short form

User says: "Preregister my next priming experiment, AsPredicted style" (no --input) Actions:

Result: Short form written; one MUST [CLARIFY:] flagged; user told to fill before pasting into AsPredicted.

  1. Prompt for the 1–3 paragraph description.
  2. User supplies a paragraph; hypothesis lacks direction → ask once: "Direction?"
  3. User clarifies; populate the 9 AsPredicted fields.
  4. Sample-size stopping rule omitted → [CLARIFY: target N or stopping rule].

Troubleshooting

"Description contains results" — by design. Move results into a methods + results write-up; preregistration is forward-looking.

Citation post-flight fails with FAIL — claim-verifier could not find a cited paper in WebSearch / corpus. Either the citation is real but the verifier missed it (common with very recent / paywalled work — cite explicitly with URL), or the citation is hallucinated. Inspect manually before upload.

Different registries asking for different things — use the registry's own template if this skill's mapping is too coarse. The three styles cover ~90% of social-science preregistrations; edge cases (PROSPERO, ClinicalTrials.gov, ISRCTN) need the registry's native form.

Output dir doesn't exist — quality_reports/preregistrations/.gitkeep should exist on a fresh fork; if missing, the skill will create the directory before writing.

More skills from pedrohcgs/claude-code-my-workflow

  • Aadjudicate-reviewTurn an incoming set of findings — from an AI reviewer, a referee report, a code review, a linter, or a second model — into verified fixes, without letting a confident misread damage correct work. Every finding is a CANDIDATE until checked against the actual source. Use whenever you receive review comments, audit findings, or a critique you did not write yourself, especially when the reviewer is a model or when the volume is too large to check by feel.
  • Aaudit-reproducibilityEnforce the replication-protocol.md rule by cross-checking numeric claims in a manuscript against the actual R / Stata / Python outputs. Report PASS/FAIL per claim against tolerance thresholds. Use before submission and before releasing a replication package.
  • Ablast-radiusBefore and after changing anything shared — a function's return value, a signature, a schema, a label set, a config default, a constant, a file format — find every consumer and actually run them. Catches the change that looks purely additive but silently breaks a contract in a file you never opened. Use when editing shared code, adding a field/column/return element, renaming, changing units or defaults, or touching a pipeline that produces reported numbers.
  • Acapture-environmentSnapshot the computational environment for a replication package — detects the analysis stack (R / Stata / Python) and emits the right lockfiles (renv.lock + sessionInfo.txt, requirements.txt / environment.yml / uv.lock, Stata version + ado package list), records seeds and RNG kind, optionally writes a pinning Dockerfile, and produces a paste-ready "Computational requirements" block. Use when user says "capture the environment", "snapshot my dependencies", "pin the versions", "make a renv.lock / requirements.txt", "make this byte-reproducible", or before releasing a replication package to openICPSR / the AEA Data Editor.
  • AchallengeStress-test a finding against the choices you did not make. Enumerates the discrete forks a competent analyst could have taken (measure definition, sample filter, control set, clustering level, weighting, functional form), runs the specification grid, and reports the distribution rather than a point estimate — then attacks the identifying assumption with named, computable sensitivity statistics. Use when the user says "is this robust", "challenge this result", "specification curve", "multiverse", "how sensitive is this", "what if I'd used a different measure", "stress-test my estimate", or before a result becomes a headline claim. NOT a reviewer of prose or code — it challenges the CLAIM.
  • AcheckpointSave a structured state snapshot before stopping or handing off. Captures the active plan, recent decisions, file pointers (with line numbers), open questions, and the next 1–3 actions into a checkpoint file under `quality_reports/checkpoints/`. Optionally proposes `[LEARN]` entries to add to MEMORY.md. Use when user says "checkpoint", "save state", "snapshot before I stop", "where am I", "wrap up the session for handoff", or before a long break / model switch / collaborator handoff. Companion to (NOT replacement for) the narrative session-log workflow.
  • Acoauthor-briefGenerate a co-author / collaborator handoff brief for a multi-author, multi-machine project — summarizing what changed since the last brief (git delta), the current state of each artifact (manuscript, analysis, slides), open questions, how to reproduce locally, and any restricted-data access steps. Use when user says "coauthor brief", "handoff brief", "bring my coauthor up to speed", "what changed since last week", "onboard a collaborator", "write a handoff for [name]", or before sending a co-author the repo. NOT a commit or a checkpoint — it is the cross-machine, cross-person summary `meta-governance.md` only partially covers.
  • AcommitCommit the current work — runs the quality, consistency and passport gates, branches off main if needed, stages specific files, and writes a commit whose subject states what is now true. Pushes and opens a pull request only with --pr or when the user asks; never merges — a merge happens only when the user explicitly says to merge. Use ONLY on explicit commit intent — user says "commit", "let's commit this", "open a PR", or prefixes with `/commit`. Do NOT auto-invoke on vague end-of-task phrases ("we're done", "wrap up") — those require explicit confirmation first. Never force-pushes or skips hooks.
  • Acompile-latexCompile a Beamer LaTeX slide deck with XeLaTeX (3 passes + bibtex). Use when user says "compile", "build the slides", "rebuild the PDF", "run latex", "render the tex", or asks why a `.tex` file isn't producing a PDF. Operates on `Slides/*.tex`.
  • Acompress-sessionDistill the current conversation into a structured note (decisions made, open questions, file pointers with line numbers, next 1–3 actions) and save to `quality_reports/session_logs/` before auto-compression. Differs from `/checkpoint` (explicit stop-point snapshot) and from auto-compaction (which truncates rather than distills). Use when context is approaching auto-compact threshold, when a long pipeline has accumulated many decisions, or when the user says "compress", "distil this session", "before we hit auto-compact", "structured handoff before context resets".
  • Acontext-statusShow current context status and session health. Use to check how much context has been used, whether auto-compact is approaching, and what state will be preserved.
  • Acreate-lectureCreate a new Beamer lecture `.tex` from source papers and materials, with notation consistency checks and the project's preamble wired in. Use when user says "create a lecture on X", "new lecture from these papers", "start a deck on topic Y", "scaffold a new Beamer file", "build me a lecture from these PDFs". Scaffolds the full deck — NOT for compiling existing `.tex` (use `/compile-latex`).

All agent skills → · MCP servers