Upgrade Your Prompt Stack for Sonnet 5 and GPT-5.6 Without Rewriting Everything

This post is about migrating a working prompt stack to new models without starting from a blank file. It is not about crowning Sonnet 5 or GPT-5.6 as the permanent winner. By the end you will be able to re-test a client system prompt in one afternoon and ship only the lines that actually moved.

The July wave made a lot of smart people do a dumb thing. They opened last year's master prompt, deleted it, and wrote a new "optimized for the latest model" version from memory. The new version often looked cleaner. It also threw away six months of hard-won constraints.

Keep the scaffold. Re-test the fail-states. Patch, do not rewrite.

What I freeze on day one

I treat every production prompt as three layers:

1. Hard constraints (banned words, length, format, "never invent numbers")
2. Task contract (what good looks like, who the reader is, what success means)
3. Style and examples (voice samples, few-shots, tone notes)

Layers 1 and 2 almost never need a full rewrite when a model upgrades. Layer 3 often does, because new models have different default verbosity and different obedience to "sound like a peer, not a marketer."

If your constraints already sit at the top (see The Constraint Goes First), you are ahead. If they do not, fix order before you chase model-specific tricks.

The bad migration (what I keep seeing)

You are now optimized for Claude Sonnet 5 and GPT-5.6.
Be more intelligent, more careful, and more creative.
Use the full power of the new models.
Write better than before.
[... then the entire old prompt pasted underneath, unedited ...]

This fails for three reasons. First, "be more intelligent" is not a constraint. Second, stacking a hype preamble above your real rules undoes constraint-first structure. Third, you have no baseline, so you cannot tell whether the new model helped or the rewrite just got lucky once.

(This is the part vendors are wrong about when they imply a model upgrade is a free prompt upgrade.)

The working migration

I run the same three tasks on the old model and the new one, same temperature settings where the API allows it, same inputs.

Task A: client brief (verbosity fail-state)

Old models often under-specified. New frontier models often over-write. On Sonnet 5 and GPT-5.6 Terra in my tests, the default brief came back 30 to 50 percent longer than the client wanted unless length was in the first five lines.

Patch that worked:

Constraints, in priority order:
1. Total output under 180 words. Count. If over, cut before sending.
2. No preamble ("Sure", "Here is", "I'd be happy to").
3. No bullet lists unless the user asked for a list.
...

I did not change the brand voice paragraph. I moved and tightened the length rule until both models respected it on three runs.

Task B: structured JSON (fidelity fail-state)

GPT-5.6 Luna was cheap and fast and slightly sloppier on nested keys in my client schema. Sonnet 5 was stricter but occasionally wrapped JSON in a short apology line when it felt unsure.

Patch that worked:

Output: a single JSON object. No markdown fences. No commentary.
If a field is unknown, use null. Never invent a string to fill a gap.
Validate against this schema before answering:
{ "headline": string, "dek": string, "risks": string[] }

When Luna still drifted, I added a one-line repair pass as a second call instead of stuffing more threats into the first prompt. Two cheap calls beat one anxious essay.

Task C: voice match (drift fail-state)

Both new models were better at following long style guides if the guide was short. Long style guides got summarized into vibes. The de-slop stack still applies (The De-Slop Prompt Stack). What changed: I cut voice samples from five paragraphs to two tight ones and put the banned-word list back at the top.

The recipe: fewer examples, sharper constraints, same brand truths.

Side-by-side: what I changed for one SaaS client

Three runs per model. I only kept patches that improved at least two of three runs. Everything else stayed frozen.

Paste-ready checklist (90 minutes)

1. Export the current system prompt. Do not edit it yet.
2. Pick three real inputs from the last month (not toy examples).
3. Run all three on the old default model. Save outputs.
4. Run all three on the candidate model with the same prompt. Save outputs.
5. Score only: constraint obedience, factual caution, voice match, length. Binary pass/fail per criterion.
6. Patch the highest-failure constraint first. Re-run. Stop when two of three tasks pass.
7. Ship the patched prompt with a one-line changelog at the top of the file: date, models tested, what moved.

Never give yourself a free rewrite. Never give yourself a free rewrite. The scaffold is the asset. The model is the temporary employee.

Tiny experiment for you

Tomorrow, take one production prompt. Do not rewrite it. Add a single hard length constraint at the top. Run it on your new default model three times. If length still fails, the model is not the first problem. Your constraint is still soft.

That is the whole lab method for a model wave. Keep the recipe. Dial the parts that broke. Leave the rest alone.

Sources

• The Constraint Goes First (Promptway)
• The De-Slop Prompt Stack (Promptway)
• July model wave context (Promptway)