Cut a Bloated Prompt From 20 Pages to 7

Last updated: August 2026

We are going to take a prompt that has grown out of control and cut it down without losing the behaviour you spent weeks tuning. By the end you will have a version roughly a third of the size, a record of which instructions actually carry weight, and a repeatable way to test a change instead of guessing. This is the exact method a student of mine used to take a production prompt from about twenty pages to seven, across four rounds of testing, with no drop in output quality.

What you need before starting

• The bloated prompt, exactly as it currently runs
• The tool you actually send it to, and enough quota to run maybe thirty generations
• A sample input you know well, so you can judge output quality quickly
• A plain local project folder and a text editor
• About two hours, spread across a few sittings rather than one

Step 1: Get it into a file, verbatim

Before you change a single word, get the whole thing out of wherever it currently lives and into a file. Copy it exactly. Do not tidy it on the way, do not fix the typo you have always hated, do not reorder anything.

mkdir prompt-cleanup && cd prompt-cleanup
mkdir versions tests

Save the original as versions/v0-original.md. This is your control, and you will compare everything against it. If you improve it while copying, you have destroyed your own baseline before you started.

Length itself is not automatically the enemy, and it is worth being precise about that before you start cutting. Modern context windows are large enough that twenty pages fits comfortably. The problem is not that the model cannot read it. The problem is that a model, particularly a smaller one or one running at lower effort, does not go back and re-check every detail of a sprawling instruction set, so things quietly get missed and you cannot tell which instruction was ignored.

Most bloated prompts got that way for a reason worth remembering: someone added a fix under deadline pressure, it worked, and nobody dared remove it afterwards in case quality regressed. My student's original prompt only worked for certain styles at first, so it grew to control for every style and every input. That is not sloppiness, that is a rational response to risk. The file is what lets you finally take that risk safely.

Checkpoint: You have versions/v0-original.md and you have not edited it.

Step 2: Split it by headline into separate instructions

Now break it apart. Every distinct instruction becomes its own block. Ask the model to do the mechanical work, because it is tedious and it is good at it:

Read versions/v0-original.md. Split it into individual instructions, one per
block, grouped under the headline each belongs to. Change no wording. Do not
merge, summarize, or improve anything. Output it as a markdown file where
every instruction is a separate bullet under its heading.

Save the result as versions/v1-split.md. You will almost certainly find the same instruction stated three times in slightly different words, in three different sections. That duplication is where most of the fat is.

Checkpoint: Every instruction in the original appears exactly once in your split file, under a heading.

Step 3: Label every instruction

This is the step that makes the cutting safe, and it is the one people skip.

Go through the split file and tag each instruction as one of three things:

- [LOAD] Output must be 9:16 vertical
- [DEFENSIVE] Do not add captions unless asked
- [DECORATIVE] Aim for a polished, professional feel

Load-bearing instructions define the output. Remove them and the result is wrong. Defensive instructions exist to stop a specific failure someone once saw. Decorative instructions are vibes, adjectives, and encouragement that feel important and usually do nothing measurable.

Do this by your own judgement, not the model's. You know which line you added at 11pm after a bad review cycle. Decorative goes first, defensive gets tested, load-bearing stays until proven otherwise.

Checkpoint: Every instruction carries one of the three labels, and you can name the failure that each defensive instruction was written to prevent.

Step 4: Cut one group, then test

Cut only the decorative instructions first. Save it as versions/v2.md and run it against your known sample.

Run versions/v2.md against tests/sample-input. Then compare the output against
tests/baseline-output from v0. List every difference you can identify, and say
for each whether it is a quality regression, an improvement, or neutral.

Then judge it yourself, because on anything visual or subjective the model is not a reliable judge of its own output. Look at the result and decide.

My student did four rounds of this. Twenty pages to roughly fourteen, then eleven, then nine, then seven. She tested after every single round, which is why she could keep cutting with confidence instead of stopping at the first nervous moment. Four rounds is the number that matters here, not the page count: nobody gets from twenty to seven in one pass, and anyone who tries will lose something and not know which cut caused it.

Checkpoint: You have a smaller version whose output you have compared against the baseline yourself, not just read a summary of.

Step 5: Isolate one variable at a time

If your prompt controls several things at once, cutting it is only half the problem. The other half is that stacked instructions interact, so a change to one part silently moves another.

The fix is to stop sending the whole thing in one shot while you are testing. Work one variable at a time, and lock each win before adding the next:

Using versions/v2.md, apply ONLY the background instructions. Ignore
everything about foreground and text overlay for now. Generate 5 options.

Pick the best result, save it, then add the next layer with the previous one explicitly protected:

Take the saved output. Now apply the foreground instructions.

IMPORTANT: do not change the background. Only work on the foreground.

That capitalized protection line is not stylistic. Without it, adding the foreground instruction will frequently move the background you just settled, and you will spend an afternoon wondering why a change you did not make keeps reappearing. Anthropic's own prompt engineering guidance covers the general principle of being explicit; this is the version of it that matters when instructions stack.

Checkpoint: You can change one part of the output without accidentally changing another.

Step 6: Write down how your tool actually behaves

Every generation tool has habits. It drifts on the second or third pass. It handles one kind of instruction well and quietly ignores another. It has an aspect ratio where a common fault is invisible, which means you can test in the wrong format and never see the problem.

Record what you learn as you go:

# Tool operating notes

- Drifts noticeably from pass 3 onward, restart from a saved output instead
- Ignores negative instructions unless they are capitalized and near the top
- Test in the target aspect ratio, the wide format hides the cropping fault
- Two generations minimum before judging, the first is often unrepresentative

This file is worth more than the prompt within a month. It is the difference between tuning by feel and tuning from evidence, and it is the thing a new team member would otherwise take six weeks to learn.

Checkpoint: You have an operating notes file with at least three behaviours you observed rather than assumed.

Where this breaks

You improve while you copy. The most common failure, and it destroys the baseline. If you have no faithful original, you cannot tell whether a regression came from your cut or from the tidy-up you did in step one.

You cut and test in one pass. Removing six things and then finding the output is worse tells you nothing about which of the six mattered. One group per round, test every round. It feels slow and it is the fastest route.

You let the model grade its own work. Asking it to compare outputs is useful for spotting differences you missed. It is not useful for deciding whether the result is good, particularly for anything visual. One student's real breakthrough came from noticing that the tool does not challenge her own contradictions, it just picks one and proceeds.

The prompt was never the problem. Sometimes the reason a prompt has ballooned is that it is being asked to compensate for an architecture that cannot do the job. In one case the honest finding was that a competitor was feeding a reference input directly while my student's team was forced to describe everything in words. No amount of prompt work closes that gap, and recognizing it early saves months. Sorting what the tool can actually do from what needs to change upstream is covered in where AI stops and configuration starts.

What to build next

Once the prompt is lean, put the operating notes and the final version into a context file so every future session starts with them instead of relearning them. What a CLAUDE.md file is covers that, and the handoff file walkthrough covers keeping the knowledge alive across sessions once your prompt work spans weeks rather than an afternoon.

If you have a prompt that has grown past the point where anyone dares touch it, bring it to a session and we will cut it together with the tests running. Book a free Discovery Call and paste the whole twenty pages in, I have seen worse.

These tutorials come from the actual curriculum I teach 1-on-1. The 20-to-7 reduction above happened in a real engagement, tested at every round.