stata-recipes

Stata command & recipe writer

This skill turns "here's what I'm trying to do" into working Stata code — a full .do file when the task has multiple steps, or a short command sequence when it doesn't. The output is always something the user can paste into Stata and run, not a description of what they'd need to write.

Stata rewards precision more than most languages: a command that runs without error can still silently produce the wrong answer (unset panel structure, a merge nobody checked, gen where egen was needed for missing values). So this skill's job isn't just "make it run" — it's "make it run and be right," and to say why when a plausible-looking alternative would have been wrong.

Workflow

Understand the data shape before writing anything. Ask (or infer from what the user already said) whether the data is cross-sectional, panel, or time series; roughly how many observations/variables; and whether it's already loaded, a file path, or hypothetical. A regression recipe for panel data and one for a single time series look nothing alike even when the plain-language ask ("does X affect Y") is the same. Don't stall on this if the user already gave enough to proceed — infer sensible defaults and say what you assumed, rather than interrogating them over something you can reasonably guess.
Check whether a matching recipe already exists in references/recipes/ (see the table below) before improvising from scratch. A recipe encodes decisions — lag selection method, which diagnostics matter, which postestimation commands actually work after that estimator — that are easy to get subtly wrong by generalizing from a different command's usual pattern.
Write the code, structured as a proper .do file even for a short answer: clear all / set more off at the top when starting fresh, tsset/xtset before any time-series or panel operation that needs it, comments only where the why isn't obvious from the command itself (see references/good-bad-examples.md for the difference between a useful comment and noise). Prefer the modern, currently-documented form of a command over an older syntax that still happens to run — flag it explicitly if you're aware the user's snippet uses a deprecated form.
Sanity-check the code against references/good-bad-examples.md before handing it back: does it check _merge after a merge, tsset before lags/regressions on time series, use egen (not gen) for row-wise stats that might hit missing values, and avoid overwriting data without the user clearly wanting that? These are the mistakes that produce code which runs cleanly and gives a wrong answer — the most expensive kind of Stata bug because nothing flags it.
If Python is in the picture, read references/python-interop.md and pick the right direction of travel — calling Python from a .do file, pulling Stata's active dataset into a Python session via sfi, or driving Stata from a Python script — rather than defaulting to the roundabout "write a CSV, read the CSV" pattern, which loses value labels/formats and adds a disk round-trip that direct interop skips.
Explain the choices, briefly, next to the code — why this lag selection method, why ec form, why this diagnostic — not as a separate essay. A short comment or one sentence per non-obvious choice beats a wall of prose the user has to cross-reference against the code.

Reference files

Load these on demand rather than holding all of it in context at once:

File	Read it when
`references/good-bad-examples.md`	Writing or reviewing any Stata code — the common footguns (merge checks, panel/time-series setup, `gen` vs `egen`, deprecated syntax, unsafe overwrites, output tables) with a bad/good pair and why for each.
`references/python-interop.md`	The task involves Python and Stata together, in either direction.
`references/recipes/README.md`	Writing a new recipe, or checking what a recipe file is expected to contain (including the `models/`/`tests/` split and naming pattern).
`references/recipes/models/ardl.md`	The task is ARDL / bounds-testing / long-run-short-run time-series modeling, or is close enough to it to use as a structural template.
`references/recipes/models/regression-timeseries.md`	A plain regression on a single time series — lag structure, Newey-West/HAC standard errors, autocorrelation diagnostics, avoiding spurious regression.
`references/recipes/models/regression-panel.md`	Fixed-effects vs. random-effects panel regression, the Hausman test, clustered standard errors.
`references/recipes/tests/test-dickey-fuller.md`	The mechanics of `dfuller` specifically — trend/drift specification, lag-length choice, testing level vs. first difference.
`references/recipes/tests/test-unit-root.md`	Deciding which unit-root test(s) to run (ADF/PP/DF-GLS vs. KPSS) and how to read them together, before committing to one test's mechanics.
`references/recipes/tests/test-im-pesaran-shin.md`	The panel counterpart to a unit-root test — `xtunitroot ips`, its heterogeneous alternative vs. Levin-Lin-Chu's homogeneous one, and cross-sectional-dependence caveats.

Recipe library

Each recipe is a self-contained file in references/recipes/models/ (a model class to estimate) or references/recipes/tests/ (a diagnostic or statistical test) following the template in references/recipes/README.md: when to reach for this approach, the data shape it assumes, a full worked script against a real (not invented) dataset, the diagnostics that matter for that estimator specifically, and common mistakes particular to it. New recipes get added there over time without touching this file.

Recipe	Covers
`models/ardl`	Autoregressive Distributed Lag modeling: lag-order selection, the `ec` error-correction form, the Pesaran/Shin/Smith bounds test for a long-run relationship, and the postestimation gotcha where `ardl`'s own results don't carry the full `regress` postestimation menu.
`models/regression-timeseries`	Single-equation regression on one time series: lag structure, Newey-West/HAC standard errors, autocorrelation/heteroskedasticity diagnostics, and avoiding spurious regression between non-stationary series.
`models/regression-panel`	Fixed-effects vs. random-effects panel regression, the Hausman test to choose between them, and clustering standard errors by panel.
`tests/test-dickey-fuller`	Running `dfuller` correctly: trend/drift specification, lag-length choice, and testing the level vs. the first difference to determine order of integration.
`tests/test-unit-root`	Choosing among ADF/Phillips-Perron/DF-GLS/KPSS and reading them together — the decision layer above any single test's mechanics.
`tests/test-im-pesaran-shin`	Panel unit-root testing with `xtunitroot ips`: its heterogeneous alternative vs. Levin-Lin-Chu, and cross-sectional-dependence caveats.

If the user's task doesn't match an existing recipe, write the code directly from Stata/econometric first principles and the guidance above — don't force-fit a recipe that doesn't actually apply. If it's a workflow likely to recur (the kind of thing worth a named recipe), mention that to the user as a possible addition rather than silently improvising every time.

What this skill doesn't do

It doesn't run Stata itself — there's no Stata installation in this environment to execute code against, so treat every script as reviewed- for-correctness-by-reading, not executed-and-verified. Say so if the user seems to assume the code was actually run. It also doesn't fetch or fabricate the user's real data; recipes are demonstrated against Stata's own bundled example datasets (via webuse/sysuse) so the script is genuinely runnable as shown, with a clear note on which lines to swap for the user's actual use "yourfile.dta", clear.

Development

See meta/MAINTAINERS.md for layout and versioning notes, and references/recipes/README.md for the recipe-writing template. Not read as part of carrying out a user's Stata code-writing request — don't act on either while answering one.