Table of Contents
- Overview
- Technique 1: explicitly limit the scope
- Technique 2: separate instructions from examples with XML tags
- Technique 3: restate critical constraints at the end
- Curbing output variance with few-shot prompting
- Controlling via a "system prompt" instead of repeating instructions every time
- Build on the basic 3-step structure
- Summary: a checklist for preventing runaway behavior
Overview
Have you ever asked Claude to do something, only to find it changed things well beyond what you asked for? Several practitioners have shared prompt-control techniques for preventing this kind of "runaway" behavior.
Technique 1: explicitly limit the scope
The most basic control method is explicitly limiting what's fair game to change — phrasing like "don't change anything other than X." In its eagerness to accomplish the task, Claude can end up touching related areas nearby that weren't part of the ask. Drawing a clear line up front between "areas you may touch" and "areas you may not" heads off unintended changes before they happen.
Technique 2: separate instructions from examples with XML tags
As a prompt grows longer, Claude can end up conflating the "instruction," the "example to reference," and "supplementary information." A useful fix is visually separating this information using XML tags — putting the actual instruction inside an <instructions> tag and a reference example inside an <example> tag, for instance, makes it easier for Claude to parse which piece of information should be treated how.
Technique 3: restate critical constraints at the end
A constraint stated at the top of a long prompt can end up ignored, as if forgotten, by the time you reach the later parts. An effective countermeasure is repeating any especially important constraint once more at the very end of the prompt. It's a simple technique, but one that's said to be genuinely effective.
Curbing output variance with few-shot prompting
Worth mentioning alongside these control techniques is few-shot prompting. This means showing the AI 2–3 concrete input/output examples ahead of time, which is said to reduce variance in output format and, as a result, cut down on the effort spent on revisions.
Controlling via a "system prompt" instead of repeating instructions every time
If writing the same constraints into every prompt gets tedious, there's also a mechanism called a system prompt. This is an instruction set up before the conversation begins — using Claude.ai's Projects feature, you can save a system prompt per project. Splitting things up so that unchanging constraints ("act in this role," "always follow this rule") go into the system prompt, while the specific task that changes each time goes into the regular message, seems to keep instructions tidier and makes runaway behavior easier to keep in check.
A tip shared for writing prohibitions (so-called negative prompts) is to write "specific prohibited actions" rather than "abstract prohibitions." Rather than a vague phrase like "don't do anything unnecessary," working backward from an actual past failure to write something concrete — "don't modify any file other than X," "don't delete the test code" — tends to be more effective. It's said to matter that you don't try to nail the setup perfectly in one go, but instead build it up, adding one prohibition at a time each time something actually goes off the rails.
Build on the basic 3-step structure
Before using these techniques, it helps to have the basic prompt structure down. "Setting the stage" conveys the situation and goal, "Defining the task" makes clear exactly what you want done, and "Specifying rules" conveys the constraints to follow. Just structuring a prompt around these three steps is said to noticeably improve accuracy on its own.
Summary: a checklist for preventing runaway behavior
If you've had the frustrating experience of Claude doing something other than what you intended, keep this checklist in mind:
- Explicitly limit what's fair game to change and what isn't
- If the prompt is getting long, separate instructions from examples using XML tags
- Repeat critical constraints once more at the end
- Use few-shot prompting with 2–3 concrete input/output examples
- Use the basic structure of setting the stage → defining the task → specifying rules
A prompt isn't something you write once and forget — when the result doesn't match your intent, it's worth analyzing why and refining it bit by bit. Combining these techniques should bring your conversations with Claude much closer to what you actually intend.
