Prompting Claude Code

How to talk to the tool effectively

The Core Idea

Claude Code is not Google. You don’t type a keyword and get a link. You are talking to a capable but literal-minded research assistant who has no context about you, your project, or your conventions unless you provide it.

The quality of what Claude produces depends almost entirely on what you tell it. A vague prompt gets a vague answer. A specific prompt gets specific, useful output.

Best external resources

Blattman — Prompt Engineering — The gap between a mediocre AI interaction and a great one is almost always the prompt. Six-section anatomy, worked examples, anti-patterns.
Blattman — Chatbots Done Right — Four levels of context, the “conversations not one-shots” pattern, and what AI is bad at.
Goldsmith-Pinkham — Getting Started with Claude Code — Practical tips on working effectively with Claude Code as a researcher.

Three Properties of a Good Prompt

Every good prompt has three things:

Context — what Claude needs to know about the situation
Task — what you want it to do, in 1–2 sentences
Output — what the result should look like (format, length, audience)

Most bad prompts fail on (1) or (3). The task is usually clear enough; the context and output spec are what people skip.

Bad vs. Good: Examples for Economists

Data analysis

Weak: > “Analyze the trade data.”

Strong: > “Read trade_sample.csv. It has bilateral trade flows (exporter, importer, product code, value, year). Show me the top 10 exporter-importer pairs by total trade value across all years. Use R with data.table.”

The strong version tells Claude what the data looks like, what question to answer, and what tools to use.

Writing a regression

Weak: > “Run a gravity regression.”

Strong: > “Using the panel in output/data/panel_clean.csv, estimate a gravity equation with fixest::feols. The dependent variable is log(trade_value). Include log(distance), contiguity, and common_language as regressors. Use exporter-year and importer-year fixed effects. Cluster standard errors by country-pair. Save the results to output/tables/table1_baseline.tex using etable().”

Reading a paper

Weak: > “Summarize this paper.”

Strong: > “Read papers/head_mayer_2013.pdf. Summarize in 3 paragraphs: (1) the research question, (2) the identification strategy and data, (3) the main findings. Write for an economist who knows trade theory but hasn’t read this paper.”

Fixing code

Weak: > “This doesn’t work.”

Strong: > “The script 03_gravity.R throws an error at line 47: ‘object country_pair not found’. The variable should come from merging trade_sample.csv and distances.csv on exporter + importer. Find the bug and fix it.”

Conversations, Not One-Shots

Claude Code works best as a conversation, not a single question. Build context across turns:

Turn 1: “Read CLAUDE.md and the data files in data/. Summarize what we’re working with.”

Turn 2: “Good. Now clean the trade data: drop rows where value is 0 or missing, create a log_value column. Save to output/data/panel_clean.csv.”

Turn 3: “Run the baseline gravity regression from the CLAUDE.md spec. Show me the output before saving.”

Turn 4: “The distance coefficient looks too small. Can you add country-pair fixed effects and compare?”

Each turn builds on the last. Claude remembers everything from the current session. This is much more effective than cramming everything into one giant prompt.

Give Claude Your Conventions

If you have preferences about how code should look, say so upfront. Claude will follow them consistently within the session:

“For all R code in this project: use data.table, not tidyverse. Use fixest for regressions. Comment sparingly — only where the logic isn’t obvious. Save all output to the output/ folder.”

Better yet, put these in your CLAUDE.md so they persist across sessions. See the CLAUDE.md guide.

What Claude Code Is Bad At

Be honest about the tool’s limitations so you use it well:

Don’t trust Claude for	Do use Claude for
Factual claims about the world	Drafting and editing text
Specific citations (it will invent plausible-sounding papers)	Writing, running, and debugging code
Causal identification strategy	Data cleaning and transformation
Current events or recent data	Explaining code or methods
Mathematical proofs	Format conversion (LaTeX, markdown, tables)
“Is this the right model?”	“Implement this model specification”

Blattman puts it well: “A chatbot is a brilliant, well-read colleague with no memory and a tendency to make things up. Trust the reasoning, verify the facts.”

The key distinction for researchers: Claude can execute your analysis plan excellently. It should not be designing your identification strategy. You are the economist. Claude is the RA.

The Iteration Pattern

The most productive Claude Code workflow is a tight loop:

Ask Claude to do something specific
Review what it produces (read the code, check the output)
Correct what’s wrong (“The standard errors should be clustered by pair, not by country”)
Repeat until you’re satisfied

This is exactly how you’d work with a good research assistant. The difference is that the loop takes seconds instead of days.

Prompting Anti-Patterns

Things that waste your time:

“Be comprehensive” — Claude interprets this as “write as much as possible.” Be specific about what you want instead.
“Be careful” / “Be meticulous” — These cause overthinking and hedging. Just state your requirements.
Pasting a 500-line error log — Give the relevant error message and 5 lines of context. See the context window guide.
Asking Claude to “review the whole project” — This reads every file into context. Ask a specific question: “Is the clustering in 03_gravity.R correct for a gravity model?”
Starting over instead of correcting — If Claude gets something 80% right, correct the 20%. Don’t re-prompt from scratch.

A Starter Prompt Library

Prompts you can copy-paste and adapt:

Starting a session

“Read CLAUDE.md and the files in data/. Summarize the project state and what data is available.”

Picking up where you left off

“Read progress.md and the current state of 03_gravity.R. Summarize where we are before we continue.”

Exploring data

“Read the first 100 rows of trade_sample.csv. Describe the structure: column names, types, number of rows, any obvious data quality issues.”

Writing analysis code

“Write an R script that estimates [specification]. Save the output as [format] to [path]. Use [packages].”

Making figures

“Create a scatter plot of log(trade_value) vs log(distance) with a fitted line. Use ggplot2. Label axes properly. Save as output/figures/fig1_distance.pdf.”

Summarizing results

“Write a one-paragraph summary of the regression results in output/tables/table1.tex. Write for an economics seminar audience. Focus on the distance coefficient and its economic magnitude.”

Ending a session

“Write a summary of what we accomplished today — decisions made, files created, what to do next — and save it to progress.md.”