Mmcp.market

stata-replication skill

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

End-to-end Stata replication pipeline — scaffolds numbered `.do` files in `scripts/stata/`, executes them via the `stata-mcp` MCP server, captures logs and outputs to `output/`, and produces publication-ready tables (esttab) and figures (graph export). Mirrors `/data-analysis` for R-first projects. Use when user says "stata replication", "set up Stata pipeline", "scaffold the .do files", "run Stata analysis", "AEA replication package in Stata", or when a project's analysis language is Stata not R.

A100/100content scan

Is the stata-replication 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 stata-replication 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/stata-replication ~/.claude/skills/stata-replication
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

/stata-replication — Stata pipeline scaffold + execution

Build a complete Stata replication pipeline in scripts/stata/: numbered .do files following .claude/rules/stata-code-conventions.md, executed via the stata-mcp MCP server, with outputs landing in output/.

When to use

  • Your project's analysis language is Stata (not R). Common in econ field experiments, RCT studies, and any AEA submission where the original replication package is Stata.
  • You're porting an R-first project to Stata for an AEA submission.
  • You're adding a Stata robustness check to an R-first paper.
  • You want a one-command reproduction: do scripts/stata/99runall.do.

When NOT to use

  • Your project is R-first. Use /data-analysis.
  • Your project is Python-first. Neither this skill nor /data-analysis is the right fit; consider extending the convention rule for Python or porting one of these skills.
  • You're doing quick exploratory work. The numbered-pipeline scaffold is for replication packages, not scratch notebooks.

Prerequisite: stata-mcp installed

This skill requires the stata-mcp MCP server. Install once per user:

claude mcp add stata-mcp --scope user -- uvx stata-mcp

The MCP server provides command-guarded Stata execution (refuses destructive operations like !/shell/erase), RAM monitoring, and Stata Language Server pairing. Maintained by SepineTam.

If stata-mcp is not installed, the skill halts at Phase 0 with installation instructions.

Workflow

Phase 0: Pre-flight

  1. Verify stata-mcp is registered in the user's MCP configuration. If not → halt with install instructions.
  2. Verify Stata is installed locally (the MCP server cannot run without it). Output stata version to confirm.
  3. Confirm scripts/stata/ directory exists or can be created.
  4. Read .claude/rules/stata-code-conventions.md — every emitted .do file follows this convention.
  5. If --from-r flag is set, locate the existing R pipeline at scripts/R/ and use it as a translation source. Apply the Stata → R pitfalls table from replication-protocol.md in reverse.

Phase 1: Scaffold the pipeline

Emit (or update) these files in scripts/stata/, each conforming to the header convention from stata-code-conventions.md:

scripts/stata/
├── 00_install.do        # ssc install, set globals, paths, sessionInfo capture
├── 01_clean.do          # raw → cleaned panel
├── 02_descriptive.do    # summary tables, balance (iebaltab), attrition
├── 03_analyze.do        # main regression specs (reghdfe / ivreg2 as needed)
├── 04_robustness.do     # alt specs, sensitivity
├── 05_tables_figures.do # esttab .tex outputs + graph export PDFs
└── 99_run_all.do        # do "01_clean.do" / do "02_..." / ...

If the paper or data source suggests specific specs (e.g., DiD with reghdfe, IV with ivreg2, RD with rdrobust), tailor 03_analyze.do accordingly.

Phase 2: Execute (unless --no-execute)

For each script in numbered order:

  1. Dispatch to stata-mcp to execute the .do file.
  2. Capture the log (Stata writes to output/NN_log.smcl per the header convention) and the resulting .dta / .tex / .pdf outputs.
  3. If a script fails, first append its specification to the ledger (step 4) with Status failed and the error in Why, then halt — do NOT auto-fix unless the failure is trivial (typo flagged by Stata at parse time). For substantive failures (insufficient observations, singular matrices, missing covariates), surface to the user.
  4. Append every specification each estimation .do file ran — kept, dropped, or failed — to quality_reports/spec-ledger.md, with the same columns, commit stamp and append-only block as /data-analysis Phase 3 ("Specification ledger"). A failed run is a row too, with Status failed and the error in Why.

For long-running scripts (> 2 minutes), use the Monitor tool to stream stdout — same pattern documented in /data-analysis and /audit-reproducibility.

Phase 3: Verify

  1. Confirm every expected output exists in output/.
  2. Check output/sessionInfo_stata.txt was captured (package versions).
  3. Run /audit-reproducibility if a manuscript exists — it reads Stata .dta outputs via haven/pyreadstat.
  4. Report scripts run, outputs produced, any warnings from Stata.

Phase 4 (optional): R cross-check

If --from-r was set, run the R version of the same analysis (assumed to live at scripts/R/) and compare:

  • Point estimates: should match to ~0.01 (per replication-protocol.md tolerance).
  • Standard errors: should match to ~0.05 (clustering df adjustments can differ slightly between Stata and R).
  • Sample sizes: must match exactly.

Discrepancies are surfaced for the user to investigate — typical culprits: clustering df, default options (logit vs probit for PS), bootstrap seed handling.

Companion skills

  • /data-analysis — R analogue. Same pipeline shape, different language.
  • /audit-reproducibility — reads both .rds and .dta outputs. Cross-checks manuscript claims against the produced values.
  • /review-paper — if the paper exists and cites tables/figures produced by this pipeline, /review-paper auto-invokes /audit-reproducibility (per cross-artifact-review.md).

Anti-patterns

  • Hand-editing .dta files. Never. All transformations happen via the .do files; .dta outputs are derived and reproducible.
  • Skipping the 99runall.do. This is the AEA-mandated one-command entry point. Build it even for small projects.
  • Using , robust by default. Use , cluster(id) at the appropriate level — see stata-code-conventions.md §6.
  • Hand-formatting tables in LaTeX. Use esttab and \input{} — see stata-code-conventions.md §4.
  • Pinning Stata version in only one .do file. Every .do file starts with version 18 per the convention.

Cross-references

  • .claude/rules/stata-code-conventions.md — the discipline contract.
  • .claude/rules/replication-protocol.md — tolerance thresholds (applies across R / Stata / Python).
  • stata-mcp on GitHub — the MCP server this skill depends on.
  • AEA Data Editor checklist — replication-package standards.

Long-running fits / batch reruns: use the Monitor tool (Apr 2026)

Long Stata fits (multi-hour bootstrap with cluster bootstrap, large reghdfe with millions of observations, simulation studies) should be background-launched and tailed with the Monitor tool — same pattern as /data-analysis and /audit-reproducibility for R / Python. The .do file logs to SMCL (output/NNlog.smcl). Monitor does not attach to a background job or its stderr: only the stdout of the command you give it becomes events. So run Monitor on a command that tails the log and filters for progress lines and Stata errors, e.g. tail -f output/NNlog.smcl | grep --line-buffered -E '\{err\}|r\([0-9]+\);|', so Claude can react to errors mid-stream (a multi-hour run needs persistent: true, then TaskStop once the job ends).

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