Claude for Applied Economists

A working script — roughly one hundred pages — that takes a working economist from "I have a messy folder of CSVs and a deadline" to "I delegate the boring 80% and keep the judgment."

This is a script, not a reference manual. It is meant to be read front to back, at a desk, with a terminal open. Every chapter has things to type, dialogues to imitate, and exercises with an answer you can check. The voice is deliberately plain: I am talking to an applied economist — someone who knows their reghdfe from their ivreghdfe, who has fought a panel into shape at midnight, and who has never been paid to be a software engineer and does not intend to start now.

The promise of the script is narrow and honest. Agentic coding tools will not write your paper or have your ideas. They will collapse the time between an idea and a first result from days to minutes, and they will do it in whatever language you already use — Stata, R, Python, Julia, or a pile of shell scripts held together by hope. The skill you are learning is not "prompting." It is delegation under uncertainty: deciding what to hand off, how to specify it, how to check it, and where to keep your hands firmly on the wheel.

Who this is for, and what you will be able to do

This script assumes you are an applied microeconomist, macroeconomist, or empirical researcher in a related field (finance, public health, political economy). You have a laptop, data you are allowed to touch, and at least one project that is behind schedule. You do not need to know what a "context window" is, what Git is for, or what an "MCP server" does. You will by the end.

When you finish the script you will be able to:

• Hand Claude a directory of raw downloads and get back a clean, documented, reproducible panel — and know how to verify it is correct.
• Scrape a website or pull an API (BLS, FRED, Companies House, Eurostat) without writing the scraper yourself, while staying on the right side of terms of service.
• Go from a cleaned dataset to a publication-quality regression table and a robustness appendix in one sitting.
• Draft referee responses, tighten prose in your own voice, and produce a Beamer deck with a non-trivial TikZ figure in minutes.
• Decide before you delegate whether a task needs a written plan, and write one that survives a fresh context window.
• Build a reusable "skill" — a regression-table skill, a referee-response skill — that you and your coauthors invoke by name forever after.
• Use Git as a safety net without memorizing Git, so that no agent and no late-night mistake can destroy three weeks of work.
• Set permissions so the tool physically cannot delete your data, and work safely with confidential, IRB-restricted, or enclave-bound datasets.

That is the whole syllabus. Six substantive parts, a setup chapter, and a capstone. Let us begin where every honest course begins: with the boring setup that everyone wants to skip and no one should.

Part 0 — Setup, and the Mental Model

Two things have to happen before any of the fun. You have to install the tool, and you have to build a correct mental model of what it is. The second matters more than the first. Most economists who bounce off agentic coding do so not because they could not install it but because they carried over a wrong intuition — either "it is autocomplete" (too small) or "it is a colleague who knows my project" (too generous). Neither is right. Spend the forty minutes.

Lesson 0.1 — What this actually is, in economist terms

Think of Claude Code as a very fast research assistant who has read essentially all public code and documentation, has no memory between sessions, cannot see your screen, and will do exactly what you literally asked — including the dumb literal thing — but who can run code, read files, and check its own output if you tell it to. Hold that sentence in your head; everything in this script is a corollary of it.

Unpack it the way you would unpack an identification assumption:

• "Very fast" — a task that is ninety minutes of fiddly reshape and merge for you is ninety seconds for it. This is the entire economic case. Your time is the scarce input; this lowers its shadow price on routine work.
• "Has read essentially all public code" — it knows Stata syntax, the fixest package, pandas idioms, BeautifulSoup, regex, LaTeX, TikZ. You do not have to teach it the language. You have to teach it your problem.
• "No memory between sessions" — close the terminal and it forgets everything except what you wrote down in files. This is why Part 3 (planning) and the CLAUDE.md file exist. Memory is something you engineer, not something you get.
• "Cannot see your screen" — it does not know your variable means a percentage, that wage2 is the deflated one, or that the 1998 wave is unreliable. Unstated context is unavailable context.
• "Will do the dumb literal thing" — ask it to "remove outliers" and it may drop the 1% tails of every variable, including your treatment dummy. The judgment is yours; the typing is its.
• "Can run code and check itself" — this is the superpower most people never switch on. An assistant that can execute summarize after a merge and read the result can catch its own mistakes — if you build verification into the request.

The agent loop (one diagram in words)

Internally the tool runs a loop: it reads your request and the relevant files, decides on an action (run a command, edit a file, search), takes the action, reads the result, and repeats until it believes the task is done. You do not manage the loop. But you should picture it, because two facts fall out of it:

1. It works from what it can see. If the relevant fact is in your head and not in a file or your message, the loop never encounters it. Hence: state the non-obvious.
2. It stops when it thinks it is done, not when you are satisfied. "Done" for the loop means "no error and the request looks addressed." "Done" for you means "correct and defensible in a seminar." Closing that gap is your job, and the script returns to it constantly.

Lesson 0.2 — Installation and your first project folder

Installation specifics change; the official instructions live at the Claude Code documentation site and you should follow whatever is current there. The shape, however, is stable, and the shape is what you need to understand:

• Claude Code is a command-line program. You run it from a terminal, sitting "inside" a folder — your project. It can see and act on files in that folder and its subfolders, and nothing else by default. That boundary is your first and best safety feature; respect it.
• You start it by opening a terminal, cd-ing into your project, and launching it. You then talk to it in plain English. It proposes actions; depending on your permission settings it either asks before each one or runs within limits you set (all of Part 6).
• There is also a web/desktop entry point, but the discipline is identical: it operates on a project, in a working directory, with a permission policy.

Set up a clean sandbox project now. Do not point the tool at your dissertation folder on day one. Make a scratch directory with a copy — never the original — of some non-sensitive data:

mkdir ~/claude-sandbox
cd ~/claude-sandbox
# copy in a NON-confidential, throwaway dataset — a copy, never the original
cp ~/Downloads/some_public_extract.csv ./data_raw.csv

Lesson 0.3 — Your first session: a ten-minute win

Open the tool in ~/claude-sandbox. Here is the script. Type the You lines; the Claude lines show the shape of what comes back so you know whether you are on track.

That is a complete, useful, safe first session, and it teaches the three habits the whole script rests on:

1. Look before you leap. "Don't change anything yet" is the single most valuable phrase you will learn. A profiling pass costs you nothing and tells you whether the tool even understands the data the way you do.
2. Make it show its work. "Show me the commands you ran" converts a black box into something you can audit. You are an empiricist; demand the equivalent of a do-file.
3. Externalize memory. Writing findings to FINDINGS.md means the knowledge survives the session. Next week, in a fresh context with no memory, that file is still there.

Lesson 0.4 — CLAUDE.md: the one file that gives the tool a memory

Because there is no memory between sessions, you create memory by putting durable facts in a file the tool reads automatically: CLAUDE.md in your project root. Treat it as the README you would write for a new RA on their first morning — the things that are true about the project no matter what task is in front of them.

Ask the tool to draft it, then edit it by hand:

A good economist's CLAUDE.md usually contains: the language and why; the directory layout and which directories are read-only; the name of the canonical dataset; variable conventions that are not obvious from names; known data problems and the decisions made about them; and how to run the pipeline end to end. It should not contain task-specific instructions ("now add a control for tenure") — those go in the conversation. The test: would this still be true and useful in six months? If yes, it belongs in CLAUDE.md.

Part 1 — Research Workflows: Cleaning, Scraping, Econometrics

This is the part that pays for the whole script in week one. The claim from the chapter outline is exact: the data cleaning, scraping, and econometric work that "used to take days or weeks" now takes minutes. The catch — and this part is mostly about the catch — is that wrong results also arrive in minutes, and they arrive looking confident. The discipline of this part is: go fast, then verify like the result is going into a top-five submission, because it is.

Lesson 1.1 — Data cleaning in your language

The tool is language-agnostic. The workflow below is shown in Stata, R, and Python so you can use whatever you already use. Nothing here requires you to switch languages, and you should not switch languages to please a tool.

The shape of a cleaning request

A good cleaning request has four parts: the input, the transformations, the output, and the checks. Most economists write the first three and skip the fourth. The fourth is what separates this from a disaster.

Notice the structure. The "drop N rows" log is a cleaning waterfall — the same table you would put in an online appendix. By asking for it as part of the job, you get the audit trail for free and you catch the moment a filter drops 40% of the sample when you expected 4%.

The same job in R

# You: "Same as above but in R, writing data/analysis.rds, using the
# tidyverse, and put the row-count waterfall in logs/01_clean.txt.
# Use a single pipe and stopifnot() for the assertions."
#
# Claude produces something like:
clean <- raw |>
  filter(age >= 25, age <= 64, year != 1998) |>
  mutate(state = recode_states(state),
         wage_r = wage / cpi * cpi_2015) |>
  filter(wage_r > 0, wage_r <= 500)
stopifnot(!any(duplicated(clean[, c("person_id","year")])))

The same job in Python

# You: "Same again in Python with pandas, writing data/analysis.parquet.
# Log the row count after every filter with logging, and assert
# uniqueness on ['person_id','year'] with a clear message."
#
# The point is not the code — it is that you specified the CHECKS,
# so the assertion and the waterfall are in every language version.

Verifying a clean you did not write

You did not type the do-file, so you must audit it as if a first-year RA wrote it — because, in effect, one did. A reliable five-minute audit:

• Read the waterfall. Does every filter drop a plausible number of rows? A surprise is a bug until proven otherwise.
• Spot-check five rows by hand. "Show me person_id 4471 in the raw file and in the cleaned file, side by side, and explain every difference." If you cannot reconcile one person, you do not understand the cleaning.
• Check the joins. Merges are where silent disaster lives. "After the CPI merge, how many rows had no CPI match, and what years were they?" An unmatched year means a wrong deflator means every real-wage result is wrong.
• Re-run from scratch. Delete data/analysis.dta, run only the do-file, confirm it regenerates byte-for-identical. Reproducibility is not a virtue you add later; it is a property you verify now.

Lesson 1.2 — Reshaping, merging, and building panels

Panel construction is the canonical "ninety minutes to ninety seconds" task, and also the canonical place to get burned. The instruction that matters is to make the relational logic explicit, because the tool cannot see your data model — it can only see your columns.

The flagged firms are the whole point. The tool did not "fix" them — you told it to report, not repair. Now you, the economist, decide: bad founding dates? subsidiaries reusing IDs? You make the call and tell it the rule. That division — machine reports anomalies, human makes the structural call — is the template for every merge you will ever delegate.

Lesson 1.3 — Scraping and APIs without writing the scraper

Pulling data from BLS, FRED, Eurostat, the World Bank, SEC EDGAR, or Companies House, or scraping a public table off a webpage, is now a stating-what-you-want exercise. Two responsibilities stay entirely yours and the tool will not raise them for you: legality/terms of service and politeness (rate limits, caching, identifying your requests). State them yourself, every time.

Official APIs first

Three instructions in there are non-negotiable and you must supply them because the tool will not: key from environment, never hardcoded (Part 6); cache raw responses (so a re-run does not re-hammer the API and so you have the immutable raw pull for your appendix); and raw layer separate from tidy layer (so cleaning bugs never force a re-download).

Scraping a web page

The lesson generalizes: the first scraping request should never scrape. It should investigate permission and look for the boring official download that makes scraping unnecessary. Nine times in ten there is one, and the tool will find it faster than you would.

Lesson 1.4 — Reproducible pipelines

You now have cleaning, merging, and pulling scripts. Tie them into one command so that "reproduce the paper" is a single line and so a coauthor (or Reviewer 2, or you in eighteen months) can regenerate everything from raw inputs.

Read the clean target with your own eyes before you ever run it. make clean deleting your raw data because a wildcard was too greedy is a genuine way to lose a project. This is also the first place the script and Part 6 (Safety) touch: a destructive command is exactly the kind of thing you read line by line and run once in a sandbox before trusting.

Lesson 1.5 — Econometric analysis and tables

From a clean panel to results is the highest-leverage delegation in the script, and the one where your judgment is least substitutable. The tool knows the syntax of every estimator. It does not know whether the estimator answers your question. You keep that entirely.

"Do not interpret the results; just show me the table and the exact commands." Say this every time. You do not want a language model's opinion about your coefficient; you want the number and the code that produced it, so that the interpretation is yours and is defensible. The model is a faster Stata, not a coauthor.

Robustness as a single delegated batch

Robustness tables are pure delegation gold: tedious, mechanical, and you know exactly what you want. Specify the grid; let it grind.

Lesson 1.6 — Debugging your own code

You can also point it at code you wrote that is broken. The effective pattern is not "fix this" — it is "diagnose, hypothesize, then fix the smallest thing."

"Don't fix it yet — diagnose first" prevents the single most common failure mode: the tool rewriting half your working code to make one error disappear, introducing three subtler errors you will not notice until the referee does. Diagnose, confirm the diagnosis yourself, then authorize the smallest possible fix, then read the diff. That sentence is most of what debugging-by-delegation is.

Part 2 — Writing with AI, and Beamer

Coding is half of empirical work. The other half is writing and thinking — the introduction that frames the contribution, the referee response that saves the paper, the slide deck that has to land in a job talk. The chapter outline puts it precisely: the goal is to write in your voice, to accelerate referee responses, and to generate beautiful Beamer decks with complex TikZ figures in seconds. The danger is equally precise and you must internalize it before you touch the tool: a language model writing your prose with no constraint produces fluent, confident, generic text — and generic confident text is exactly what gets a paper rejected. Everything in this part is about keeping the thinking yours while delegating the typing, the formatting, and the mechanical revision.

Lesson 2.1 — Writing in your voice

The default register of an unconstrained model is bland consultant-English: hedged, list-happy, fond of "moreover" and "it is important to note." That is not your voice and it is not a good academic voice. You fix this not by asking nicely for "good writing" but by giving it your actual writing as the specification.

You have just built a reusable style specification — the writing analogue of CLAUDE.md. Reference writing/STYLE.md in every drafting request. It is the difference between text that sounds like everyone and text that sounds like you, and it is the single highest-return ten minutes in this part.

Lesson 2.2 — Drafting, tightening, and editing

The model is far better at transforming text you have already thought through than at generating thought. So generate the thought yourself — even badly — and delegate the transformation.

The brain-dump method

Talk or type the argument out, ugly and unstructured, in your own words. Then:

The [SHARPEN?] markers are the feature, not the friction. They point exactly at the places where you have not finished thinking — which no model can do for you. Editing-by-delegation is most valuable when it surfaces the holes in your argument instead of smoothing them over.

Tightening on command

Concrete, measurable editing instructions work; vague ones produce vague edits.

• "Cut this 240-word paragraph to under 120 words. Remove hedging. Keep every numeric claim. Do not merge it with the next paragraph."
• "This abstract is 210 words; the journal limit is 150. Cut to 148 without losing the result or the contribution sentence. Show me what you removed."
• "Find every sentence over 40 words and offer a shorter rewrite, side by side. Change nothing else."

Lesson 2.3 — Responding to referees

The referee response is where this part earns its keep. The work is high-stakes, emotionally taxing, and largely mechanical scaffolding around a few real intellectual decisions. Delegate the scaffolding; keep the decisions.

This is the canonical division of labour for the whole script, stated in its sharpest form. The triage (mechanical, the model is good and fast at it) is delegated. The minor responses (formulaic) are delegated with placeholders. The identification responses — the ones that decide whether the paper survives — you write yourself, because that is the part that is actually your job and the part a model cannot do without inventing. Use the saved hours on those.

Lesson 2.4 — Beamer decks and TikZ figures

Beamer and TikZ are the perfect delegation target: the output is mechanically verifiable (it either compiles and looks right or it does not), the syntax is fiddly and universal, and your judgment is about content and emphasis, not about whether you remembered the \node[draw,circle] incantation.

"Compile it and fix errors until it builds clean" is the instruction that turns LaTeX from a time sink into a non-event. You are not asking the model to be right about LaTeX; you are asking it to iterate against the compiler until the compiler is satisfied — verification it can do without you.

A non-trivial TikZ figure from a description

Part 3 — Research Judgment: Planning Before Delegation

This is the most intellectually important part of the script and the one with the least typing. The chapter outline frames it exactly: a common practice in agentic coding is to write a plan before doing the work, primarily to preserve the context window — and the real skill is knowing when this is worth doing and how to do it well. Planning is not bureaucracy. It is the mechanism by which you keep the judgment while delegating the labour, and it is the antidote to the structural weakness from Part 0: no memory between sessions, stops when it thinks it is done.

Lesson 3.1 — When planning is worth it (and when it is overhead)

Not everything needs a plan. Forcing a plan onto a thirty-second task is its own kind of waste. Use this decision rule, which is just expected-cost reasoning you already do instinctively for RA tasks:

The deep reason the left column wins is the Part 0 law restated: the loop "stops when it thinks it is done." On a large or ambiguous task, the model's notion of done and yours diverge badly. A plan is a contract that re-aligns them before any irreversible work happens — and crucially, before the cost of being wrong has been paid.

Lesson 3.2 — The cost of context, and why plans are written to a file

The model has a finite working memory (the "context window"). A long, exploratory session fills it with dead ends, abandoned attempts, and noise. As it fills, quality degrades — the model loses the thread exactly as a tired RA would at hour nine. Planning fights this two ways: it does the expensive thinking once, while context is clean; and it writes the conclusion to a file, so the plan survives into a fresh session where the model is sharp again.

Lesson 3.3 — Writing a plan that survives a fresh context

Use plan mode (or simply: "Do not change anything. Investigate, then propose a plan."). A plan good enough to execute from cold has six parts:

1. Goal — one sentence, in terms of the research output, not the code.
2. Inputs and the data model — exact files, keys, the relational logic the model cannot see.
3. Steps — ordered, each producing a checkable artifact.
4. Checks — for each step, how we will know it is correct (the match rate, the assertion, the expected N).
5. Decisions already made — the identification choices, sample restrictions, conventions that are yours and not up for the model to revisit.
6. Out of scope / do not touch — explicitly, including data_raw/.

"Execute steps 1–3 only… do not start step 4" is deliberate. You are converting the model's open-ended loop into a series of small, checkpointed delegations, each with a verification gate you control. The plan made the work legible; the step-gating keeps the judgment yours throughout execution rather than only at the end.

Lesson 3.4 — Knowing when the model is wrong

Planning surfaces wrongness early, but you still need the instinct. The model is most dangerous when it is confidently plausible. Calibrate your suspicion by domain:

The pattern: trust it on the verifiable and mechanical; distrust it on the inferential and the unverifiable. The right column is, not coincidentally, the list of things that constitute economic expertise. The tool does not erode the value of that expertise — it concentrates your day onto it.

Part 4 — Reusable Systems: Skills, MCPs, Subagents

The chapter outline calls skills "the foundational agentic coding topic of greatest use to economists," and that is right for one reason: research is repetition. You build the same regression table, run the same referee triage, produce the same summary-stats panel, every project, for years. A skill turns a workflow you have already perfected into a one-word command that you and your coauthors invoke forever after. Subagents let you fan that work out in parallel; MCP servers connect the tool to your data sources. Together they convert one-off cleverness into durable infrastructure.

Lesson 4.1 — What a skill is, and using one

A skill is a named, reusable instruction package: a folder with a description of when to use it and step-by-step guidance the tool follows when you invoke it. You trigger it by name (typically /name). Think of it as a do-file for process rather than for data — a codified standard operating procedure. Installing a skill is just placing its folder where the tool looks for skills; from then on it is available in every session in that project.

Lesson 4.2 — Build your own: a regression-table skill

You will get more from one skill you built for your own workflow than from fifty generic ones. Build the regression-table skill, because every empirical economist needs it and it makes the abstraction concrete.

What you have actually built is a codified standard. Your house regression-table style is now executable and consistent across every paper, every coauthor, every RA — and it embeds your safety rule ("always summarize the sample first, never interpret"). That is the real payoff: skills are how you make your judgment reusable, not just your code. Good starter skills for an economist: regtable, summstats, referee-triage (from Part 2), clean-waterfall (the logged-cleaning pattern from Part 1), beamer-deck, repro-check (delete generated files and rebuild from raw).

Lesson 4.3 — MCP servers: connecting the tool to data sources

An MCP server is a connector that gives the tool a structured, governed channel to a system — a database, a data vendor's API, a documentation source — instead of you exporting CSVs by hand. For economists the common cases are: a connector to a statistical-data API so series can be pulled by name with provenance; a connector to a SQL warehouse so the tool can query (read-only, by your design) rather than you round-tripping extracts; a connector to a documentation source so it cites real docs rather than recalling them imperfectly.

Lesson 4.4 — Subagents for parallel research

A subagent is a fresh, isolated worker the main session dispatches to do a self-contained job and report back a summary. The two economist use-cases are parallelism (independent jobs at once) and context hygiene (a noisy search happens in the subagent and only the clean answer returns to your main session — directly the Part 3 context-cost concern).

This is Part 1's robustness batch and Part 3's context discipline combining: the slow, log-heavy work is fanned out and isolated, while your main session stays clean and sharp for the decisions only you make.

Part 5 — Version Control: Git, Branches, Collaboration

The chapter outline states the stakes bluntly: agentic coding shifts Git "from an optional nuisance to an absolute necessity." Here is why, with no hand-waving. You are now authorizing a fast agent to modify many files quickly. Without version control, a wrong delegation silently overwrites three weeks of work and there is no undo. With version control, every state of your project is a place you can instantly return to, and "the agent broke something" becomes a thirty-second recovery instead of a catastrophe. You do not need to love Git. You need it to be your seatbelt, and you can let the tool operate most of it.

Lesson 5.1 — Why Git is now non-negotiable

Three properties of agentic work make Git mandatory rather than optional:

• Speed of change. The agent can touch twenty files before you finish your coffee. Frequent commits are restore points between those bursts.
• Delegated edits you did not type. A commit is the clean diff you review to see exactly what the agent changed — your audit log. "Show me the diff" (Part 1's debugging rule) only works if there is a committed baseline to diff against.
• Fearless experiments. A branch lets you try a risky reanalysis knowing the main line is untouched and one command away.

Lesson 5.2 — Git without memorizing Git

You can drive Git through the tool in plain English while keeping the dangerous parts under your own hand. The everyday loop:

Lesson 5.3 — Branches: fearless experiments

A branch is a parallel universe of your project. Use one for anything you are not sure about — a referee's demanded reanalysis, a different identification strategy, a risky refactor. If it works, keep it; if it does not, abandon it and the main line never knew.

You can now show your coauthor both results and decide together, with neither version overwriting the other. That is the entire emotional case for branches: they make consequential experiments cheap and reversible, which is exactly the property the rest of this script keeps insisting on.

Lesson 5.4 — Collaboration and recovery

With coauthors, the same tool can explain state and resolve conflicts in plain English: "A coauthor pushed changes; pull them and tell me in plain words what they changed and whether it conflicts with my uncommitted work — do not overwrite anything of mine." And recovery — the reason the seatbelt exists:

Part 6 — Safety: Permissions and Sensitive Data

The chapter outline is exact: set up permissions so the tool cannot accidentally delete your data, and adopt real strategies for sensitive or restricted data. This part is last because it presumes everything before it, and first in importance because economists work with data they are legally and ethically responsible for — IRB-restricted, DUA-bound, confidential firm or administrative microdata. A leaked or destroyed restricted dataset is not a bug; it is a breach. Read this part twice.

Lesson 6.1 — The permission model

The tool runs under a permission policy you set. The spectrum runs from "ask me before every action" (slow, maximally safe) through "auto-allow a named safe set, ask for the rest" (the sweet spot for most research work) to "broadly autonomous" (appropriate only in a disposable sandbox with no real data). Two structural facts make this manageable:

• The working directory is a boundary. By default the tool acts within the project folder. Keeping confidential originals outside the project the tool runs in is itself a control — possibly the strongest one you have.
• Permissions are configurable per project. Your sandbox can be permissive; your project sitting next to confidential microdata is locked down. Match the policy to the blast radius.

Lesson 6.2 — Making it physically unable to delete your data

Permissions are layer one. The robust protections are structural, and you have already been practising them since page one of this script:

1. Originals are read-only and outside the project. What the agent never sees, it can never destroy. The project gets a copy; the source of truth lives elsewhere, ideally on a path the project does not even reference.
2. Operating-system read-only permissions on raw data. Set data_raw/ read-only at the filesystem level (e.g. chmod -R a-w data_raw). Now even a correctly-formed delete command fails. Belt and braces.
3. Git is the time machine. Everything not gitignored has a history (Part 5). Frequent commits make destruction recoverable.
4. An untouched backup that the workflow never references. A copy on separate storage that no script and no agent path points at. The backup you cannot reach from the project is the backup that survives the project.

Lesson 6.3 — Sensitive, restricted, and enclave data

This is the part with legal weight. Categories and the rule for each:

The synthetic-fixture pattern

This is how you get the full speed of the tool with zero exposure of restricted data. You never show it the real data; you show it a fake with the same shape.

You get the speed; the restricted data never enters a prompt, never crosses the network, never leaves the room. This single pattern reconciles "minutes instead of weeks" with "I am legally responsible for this data." Make it your default for anything non-public.

Lesson 6.4 — Secrets, keys, and .gitignore

API keys, database passwords, signed data-download URLs: keep them in environment variables or an untracked secrets file, never in code, prompts, or commits. This closes the loop with Parts 1 and 5 — every API script in Part 1 read its key from the environment for exactly this reason.

• Secrets live in .env (or your OS keychain). .env is in .gitignore from the first commit.
• Code reads os.environ[...] / Sys.getenv(...) — never a literal.
• Standing instruction: "Never hardcode a credential; never print one to a log; never include one in a commit. If you need a secret, read it from the environment and tell me which variable you expect."
• Before any push, the staged-list review (Part 5) is also your last secret check.

Lesson 6.5 — The safety checklist

Pin this. Run it at the start of any project that touches data you would be unhappy to lose or leak.

• Originals are copied; the project works on copies; the source of truth is read-only and outside the project.
• data_raw/ is filesystem read-only (chmod -R a-w).
• An untouched backup exists on separate storage that no script or agent path references.
• Git is initialised; .gitignore excludes raw data, large files, and .env; I have eyeballed the staged list.
• Permission policy: read-only auto-allowed; deletions/overwrites/network/force-ops require my explicit confirmation; no autonomous mode near real data.
• Data classified (public / confidential-local / IRB / enclave) and the matching rule written into CLAUDE.md.
• For non-public data: a synthetic fixture exists; code is developed against the fixture; real runs are local with no external transmission.
• No secret is in any file Git tracks; credentials are read from the environment only.
• I have re-read my DUA / IRB / enclave rules and confirmed nothing in my workflow violates them.

Capstone — The Whole Script in One Project

One project that exercises every part. Pick a real research question you can answer with public data.

1. Safety first (Part 6): set up the project with read-only originals, .gitignore, permission posture, and a CLAUDE.md data-handling rule — before writing any code.
2. Version control (Part 5): initialise Git; commit the empty scaffold.
3. Plan (Part 3): write a six-part PLAN.md; resolve every [CONFIRM]; fill "decisions already made" with your own identification choices.
4. Workflows (Part 1): from a fresh session, execute the plan with step-gating — pull (cached), clean (logged waterfall), panel (reported match rate), main + robustness tables. Commit after each green step.
5. Reusable systems (Part 4): build and use a regtable skill; run the robustness batch as parallel subagents.
6. Writing (Part 2): build STYLE.md; draft the results section by the brain-dump + [SHARPEN?] method; produce a compiling Beamer deck with one TikZ figure.
7. Prove reproducibility: delete every generated file; make all rebuilds everything from raw with no manual step. This passing is the capstone.
8. Final judgement pass (all parts): read every diff, every table, every slide, every prose claim. Confirm there is no fabricated citation, no undefended identification, no point silently dropped, no secret committed, no restricted data exposed. Sign off only when you would defend all of it in a seminar.

Appendix A — Prompt Patterns Cheat Sheet

Appendix B — Language Quick Recipes

The same delegated task, three languages, to prove language-agnosticism. In every case you supply the check; only the syntax differs.

• Stata: "…after cleaning, assert no dup id year; tab year; write step Ns to a log."
• R: "…stopifnot(!any(duplicated(...))); count(year); write the waterfall to a txt."
• Python: "…assert df.duplicated(['id','year']).sum()==0; log row count after each filter."

Appendix C — Glossary

Appendix D — A Four-Week Schedule

• Week 1: Part 0 + Part 1. Daily: one real cleaning/merge task from a live project, with a logged waterfall and a hand-reconciled observation.
• Week 2: Part 2 + Part 3. Build STYLE.md and a PLAN.md for a real task; execute it step-gated from a fresh session.
• Week 3: Part 4 + Part 5. Build two skills you will actually reuse; put your live project under Git with a clean .gitignore.
• Week 4: Part 6 + Capstone. Run the safety checklist against your real project; complete the capstone over the final weekend.

Closing — The Skill You Actually Learned

Nothing in these hundred-odd pages was about prompting tricks. The through-line, stated once more because it is the only thing worth remembering: you delegate the typing, the formatting, the mechanical search, the boilerplate, and the fiddly syntax; you keep — entirely and without apology — the identification, the interpretation, the data-handling responsibility, the destructive decisions, and the final judgement. The tool collapses the cost of the first list to near zero. That does not make the second list less valuable. It makes it the entire job. Go and use the hours you just got back on the work only an economist can do.