Serious prompts for Claude and Claude Code: the loop

There's something I notice every time I watch someone use Claude seriously for the first time: the jump in quality doesn't come when they learn a new technique. It comes when they stop thinking of the prompt as a message and start thinking of it as a work instruction. Those are two different categories of writing. One is read by a person who'll reply in seconds; the other is executed by a system that, in many cases, will run on its own for ten minutes before showing you anything to review.

I want to walk through how I write the prompts that actually work — both for Claude in the chat app and for Claude Code on the command line — and why the two tools, which to a casual eye look like the same model with a different skin, in fact demand opposite disciplines.

A distinction that changes everything: one-shot vs. loop

When you message Claude in the web app, you ask a question and get an answer. It's one turn. Even when the conversation runs long, each of your messages is a single unit that produces a single output. The model reads, writes, stops. You evaluate, follow up, rephrase.

Claude Code is a different animal. When you give it an instruction, a loop starts: the model decides which tool to call (read a file, write, run a bash command, fetch a URL), observes the result, picks the next move, and iterates until it considers the task closed. You see the steps as they happen, but the model isn't pausing for permission at every iteration. Your opening instruction has to hold up at step nine, when the agent has already touched six files and is deciding whether to install a dependency.

This difference has a huge practical consequence. A chat prompt can be ambiguous: if it misses, you just rephrase. A prompt to an agent running in a loop, if it's ambiguous, produces ten minutes of wrong work that you then have to undo. The cost of imprecision changes by an order of magnitude.

The minimum anatomy: four slots, not seven

Forget the six- or seven-block templates that circulate on LinkedIn carousels. The bare minimum is four slots:

1. Who is answering — the role, specific enough to bias vocabulary and priority
2. What it must produce — the exact deliverable, never the topic
3. With what material — the factual context: numbers, constraints, what's been tried
4. In what shape and under what limits — length, structure, what NOT to do

Four slots cover the vast majority of serious prompts. When the stakes go up — complex analysis, strategic decisions, long creative work — I add a fifth piece: the how to think, i.e. the reasoning strategy I want active ("think step by step before concluding", "weigh three alternatives and drop the weakest", "play devil's advocate against your own recommendation"). But if the base four slots are empty, no "think step by step" can rescue the prompt.

A concrete example, because without one this stays abstract.

The version people type a hundred times a day:

"Write me an onboarding email for my product."

The version with the four slots filled:

"You are the customer success lead of a B2B SaaS tool priced at €19/month that handles e-invoicing for Italian VAT-registered freelancers. Write a 130-word welcome email for users who just signed up to the 14-day trial. Goal: get them to issue their first invoice within 48 hours. Tone: direct, no American enthusiasm, no emoji. One CTA only: link to the onboarding wizard. Don't promise 24/7 support, don't mention other plans, don't use the word 'revolutionary'."

Same model, same day, two incomparable outputs. The second isn't smarter: it has more structured information to work with.

(The €19 figure is illustrative; it's just there to show how a real price drops into context.)

Context is raw material, not politeness

The most common misunderstanding is treating context as a polite preamble — something you put at the top "to give an idea". It isn't. Context is the raw material from which the model builds the answer. Without specific context, it falls back on the statistical average of the web — which is exactly what produces the outputs that make you think "I could have written this myself".

Three habits that move quality more than any technique.

Numbers, not adjectives. "I have a small following" is useless. "420 Instagram followers, 0 email list, 3 sales in the last 30 days at €29 each" is useful. Numbers force Claude to calibrate advice for your actual scale, not for a Series A startup playbook. (€29 here is illustrative too.)

What you've already tried and what failed. "I posted daily on X for two months, reach collapsed, account suspended in March" saves Claude from confidently recommending exactly the thing you already discovered doesn't work. It's the single piece of context with the highest ROI: you spare yourself the wrong advice.

What you don't want. Negative constraints carry as much weight as positive ones. "Don't suggest solutions that need an ad budget", "don't tell me to hire", "don't use American motivational vocabulary". Without negative constraints, the model explores the space where it has the most training data — which for someone operating solo, in a non-English market, with a real budget, is almost always the wrong direction.

What actually changes in Claude Code

All the rules above still apply in Claude Code, but three of them shift in a deep way.

The prompt defines a loop, it doesn't answer a question. You're writing the rules of engagement for a work session that will take N steps you won't witness in real time. They have to hold up at step 9, not just at step 1. That means writing instructions that keep guiding the agent even after it's read six files, modified two, and is weighing whether a third is needed.

Stop conditions are action boundaries, not word counts. In chat, if Claude overshoots, you scroll. In Code, if the agent decides that finishing the task requires refactoring three modules and installing a framework, damage is done. Stop conditions become: "don't modify files outside src/auth/", "don't run commands that write outside the repo", "if a package install is needed, stop and ask". They are guardrails, not pleasantries.

Context is environment, not text you paste. What the model "sees" in Code includes the filesystem, the CLAUDE.md, the enabled tools, the configured permissions. A brilliant prompt inside a badly prepared directory still produces mediocre output, because the agent is reading a state of the world that isn't the one you had in mind.

Same example, two versions. The one that causes damage:

"Add tests for the auth module."

The agent will pick the test framework it wants, the style it wants, and hand you something that probably compiles but that you might not recognize as yours.

The one that produces reviewable work:

"Add unit tests for src/auth/login.ts and src/auth/refresh.ts. Use Vitest, already configured in package.json. Follow the style of the tests in src/users/__tests__/. Coverage is required on every error path. Don't modify the files under test, don't install new dependencies. If you hit an ambiguous case, stop the loop and ask. When done, run npm test and show me the full output."

Three extra sentences that move you from "generated code" to "a PR I can review in five minutes".

How a session actually gets written: big upfront, fast iteration

There's a mistake almost everyone who learns structured prompting makes: they write the structured version for every message. It's a subtler error than the first one, and it wastes more time.

The method I use, in chat and in Code alike: one big prompt at the opening of the session — the one that fixes role, context, constraints, desired output — and then short iterative prompts that work inside the context already established. "Sharpen the opener." "Rewrite it for an Italian audience, not an American one." "Explain why you picked that metaphor." Those are one-line prompts, but they run inside 800 words of context set at the start.

In Claude Code the same logic is even stronger: the opening instruction nails commit language, code style, working branch, off-limits files, expected behavior under ambiguity. From that point on the commands become "now add email validation" and that's it. If you find yourself repeating context instructions every turn, the opening was wrong.

Four mistakes I see most

In order of frequency.

Topic instead of task. "Let's talk about my social strategy" isn't a task, it's an invitation to chat. "Give me three positioning angles for a TikTok account selling a €29 PDF to over-35 freelancers" is a task. The difference shows up in the first verb.

Stacking too many requests into one prompt. Asking for email + caption + ad copy + headline in a single turn yields four mediocre 60% outputs. Asking for them one at a time, each built on the previous deliverable, yields four 95% outputs. Slightly slower to type, much faster to a usable result.

Asking for "creativity" without constraints. "Be creative" is the least creative request you can make. Creativity lives in the constraint: "write a 12-word hook, no rhetorical questions, no hollow words like 'revolutionary', and it has to work read aloud". That's a brief; "be creative" is an abdication.

Skipping prompt debugging. When the output disappoints, the reflex is "Claude is bad today". The right reflex is to ask Claude itself: "What information were you missing to do this better? What should I have given you in the prompt?". Nine times out of ten it lists exactly the missing context. It's the cheapest, fastest debug there is, and almost nobody runs it.

Context is a budget, not a space

One last thing that applies to both tools and matters double in Code. Context isn't free and isn't infinite. Every token you push in is a token the model has to read, weigh, integrate. Filling context with marginally relevant material doesn't help: it distracts. Three files read in full when only the relevant section was needed is noise, not richness.

In Code this is visible to the naked eye: an agent reading twenty files of which three matter struggles more than an agent reading three well-chosen ones. When you define a task, define the perimeter: which files to look at, which to ignore, how deep. Curated context beats abundant context every time.

The final question, before you hit send

It isn't the number of techniques you use that separates people who work well with Claude from people who suffer it. It's a habit: reread the prompt before sending and ask yourself if this landed in the inbox of a competent human collaborator, would they unambiguously understand what to do?. If the answer is no, the prompt isn't ready, no matter how elaborate it looks. Claude doesn't read your mind. It reads your tokens. Ambiguous tokens, ambiguous output. Precise tokens, output that changes what feels possible in an hour of work.

The four slots in this article are the minimum that gets you far. When you want the full system behind the method — the six expanded prompt blocks, ready-to-use role definitions, context checklists, five reasoning strategies with end-to-end examples, and templates for Claude Code — I packaged it in Prompt Anatomy, the YUKIMORI operating guide to prompting with Claude. It's built for people who want to stop improvising and start working with a reusable system. Get it here.