Prompts

Every build module in this course produces at least one prompt worth keeping after the module ends. This page collects them in one place, quoted exactly as they appear in the module notes, with a short note on when to use each one. None of them is special. Each is the specific, front-loaded phrasing the rest of the course argues you should be writing anyway. Treat them as templates, not scripts to paste into a task they weren’t written for.

Module 1 — the four-component makeover

Every prompt on this page rests on one habit: name the file, the operation, the level of aggregation and the output before you hit enter. Module 1 demonstrates it as a before/after pair.

Vague:

Look at this Compustat file and tell me something about leverage.

Specific:

Read funda_1990_2023.csv. For each gvkey-fiscal year, compute book leverage as long-term debt divided by total assets, winsorize it at the 1st and 99th percentiles, and compute the mean by fiscal year and two-digit SIC code. Save the result as leverage_by_industry_year.csv, and save a line figure with one line per two-digit SIC as leverage_trends.png, formatted for a working-paper draft.

Usage note. Before sending any one-off analysis request, check it against the four components — file, operation, aggregation, output. If one is missing, add it. A request that names all four rarely needs a second round to fix a misunderstanding.

Module 2 — the six-part opening prompt

Module 2 extends the four-component habit to a full pipeline by adding a join and a paper trail. Of everything in the module, this prompt is the one you are most likely to reuse. Keep it as a template for any measure you build from a two-table dataset.

DATA: Download the FSDS quarterly zip files for these fourteen quarters — Q4 of each year from 2010 through 2023 — from the SEC’s Financial Statement Data Sets page. From each quarter we need two files: sub.txt (filing metadata: adsh, cik, sic, form, fiscal year end, period) and num.txt (tagged numeric values: adsh, tag, ddate, qtrs, value).

JOIN: Merge sub.txt and num.txt on adsh — the filing’s accession number, the only key that reliably links the two files. State the row count in each file before the join and the row count after, and flag any adsh values in num.txt with no match in sub.txt.

MEASURE: R&D intensity, defined as R&D expense divided by total assets for each filer-period. Use the XBRL tag ResearchAndDevelopmentExpense for the numerator and Assets for the denominator. Keep qtrs = 0 rows for Assets (a balance-sheet snapshot) and qtrs = 4 rows for the R&D tag (a full fiscal year of a flow variable). Restrict to form = 10-K.

AGGREGATION: Compute the median R&D-intensity ratio by two-digit SIC code (sic2, the first two digits of sub.txt’s sic column) and calendar year, across all fourteen quarters.

OUTPUT: One line figure, one line per SIC2 industry, R&D intensity on the y-axis and year on the x-axis, formatted for a working-paper draft — white background, labeled axes, a legend, no default plotting-library styling — saved as rd_intensity.png. Save the underlying aggregated table as rd_intensity_by_sic2_year.csv.

PAPER TRAIL: Write every stage as a named script — no output that exists only as a chat reply. Keep a DECISIONS.md recording every methodological choice as it’s made — which tag was chosen when more than one was available, how duplicate rows were handled, any filter applied and why. Keep a LOG.md with a timestamped line for every major step. Print an attrition row — n before, n after, reason — every time the sample size changes.

Usage note. Adapt this to any two-file, join-on-a-key dataset (a Compustat funda/company-file pull works the same way): fill in your own DATA, JOIN, MEASURE, AGGREGATION and OUTPUT, and keep the PAPER TRAIL clause verbatim. People in a hurry often drop that clause, and it is the part that lets a coauthor rerun a one-off analysis.

Module 2 — the paper-trail request, standalone

The PAPER TRAIL clause above also works on its own. Append it to any prompt that starts a multi-step build, not just the FSDS pipeline it was written for:

Write every stage as a named script — no output that exists only as a chat reply. Keep a DECISIONS.md recording every methodological choice as it’s made — which tag was chosen when more than one was available, how duplicate rows were handled, any filter applied and why. Keep a LOG.md with a timestamped line for every major step. Print an attrition row — n before, n after, reason — every time the sample size changes.

Usage note. Request this in the same prompt that starts the work, not after the analysis is done. A paper trail requested after the fact is reconstructed from memory, which is what Module 1 warns you not to rely on. Module 5 adds the matching check: before you trust any specific claim in these files, compare it with the actual commit history.

Module 3 — the front-loaded EDGAR prompt

Module 3 argues that a better first prompt saves more time than better code. State the operational facts you already know (CIK resolution, the rate limit, the User-Agent requirement) before any script is written, so the agent doesn’t discover them one failed request at a time.

Fetch the Item 1A Risk Factors section from the 10-Ks filed by the CIKs in pinned_ciks.csv, for fiscal years 2021–2023, using the EDGAR full-text search and submissions endpoints. Respect a 10 request/second rate limit and set the User-Agent header to <name>@<institution>.edu on every request. Cache raw filing HTML to data/filings/ so a re-run never re-downloads a file that already succeeded.

Usage note. Use this shape for any EDGAR pull. Name the identifier list, the section or form type, the date range, the two operational facts (rate limit, User-Agent) and the caching requirement, in that order, before you send the prompt.

Module 3 — “why are N missing”

After an extraction pass runs, Module 3 recommends a specific follow-up for the failures instead of re-running the whole pipeline. Ask Claude directly why N filings are missing or flagged. Let it read the cached HTML for those filings and report what is structurally different about them.

Usage note. This works because the raw files are already cached to disk. The agent can inspect the actual failing cases instead of guessing, and you get a diagnosis (a genuine edge case or a fixable regex gap) instead of a re-run. A blunt, specific question works better than a vague “something’s wrong, please investigate.”

Module 4 — the feasibility-assessment prompt

Module 4 asks you to learn this one word for word. The phrasing gets the agent to raise blockers before it commits to a build, instead of running into them mid-pull.

“I want a firm-year panel with leverage and ROA for US industrials 2000–2023 from funda. Tell me what’s involved before you try anything complicated. What might be missing?”

Usage note. Use this before any nontrivial pull or linkage task: a classification job, a cross-dataset join, anything with more than one moving part. It asks the agent to reason about filters, variables and known data-format transitions before it runs a single query, so you learn about problems up front instead of mid-pull.

Module 5 — editor, not rewriter

Module 5 uses this exact prompt live on a real identification paragraph. It gets feedback on the argument while you keep writing the sentences.

Please review this Identification section. I want feedback in the style of
a New York Times editor — sharp on argument and clarity. Do not directly
edit my writing. Instead, insert inline <!-- comments --> at the specific
places where the argument is weak, unclear, or could be tightened. Do not
rewrite any sentences yourself; leave the prose exactly as written and let
the comments carry the feedback.

Usage note. Without “do not,” you get a rewrite back. If you soften the instruction to “comments, and suggestions if you have them,” you are back to accepting a polished rewrite with one click, and you lose the benefit of the prompt. Use this for any meaningful writing (an identification argument, a contribution statement, a limitations section) where you want feedback without handing over the thinking.