Advanced Prompting Strategies

Summary#

A Claude Code prompt is not a Google search query. It is a brief to a collaborator who can see the code, run commands, and edit files — but who has no telepathy, no memory of yesterday’s session, and an explicit context window. The quality of your prompts determines the quality of the work more than the model version does.

Advanced prompting is the discipline of writing those briefs well. Three habits do most of the lifting:

1. Specificity — name files, name functions, name what “done” looks like.
2. Examples — show inputs and outputs, before-and-afters, the shape of the answer.
3. Priming — say what role Claude is playing, what context to pull, what to ignore.

Get those three right and most prompts work the first time. Get them wrong and you spend more time correcting than you saved by being terse.

Why it matters#

Three concrete reasons specificity pays:

• Vague prompts produce vague work. “Clean up this file” produces a different cleanup every time. “Replace the four nested try/except blocks in parser.py:50-90 with a single Result-returning helper, keep the existing test suite green” produces a specific diff you can evaluate.
• Tokens spent on the prompt save tokens on rework. A 200-token prompt that takes one round saves a 2,000-token clarification spiral. The “prompt should be terse” instinct is wrong; the right rule is “the prompt should leave no room for a wrong interpretation.”
• The model is good at executing under-specified plans confidently. That confidence is a footgun if your spec is wrong. Specificity is how you keep the confidence aligned with your intent.

The single most-discriminating predictor of a productive Claude Code session is whether your opening message would let a senior engineer (without further questions) understand what you want.

How it works#

Specificity — name things#

The lazy version of a prompt names the outcome. The specific version names the artefacts that produce that outcome.

The specific version is six times longer and ten times more useful. It names the file, the line, the two suspects, the success criterion, and the tests that gate “done.” The model now has a specific brief to execute and a specific way to verify success.

Examples — show, don’t tell#

For anything with a structural pattern — refactors, new endpoint shapes, test fixtures — give Claude one or two before/after examples in the prompt itself.

Refactor the four CRUD endpoints in `users.ts` to return Result<T, ApiError>
instead of throwing. Match the pattern in `orders.ts`, which I already migrated:

Before:
  app.get('/orders/:id', async (req, res) => {
    const order = await db.findOne(req.params.id);     // throws on missing
    if (order.user !== req.user) throw new ForbiddenError();
    res.json(order);
  });

After:
  app.get('/orders/:id', async (req, res) => {
    const result = await getOrderForUser(req.params.id, req.user);
    if (result.isErr()) return apiErrorResponse(res, result.error);
    res.json(result.value);
  });

Keep the same status codes, error shapes, and tests.

Two before/after pairs is the sweet spot. One leaves room for misinterpretation; three is wasted tokens.

Priming — set the role and the constraints#

For tasks that involve judgement (architecture, code review, refactor strategy), spend a sentence saying how you want Claude to think.

> Be a sceptical reviewer. Read the diff, then list every assumption it makes
> that the test suite doesn't verify.

> Treat this as a 30-minute task, not a rewrite. The smallest change that
> fixes the bug wins; no refactoring nearby code.

> Three options please, ordered by how much we'd have to change. Don't pick;
> I want to see the trade-offs.

Priming is how you turn an open-ended request into a constrained one. Without it, Claude defaults to its training-data centroid — usually “thoughtful junior engineer with enthusiasm and slight scope creep.” Priming pulls that toward “skeptical staff engineer” or “minimal-change surgeon” or whatever the task actually wants.

The CLAUDE.md leverage#

Repeated context — project conventions, naming rules, deploy flow, “don’t use this library” — belongs in CLAUDE.md, not in every prompt. The rule of thumb: if you’d write the same caveat twice in two different sessions, it goes in CLAUDE.md. See CLAUDE.md and Memory Files for the full memory model.

In-prompt context is for this session’s specifics. CLAUDE.md is for every session’s invariants. Mixing them up produces prompts that get longer over time and CLAUDE.md files that get vague.

Variants and trade-offs#

The right amount of specificity is task-dependent. Three useful calibrations:

Trade-offs to be aware of:

• Over-specification. A prompt so precise it removes Claude’s judgement turns the model into a literal transcriber. Spec the outcome and constraints; leave how to Claude unless you actually care.
• Under-specification with confidence. The opposite failure — Claude proceeds confidently in a direction you didn’t intend. Counter with Plan Mode for anything non-trivial.
• CLAUDE.md drift. When CLAUDE.md grows past ~200 lines, the model starts to skim. Audit it quarterly; remove anything no longer load-bearing.

When this is asked in interviews#

Three signals you’ve under-prompted:

1. Claude asks a clarifying question. The question itself is the missing spec; add the answer to the prompt next time.
2. The first proposed diff is in the wrong direction. You under-specified the intent. Course-correct via Guiding the Conversation Mid-Task, but also note what you should have said upfront.
3. You’re tempted to write “no, do it differently” three times in a row. Stop. Hit Escape, restate the task with examples, and resume. Three corrections is the threshold past which a fresh prompt beats more corrections.

Conversely, two signals you’ve over-prompted:

1. Claude reproduces your prompt verbatim in the response. It has nothing to add because you gave it nothing to figure out.
2. The prompt itself reads like the diff. You wrote the code in English. Just write the code.

Related concepts#

• CLAUDE.md and Memory Files — repeated context belongs here, not in every prompt.
• Plan Mode — for non-trivial tasks, ask for a plan before action. The plan becomes the spec.
• Guiding the Conversation Mid-Task — mid-task steering when the initial prompt under-specified.
• The Conversation Loop — the loop your prompts feed; understanding it makes prompting feel less like a guessing game.
• Conversation-Driven Development — the workflow that pairs with this concept.