Why local context, concrete examples, and iterative correction shape the work.
The tool is technically capable but locally ignorant. It can read files, edit them, and run commands, but at the start of a session it does not know what the files mean, which columns matter, what counts as a mistake, or what a finished result should look like in your work. Leave those things implicit and it fills the gap with a guess, which is why effective prompts usually read like work instructions: name the files, say what should change, and say what should stay the same.
A workable opening request usually names the material you are starting from, the result you want, and the constraints the tool is least likely to infer correctly on its own. If you are precise at the outset, you avoid guesses you would otherwise have to clean up later.
"Clean up this spreadsheet."
"In survey_responses.csv, standardize the date column to YYYY-MM-DD, remove rows where the consent field is blank, and split the 'name' column into 'first_name' and 'last_name'. Save the result as survey_cleaned.csv."
The vague version forces the tool to supply its own interpretation of "clean up," and its interpretation will be generic. You can name a specific tool or library when it matters. Usually it is clearer to describe the result in enough detail that the tool can work toward something visible.
Sometimes the goal is clear but the specification is still loose. In that situation, ask the tool to help define the task before it starts building anything.
A tool like this will usually ask the questions the task was already waiting for: which file has the data, which fields matter, whether the result should be interactive or static, what exactly needs comparing. You answer those questions, and the answers become the specification. Those questions often expose decisions you had not thought to make yet. It helps to ask before any code gets written.
Examples do more than illustrate a task. They specify it, with structure and formatting rules that would take a paragraph to describe and that the tool might still misread from description alone. When I have an existing file that shows the right format, I point the tool at it; the result is usually more consistent than anything I could get from a written specification.
"Create a summary table with columns for author, year, journal, sample size, and key finding. Sort by year. Use APA-style author names."
"Here's a summary table I started by hand: @extraction_example.csv. It has five rows filled in. Continue with the remaining articles in screened_articles.csv, following the same format and column structure."
The contrast is sharpest in tables and structured output. A single finished row shows the format, columns, and logic together. A written specification often cannot.
Most sessions proceed through successive approximations. One request leads to a first pass, then you correct, narrow, or extend it. The opening prompt sets the direction. In the follow-ups, you find out whether the tool understood the task you thought you had stated clearly.
The opening prompt rarely produces the final result. Most of the specification happens in the corrections.
After the tool gives you something, your response is usually some version of redirect, narrow, expand, question, undo, or probe. They work here roughly the way they would with a research assistant: you look at the result, say what is wrong or what should happen next, and the tool adjusts.
The output went in a direction you didn't want.
The broad strokes are right. Focus on a specific part.
What worked for one case should apply to more.
Something about the output doesn't look right.
Too much changed at once, or the wrong thing changed.
Ask what it did so you can evaluate the work.
Ask the tool to explain what it did. The explanation tells you what the tool thought you meant. When that differs from what you intended, the error is one you can correct.
A researcher is preparing screening data for analysis.
The researcher's sense of what to ask next is sharper once the data is visible. The first prompt did not need to anticipate the bar chart. It put the data in front of her, and she could see what to ask next.
Sometimes a conversation stops being productive. The tool starts circling, or each correction somehow leaves the next response worse than the last. By that point, the session has accumulated old directions, partial fixes, and discarded ideas. Starting over is often easier than continuing through that.
If you've corrected the same issue twice and it is still wrong, stop and restart. Starting a new conversation costs very little, and the second attempt is usually better because the first one has already shown you what the tool misunderstood and which constraints mattered. Fold those lessons into a new opening prompt.
When a conversation goes well, save the prompts that held up (or at least the ones that produced a reliable starting point) in a note or text file. When the task returns, reuse them and change only the parts that have changed.
CLAUDE.md for Project-Level ContextIf you keep repeating the same background information at the start of every conversation ("we use YYYY-MM-DD for dates," "author names should be Last, First," "output files go in the /results folder"), that information belongs in a project file. In Claude Code, that file is CLAUDE.md. The tool reads it at the start of every session, so you do not need to restate it each time. Keep it short. A few lines about conventions and preferences usually help more than a long document the tool is unlikely to follow closely. The CLAUDE.md guide develops that pattern more fully.
If a pattern comes up regularly (processing a particular kind of file, formatting records for a particular system), you can package the instructions as a reusable workflow. Claude Code does this through skills. Start with prompts. When you find yourself restating the same conventions, write them into a project file. When the same procedure keeps recurring, save it as a skill.
The overhead of spelling things out is lower once you build up project-level context and reusable patterns. Early sessions need more explicit prompting because you and the tool have not yet established shared conventions. Over time, you turn the prompts that worked into templates and write repeated constraints into project files. With each new session, you reuse more of what you already wrote down. After enough sessions, you stop restating the same conventions, because they are already in a place the tool will read.