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. Prompts are tightly coupled to their original assumptions — the audience, the format, the implicit constraints, the unstated examples in your head. When the task shifts, those 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.
This page walks through why prompt reuse fails and how to rebuild from the goal rather than retrofit the old text.
Common causes
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.
How to 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.
How to 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.
How to 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.
How to 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 have contradictions you do not see.
How to 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 for diffing.
- Plan whether to edit the old prompt or write a new one (usually new is faster).
Information to collect
- The old prompt and what task it was for.
- The new task goal.
- The bad output from the copied prompt.
- Specific lines in the prompt that reference the old context.
- Any few-shot examples carried over.
Shortest path to fix
Step 1: Start from the goal sentence
Before looking at the old prompt:
New goal: "Produce a 1-page marketing brief about Feature X for SMB
sellers, structured as: Pain → Solution → Proof → CTA."
Compare against the old goal. If they share less than ~50% of structure, you should rebuild, not retrofit.
Step 2: Audit the old prompt line by line
For each line:
- 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 → REBUILD
This is faster than scanning for fossils.
Step 3: Replace examples wholesale
Examples carry the heaviest assumptions. If the domain changed, all examples must be replaced. Edited examples are worse than no examples.
Bad: Edit "the deploy failed because env var was missing" to
"the campaign failed because tracking was missing".
Half-broken hybrid.
Good: Replace with a real marketing-brief example from your team.
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.
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.
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. Mixing templates is how fossils accumulate.
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 from the new domain.
- A teammate reading the output cannot tell what the old prompt was about.
If it still fails
- The goal sentence may itself be unclear — refine it before rebuilding the prompt.
- The new domain may need a fresh few-shot library; produce 2-3 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.
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