You had a great prompt for generating engineering postmortems. You copied it, swapped the input, and ran it on a marketing brief. The output reads like a postmortem of a marketing brief: timeline, root-cause analysis, “lessons learned”. It is a perfectly executed wrong shape.
Fastest fix: stop editing the old prompt. Write the new task goal in one sentence without looking at the old text, then rebuild the role, the output format, and the examples from that sentence. Editing usually leaves contradictions you cannot see; a clean rebuild from the goal takes less time and produces a cleaner result. Steps 1-6 below do exactly that.
The reason this happens is mechanical, not mysterious. A prompt is tightly coupled to its original assumptions: the audience, the format, the implicit constraints, and especially the few-shot examples. Those examples anchor the model’s format, tone, and labels more strongly than your instructions do (this is why one mismatched example can override a clear instruction). When the task shifts, the old assumptions become silent contaminants. The model follows them because they are still in the prompt; it just produces something that fits the old task, not the new one.
Which bucket are you in?
Match your symptom to the cause before you touch anything. Most copied-prompt failures are one or two of these, not all five.
| Symptom in the output | Most likely cause | Where it lives in the prompt |
|---|---|---|
| Uses domain jargon the new reader won’t know | Audience never updated | Role line / “you are a…” |
| Structure matches the old deliverable, not the new ask | Format inherited from old task | Instructions + output schema |
| References entities only the old examples mentioned | Few-shot examples from old domain | Example block |
| References files, PRs, or data that don’t exist now | Implicit constraints from old context | ”You have access to…” lines |
| Mixes old and new audience/topic in one output | Half-edited prompt (“fossils”) | Scattered leftover lines |
1. Audience shifted but vocabulary did not
The old prompt assumed an engineering audience. The new task is for marketing. Jargon, tone, and level of detail are all wrong but inherited verbatim. Spot it: output uses domain terms the new audience does not.
2. Format inherited from old task
The old task wanted a timeline. The new task wants a one-pager. The prompt still says “produce a timeline” because you forgot to remove it. Spot it: output structure matches the old task, not the new ask.
3. Examples from old domain
You kept the few-shot examples from the old prompt. The model copies their shape and produces something on-shape but off-task. This is the single most common cause, because examples carry the heaviest weight. Spot it: output references domain entities only the old examples mentioned.
4. Implicit constraints from old context
The old prompt had “you have access to PR description X” — true then, false now. The model now invents what “X” might contain (a confident hallucination). Spot it: output references resources that do not exist in your current task.
5. Edits leave fossils
You edited the old prompt to fit the new task but missed some lines. Half-edited prompts often perform worse than fresh ones because they contain contradictions you do not see, and the model silently picks one side. Spot it: prompt has both old and new audience references.
Before you change anything
- Write down the new task goal in one sentence — without referring to the old prompt.
- Identify the new audience, format, and constraints from scratch.
- Find the old prompt and mark every line as: keep / modify / delete.
- Save the bad output from the copied prompt so you can diff against the rebuilt result.
- Decide whether to edit the old prompt or write a new one. Rebuilding is usually faster.
Shortest path to fix
Step 1: Start from the goal sentence
Before looking at the old prompt, write the new goal as a single concrete sentence:
New goal: "Produce a 1-page marketing brief about Feature X for SMB
sellers, structured as: Pain -> Solution -> Proof -> CTA."Compare it against the old goal. If they share less than roughly half their structure (different audience and different format), rebuild rather than retrofit. This sentence is your “output contract” — the single best-practice prompt teams lead with in 2026 — and everything downstream is derived from it.
Step 2: Audit the old prompt line by line
For each line, tag it. This is faster than scanning for fossils after the fact:
- Line 1: "You are a senior engineer..." -> DELETE (audience changed)
- Line 2: "Produce a postmortem timeline..." -> MODIFY to "Produce a marketing brief..."
- Line 3: "Use jargon-free language..." -> KEEP
- Line 4: Few-shot example A -> DELETE (old domain)
- Line 5: Output schema -> REBUILDStep 3: Replace examples wholesale
Examples carry the heaviest assumptions, so if the domain changed, all examples must be replaced. Edited examples are worse than no examples, because they keep the old structure while pretending to be new.
Bad: Edit "the deploy failed because env var was missing" to
"the campaign failed because tracking was missing".
A half-broken hybrid that still smells like a postmortem.
Good: Replace with a real marketing-brief example from your team.Two practical rules from current few-shot guidance (as of June 2026): keep 2-5 examples for most tasks — that is the sweet spot — and make sure they are balanced. If most of your examples share one shape or one label, the model defaults to it for ambiguous inputs (majority-label bias), and it tends to over-weight the last example you list (recency bias). Put your most representative example last.
Step 4: Rebuild the output schema for the new task
Old schema:
{ "timeline": [], "root_cause": "", "action_items": [] }New schema:
{ "pain": "", "solution": "", "proof": [], "cta": "" }These are different documents, not variations on a theme. Specifying the schema explicitly also stops the model from reaching back to the old shape by default.
Step 5: Test once on a narrow case before scaling
Run the rebuilt prompt on one small input. If the output is on-task, scale. If not, the goal sentence or the schema is still wrong — fix those, not the wording around them.
One green run is not proof. Before you trust the prompt for real work, run it on a handful of different inputs. The 2026 rule of thumb: one good output means nothing; ten good outputs across varied inputs means the prompt is stable.
Step 6: Save the new prompt as its own template
Do not save it as “old prompt v2”. Save it as a new task type with its own name. Mixing templates is how fossils accumulate in the first place. If you manage prompts in a tool (PromptLayer, Langfuse, LangSmith, Braintrust, and similar all do this), give it a fresh prompt ID and version it from there rather than forking the old one’s history.
How to confirm the fix
- Output matches the new task type (marketing brief, not postmortem).
- Output references the new domain, not the old.
- No leftover jargon from the old audience.
- The few-shot examples (if any) are all from the new domain.
- A teammate reading the output cannot tell what the old prompt was about.
- It holds across several different inputs, not just the one you tested first.
If it still fails
- The goal sentence itself may be unclear — refine it before touching the prompt again.
- The new domain may need a fresh few-shot library; write 2-3 real examples and use them.
- Combine multiple new prompts into one only after each works individually.
- For high-stakes work, never reuse — always start from the goal.
FAQ
Why does a half-edited prompt perform worse than the original? Because it contains contradictions. The old role line and the new task line both stay in context, and the model silently resolves the conflict in one direction — often the old one, since the examples still point there. A clean rebuild has no competing signals.
Should I edit the old prompt or write a new one? Write a new one whenever the audience or the format changed. Editing only pays off when the task is genuinely the same and you are swapping a slot value (a name, a date, an input). Anything more and rebuilding from the goal sentence is faster and safer.
My instructions clearly say “marketing brief” but I still get a postmortem. Why? Almost always the few-shot examples. Examples anchor format and tone more strongly than instructions, so a leftover postmortem example overrides the words “marketing brief”. Delete or replace the examples first; it usually fixes it on its own.
How many examples should I keep when I rebuild? For most tasks, 2-5. Fewer than that and the model guesses at structure; more than that and you pay context cost without much gain. Keep them balanced across the outcomes you expect, and put the most representative one last.
The same prompt works on one model but not another. Is that normal? Yes. Models respond to formatting and example patterns differently, so a prompt tuned for one (GPT-5.5, Claude Sonnet 4.6, Gemini 3.1 Pro) may need its examples or schema adjusted for another. Re-run Step 5 per model rather than assuming it transfers.
Prevention
- Maintain a prompt library indexed by task type, not by “good prompt I once had”.
- Before reusing, write the new goal in one sentence and compare against the old.
- For parameterized prompts (templates with slots), only the slots change; everything else stays stable.
- For one-off prompts, do not save them at all — write fresh each time.
- Audit prompt libraries quarterly; remove prompts whose original task no longer exists.
- When tempted to edit, ask: “Would rebuilding from scratch be faster?” Usually yes.
Related reading
- Prompt missing audience
- Conflicting instructions weaken output
- No output format specified
- Long prompt degrades output
- Missing examples output drift
Tags: #Troubleshooting #Prompt #Prompt quality #Prompt engineering