Writing a prompt that survives a long task

A prompt for a single answer needs to be clear. A prompt that has to steer twenty turns of work needs something else: it has to still be doing its job after everything that comes afterwards has been added on top of it.

Those are different design problems, and the second one has a shape you can copy.

Why an opening instruction fades

Your first message keeps being re-sent, so it never literally disappears. What changes is its share of attention. By turn twenty it is one small part of a much larger bundle, competing with every file read and every reply since — Anthropic's context rot again, where recall degrades as the token count climbs.

The visible symptom is a constraint quietly stopping being honoured. Nothing announces it. The work simply drifts.

What a durable prompt contains

Anthropic's description of a good spec transfers directly to any long task. The most useful ones "are self-contained: they name the files and interfaces involved, state what is out of scope, and end with an end-to-end verification step that proves the feature works."

Three parts, and the middle one is the part most people leave out.

Self-contained. Everything needed to act sits in the message. A prompt that depends on something you said earlier degrades exactly as that earlier thing loses attention.

Out of scope, stated. Naming what not to do is more durable than naming what to do, because scope creep is the characteristic long-task failure. "Do not change the database schema" survives twenty turns better than an unstated assumption that nobody would.

A verification step. End with what would demonstrate success. Anthropic's framing for code is that Claude stops when the work looks done, and "without a check it can run, 'looks done' is the only signal available." The same holds for a report or an analysis: state what would show it is right.

Constraints belong near the top and stated as rules

Bury a constraint in the middle of a paragraph of context and it reads as background. State it as a rule and it reads as a rule.

Anthropic's advice on emphasis is worth borrowing exactly, because it contains a warning: if one instruction keeps getting skipped, mark that line alone. "If you emphasize many lines, none of them stands out." Emphasis is a budget too.

Restate rather than accumulate

The durable move mid-task is to restate, compactly, instead of adding another correction on top of a growing pile.

At a natural checkpoint, write one message containing the original goal, the constraints that still apply, and where things stand. It costs a few sentences and resets what the model is actually steering by. Past two failed corrections on the same point, the better move is to start fresh with what you learned.

Try this

Take a long task you are part-way through. Without scrolling up, write the instruction you think is governing the work. Then ask the model to state the constraints it believes it is operating under.

Where the two lists differ, you have found what faded — and that gap is information you can only get by asking.

What goes wrong

Assuming stated once is stated forever. It was said once, and it is now competing with everything since.

Adding constraints one at a time as they are violated. This produces a long tail of corrections scattered through the conversation, each less prominent than the last. Consolidate them into one restatement.

Describing the output instead of the goal. "Write four paragraphs" is checkable and hollow. "Explain this so a new joiner can act on it" gives something to aim at, and the length follows.

Leaving scope open. Without a stated boundary the work expands, because adding seems more helpful than stopping.

How to check it worked

Mid-task, ask what it is optimising for and what it believes is out of scope. An accurate answer means your prompt is still steering. A vague or wrong one means it faded some turns ago, and everything produced since was guided by something other than what you asked for.