# Stata Recipes

> Turns a plain-language description of a data/statistics task into correct, runnable Stata code — a .do file or command sequence, not pseudocode. Use this whenever the user asks how to do something in Stata, wants a Stata command or .do file written or fixed, mentions Stata alongside a modeling task (regression, panel data, time series, ARDL, fixed effects, diff-in-diff, matching, etc.), or wants Stata and Python working together (running Python from inside a .do file, pulling Stata's dataset into pandas, or driving Stata from a Python script via pystata/stata_setup or batch mode). Also trigger when the user pastes Stata code that errors or gives wrong-looking results and wants it debugged, or asks 'is this good Stata style' / 'what's wrong with this command'. Covers a growing library of named recipes for common econometric workflows (ARDL modeling shipped now; more added over time) that produce a ready-to-run script, not just an explanation.

- Skill: `sugatoray/stata-recipes` (Agent Skill, multi-file: 16 files)
- Install (CLI): `npx skillmds@latest add sugatoray/stata-recipes`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sugatoray/stata-recipes/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Data & Analytics
- License: MIT
- Author: sugatoray (https://skillmd.com/u/sugatoray)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sugatoray/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

1. **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.

2. **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.

3. **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.

4. **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.

5. **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.

6. **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`](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`](references/python-interop.md) | The task involves Python and Stata together, in either direction. |
| [`references/recipes/README.md`](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`](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`](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`](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`](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`](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`](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`](references/recipes/models/ardl.md) | 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`](references/recipes/models/regression-timeseries.md) | 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`](references/recipes/models/regression-panel.md) | Fixed-effects vs. random-effects panel regression, the Hausman test to choose between them, and clustering standard errors by panel. |
| [`tests/test-dickey-fuller`](references/recipes/tests/test-dickey-fuller.md) | 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`](references/recipes/tests/test-unit-root.md) | 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`](references/recipes/tests/test-im-pesaran-shin.md) | 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.