Prompting for planning vs execution
Universal prompting rules, prompting for planning vs implementation vs research, describing behavior rather than keystrokes, and common mistakes.
The previous guides cover the tools and systems. This one covers how to talk to Claude effectively when using them. The difference between a prompt that produces useful output on the first try and one that requires two rounds of correction is not length or detail. It is structure: what you lead with, what you include, what you leave out, and how you frame what you want back.
The advice differs depending on what you are doing. Prompting for planning and discovery work has a different shape than prompting for implementation work. Both differ from prompting for research or investigation. This guide covers all three and explains why they diverge.
The Universal Rules
These apply regardless of what kind of work you are doing.
Lead with the goal, not the backstory
Claude reads your prompt top to bottom. If the first sentence is context (“I have been working on this feature for a while and we had a meeting last week where someone mentioned…”), Claude anchors on the context and tries to figure out the goal. If the first sentence is the goal (“Add a CarliEnabled guard to the Pending Estimates decision”), Claude orients immediately and treats everything after as supporting detail.
Bad: “So we have this queue called Pending Estimates and it is part of the workflow routing system. UVW Lite sites should not be entering this queue because they do not use Carli. Can you look at the decision class and figure out where to add the check?”
Good: “UVW Lite vehicles should never enter the Pending Estimates queue. Add the appropriate guard to prevent this. The existing queue transition decisions already have guards for similar cases.”
The good version states the behavioral requirement up front, gives Claude enough direction to find the right code, and lets Claude figure out the mechanics. The bad version buries the goal in a paragraph of context that Claude has to parse before it knows what it is doing.
Specify the response format
If you do not tell Claude what shape the answer should take, it picks one. Often it picks a longer, more exploratory shape than you needed. “Summarize in under 200 words” or “return a bulleted list” or “give me the file path and the line number, nothing else” all produce tighter output.
This matters more than it seems, especially in longer sessions. Every response Claude generates becomes part of the context. A 500-word answer when you needed 50 words is 450 words of noise that will compete for attention on every subsequent turn.
Tell Claude what it already knows
This sounds counterintuitive, but it is one of the most effective techniques. If Claude has relevant context loaded (from CLAUDE.md, from prior turns, from a file it read earlier), referencing it explicitly in your prompt makes Claude use it rather than re-derive it.
“Use the same pattern from OdometerUpdateCommandHandler that you found earlier” is better than “figure out the right pattern for event publishing.” The first version anchors on known-good information. The second version risks Claude searching again and potentially finding a different, less appropriate pattern.
Break compound requests into steps when the order matters
“Create the migration script, update the pipeline YAML, and add the feature toggle config” is three independent tasks and Claude can handle them in any order. That is fine as a single prompt.
“Research how the queue routing works, then based on what you find, design the guard, then implement it” is sequential. Each step depends on the output of the previous one. Prompting this as a single request forces Claude to hold the entire chain in one pass, which works for short chains but degrades for anything with more than two or three dependencies. Give it the first step, review the output, then give it the next step with what you learned. You get better results and you maintain control over the direction.
Do not over-explain what Claude can see
If Claude has already read a file, you do not need to re-explain the file’s contents in your prompt. “The handler at line 45 does X and then Y and then Z, so modify it to also do W” is worse than “modify the handler at line 45 to also do W after the existing Z step.” Claude can read the file. Your prompt should reference it, not re-narrate it.
The exception: when the file is large and the relevant section is buried. In that case, a one-sentence pointer (“the relevant logic is in DetermineTargetQueue at line 160, not the earlier GetQueueForSpecialAccounts”) saves Claude from anchoring on the wrong section.
Prompting for Planning and Discovery
Planning and discovery work is about producing specifications, not code. The output is a story, a task spec, a feature breakdown, or a discovery report. The prompting style that works here is fundamentally different from implementation because the goal is precision of description rather than precision of execution.
Ask questions before asserting answers
The planning system’s interrogatory process is built around a specific principle: search the codebase before asking the developer, and ask the developer before assuming. The same principle applies to how you prompt when doing planning work.
Instead of: “Write a story for adding a retry policy to the Service Bus consumer.”
Try: “I need to add retry handling to the Service Bus consumer in inspection-workflow. Before writing anything, research how existing consumers in the repo handle retries. Check if there is a shared retry policy, a per-consumer configuration, or something else. Come back with what you found and what questions remain before we can write the spec.”
The second version produces a discovery pass first, which almost always surfaces details the first version would have guessed at. The interrogatory process exists because specifications built on assumptions need rework later. Specifications built on discovered facts do not.
Be precise about what kind of precision you need
Planning work demands exact values for things that cannot be guessed: property names, database column names, toggle keys, error message text, configuration values, GUID constants. The planning system’s quality standards draw a hard line: “precision is non-negotiable.”
When you prompt for planning work, make the precision expectation explicit:
“When you document the database changes, use fully qualified names (SCHEMA.TABLE.COLUMN) verified against the actual schema, not inferred from C# model names. Query sys.columns if you are not certain.”
“For the feature toggle, include the exact key string from LaunchDarklyToggles, whether it is site-scoped or global, and which IsEnabled overload to use.”
This is the kind of instruction that prevents the most expensive class of planning errors: specs that look correct but reference a column that does not exist, a toggle that uses the wrong evaluation context, or a property name that is the C# model name rather than the database column name.
Separate business questions from technical questions
The planning system’s pattern discovery rules draw a clear boundary: search code for technical patterns, ask the developer for business decisions. When you are prompting Claude for planning work, applying this same boundary in your own prompts saves round trips.
Things Claude should discover on its own: naming conventions, file structure, DI registration patterns, test framework choices, error handling patterns, existing similar implementations.
Things you need to tell Claude: business logic rules, rollout strategy, which sites are affected, what the user-facing behavior should be, whether this feature replaces or complements an existing one.
If you find yourself explaining a naming convention to Claude, that is a sign the prompt should have included “search for existing examples of this pattern first.” If you find Claude asking you about business rules it should know, that is a sign those rules need to be in the story or in a CLAUDE.md file.
Scope the output format to match the planning artifact
Planning work produces specific artifact types. Telling Claude which one you want avoids getting an essay when you needed a story spec, or a story spec when you needed a feature overview.
- “Produce a story spec following the template in
planning/.agent-rules/core/story-task-templates.md” - “Write a feature overview, not individual stories. I want the shape of work before we decompose.”
- “This is a task spec for a specific repo. Include code references, test specs, and preserved behaviors.”
- “I just need a discovery report. What repos are affected, what patterns exist, and what questions remain.”
Each of these produces a different output. Without the framing, Claude defaults to whatever seems most comprehensive, which is often not what you wanted.
Prompting for Implementation
Implementation work is about producing code. The prompting style here is about describing intent and behavior precisely enough that Claude is constrained toward the correct solution, while still making Claude do the heavy lifting of reading the code, finding the patterns, and figuring out how to satisfy the requirements.
The key insight: your prompt should make the correct solution the natural one without dictating the mechanical steps to get there. Describe what the code should accomplish, what constraints it must satisfy, and what patterns it should be consistent with. Let Claude figure out the file, the placement, and the exact implementation.
Describe behavior, not keystrokes
The goal is to constrain Claude’s solution space, not to write the code in English. If your prompt specifies the exact file, exact line number, exact variable names, and exact control flow, you have done the hard part yourself and Claude is just transcribing. That is not a good use of either your time or Claude’s capabilities.
Too vague: “Handle the UVW Lite case for Pending Estimates.”
Too specific: “Add a CarliEnabled check in IsPendingEstimates.ExecuteDecision() after the FrCompleteFlag check at line 48. If CarliEnabled is false, return false.”
Right level: “UVW Lite vehicles should never enter the Pending Estimates queue. Add a guard that bypasses the queue when Carli is disabled. The existing queue transition decisions already have guards for similar routing conditions. The FrCompleteFlag check should still take precedence.”
The right level describes the behavioral requirement (UVW Lite vehicles never enter this queue), names the mechanism (a guard), points at precedent (existing guards in queue transitions), and states the ordering constraint (FrCompleteFlag takes precedence). Claude reads the code, finds the existing guards, understands the decision priority chain, and implements a guard that fits. You get the right solution because the constraints made it the natural one.
Constrain with behavior, point with precedent
The most common failure mode in implementation is Claude solving a problem with a “better” approach that conflicts with every other implementation in the repo. Pointing Claude at existing precedent constrains the solution to match what exists without you having to dictate the mechanics.
“The repo already has HTTP clients that call external services. Find the simplest one and follow its pattern for the new inspection-services client. Same DI registration shape, same retry policy, same auth token handling.” This is a behavioral constraint: match the existing pattern. Claude finds the pattern, reads it, and replicates the shape. If you instead say “create an HTTP client with AddHttpClient<IInterface, Implementation>(), .AddClientCredentialsTokenHandler(), and .AddTransientHttpErrorPolicy(),” you have done the discovery yourself and Claude is typing.
The value of Claude in implementation is that it can read a codebase, identify the right pattern, and apply it consistently. Prompts that describe “what it should behave like” leverage that capability. Prompts that dictate “what to type” bypass it.
Bound the scope with intent, not prohibition lists
Claude tends toward completeness. If you ask it to add a feature toggle check, it may also refactor the surrounding code, add logging, update comments, and normalize whitespace. Bounding the scope by describing what the change is for works better than listing what Claude should not touch.
“This change is strictly about preventing UVW Lite vehicles from entering Pending Estimates. The surrounding routing logic is correct and should not change.” This tells Claude the purpose, which implicitly bounds everything else as out of scope.
Compare to: “Do not modify anything else in the file. Do not refactor surrounding code. Do not add logging.” That is a prohibition list. It works, but it is reactive (you are anticipating what Claude might do wrong) rather than proactive (you are telling Claude what the change is for, and letting it derive the boundaries).
Both approaches constrain scope. The intent-based version is shorter, more natural, and scales better because it does not require you to predict every possible tangent.
Let the task spec do the prompting when one exists
If the work has a planning-repo task spec, the spec itself is the best prompt for the implementation. The spec describes the behavioral requirements, the acceptance criteria, the relevant patterns, and the test expectations. It was built through discovery against the actual codebase, so its constraints already reflect what exists.
“Implement the task at planning/features/164846-uvw-lite/stories/164846-ws02-02-workflow-routing.md, task 1 (inspection-workflow). Follow the spec.” This lets the spec do the heavy lifting. The spec was designed to constrain the solution space exactly the way a good implementation prompt would. There is no value in re-stating its contents in your own words, and doing so risks introducing translation errors.
Prompting for Research and Investigation
Research prompts are the most common input to background agents (guide 02). The goal is an answer, not an action. The prompting style is tighter because the output is consumed by you, not by the codebase.
Constrain the scope and the length
“How does the workflow service work?” will produce a 2000-word essay. “How does the AutomaticallySendToReconComplete handler decide whether to call SendToPhase? I need the decision logic, not the surrounding infrastructure. Under 150 words.” will produce what you actually need.
Research prompts that are too broad produce too much output, which then sits in your context (or the agent’s report) and dilutes focus on subsequent turns. Ask for the minimum you need to make the next decision.
Name the files if you know them
“Read GetNeedsDiagExitEligibilityDatabaseQuery.cs and explain the three-class pattern” is faster and more accurate than “find the eligibility query for the NeedsDiag exit handler.” The first version goes directly to the file. The second version searches, and the search may find the wrong file or take multiple attempts.
If you do not know the file, say so: “I do not know which file handles the DLQ retry for the certification events. Find it and explain the retry policy.” Honest uncertainty in the prompt produces better results than false precision.
Ask for the format that serves your next step
If you are going to use the research output to write a spec, ask for spec-ready output: “list the exact method signatures and constructor dependencies.” If you are going to use it to make a decision, ask for a comparison: “show both approaches and the tradeoff.” If you just need orientation, ask for a summary: “explain in plain language what this subsystem does, under 200 words.”
The research prompt’s format should match how you plan to use the answer. A mismatch means you spend time reformatting the output mentally, which defeats the purpose of delegating the research.
Common Mistakes
Prompting as if Claude remembers the plan you had in your head. Claude knows what is in the context window: your CLAUDE.md, the conversation so far, any files it has read. It does not know what you decided in a meeting, what you discussed on Slack, or what the story should be unless you tell it. If your prompt references decisions Claude was not present for, state them explicitly.
Repeating what Claude already said back to it. “You mentioned that the handler uses the MediatR pattern, so can you…” Claude knows what it said. Reference the finding without restating it: “Using the MediatR pattern you found, add…” This seems minor, but in long sessions the restated content piles up.
Asking “Can you…” instead of telling Claude to do it. “Can you add the guard?” is a yes/no question. Claude will say “Yes, I can” and then do it, but the “Yes, I can” preamble is wasted context. “Add the guard” is direct and produces the same work without the preamble.
Giving Claude a choice when you already know the answer. “Should we use the existing retry policy or create a new one?” If you already know the answer is “use the existing one,” do not ask. “Use the existing retry policy from RetryPolicyConfig.” Questions are for when you genuinely need Claude’s analysis. If you are testing whether Claude will pick the right answer, you are wasting context on a quiz.
Over-prompting simple tasks. “Read this file and tell me what line the ProcessInspection method starts on” does not need three sentences of context about what you are building. The amount of context in the prompt should be proportional to the complexity of the task. Simple lookups need simple prompts.
The next guide in this series covers tips and tricks: compaction strategy, model and effort switching, session lifecycle management, and the day-to-day patterns that make individual sessions more productive.