Reading about negative prompting is one thing; sitting down and actually building a constraint that holds is another. This article is the sequential, hands-on version. We will walk through a single repeatable process, in order, that takes you from an output that annoys you to a tested negative prompt you can reuse. You can follow it right now with any model you have open.
The process has six steps, and they are deliberately small. Each one ends in a concrete artifact: a list, a revised prompt, a comparison. By the time you reach the end, you will not just understand negative prompting in theory, you will have a working example in hand. If you want the conceptual background first, the overview in What to Tell a Model It Should Never Do sets the stage, but it is not required to follow along here.
Pick a real task you actually need done. Abstract practice tasks rarely surface the friction that makes this skill worth learning.
Step One: Generate a Clean Baseline
Before you constrain anything, you need something to constrain. Run your task with a normal, positive-only prompt and no exclusions at all.
Why baseline first
If you start by piling on negatives, you cannot tell which ones did anything. The baseline is your control. It also frequently reveals that the model does not have the problem you assumed, saving you from adding a pointless constraint.
What to capture
Save the baseline output somewhere you can see it. You will compare against it at the end, so do not discard it the moment you move on.
Step Two: Name the Specific Problems
Read the baseline closely and write down exactly what is wrong. Be precise, because vague complaints produce vague constraints.
Turn feelings into observations
"It feels off" is not actionable. Translate it: "the second paragraph repeats the first," "it uses the word leverage three times," "it ends with a sales pitch I did not ask for." Each observation is a candidate for a constraint.
Sort by whether a positive could fix it
For each problem, ask whether you could fix it by adding what you want rather than forbidding what you do not. If yes, mark it for inversion. This sorting is the heart of the method, and the failure modes of skipping it appear in 7 Reasons Your Exclusions Get Ignored.
Step Three: Draft Each Constraint Twice
For every problem, write both a negative version and a positive version. Seeing them side by side makes the better choice obvious.
The dual-draft technique
Take "it uses too much jargon." The negative draft is "do not use jargon." The positive draft is "use plain words a tenth grader would know." The positive draft is usually more enforceable because it names a target.
Keep true negatives where they belong
Some problems have no clean positive form. "Do not fabricate quotes" or "never mention pricing" are genuine negatives; leave them as negatives. The goal is not to eliminate all negatives, only the ones that a positive would serve better.
Step Four: Assemble a Structured Prompt
Now combine your positive instructions and your kept negatives into one organized prompt. Organization measurably improves how well the model follows your constraints.
Use a rules block
Put your hard exclusions under a labeled section so they are easy for the model to find:
- Write the body as three short paragraphs.
- Use plain, concrete language.
- Rules: do not fabricate statistics. Do not include a closing sales pitch. Do not exceed 200 words.
Keep the list short
If your rules block has grown past a handful of items, you are probably over-constraining. Trim to the exclusions that genuinely matter. The reasoning behind a tight list is covered in Negative Prompting: Best Practices That Actually Work.
Step Five: Run and Compare
Generate output from your new prompt and place it next to the baseline. This is where you find out if your work paid off.
Check three things
- Did each named problem disappear?
- Did anything new break? Watch for overcorrection, like prose so plain it feels condescending.
- Is the output still good on its own terms, not just free of flaws?
Iterate one change at a time
If something is off, change a single constraint and rerun. Changing several at once means you cannot tell which adjustment helped. This disciplined, one-variable loop is exactly what the Case Study: Negative Prompting in Practice demonstrates over several rounds.
Step Six: Save What Works
A constraint that reliably solves a problem is an asset. Treat it like one.
Build a personal library
Keep a file of tested constraints labeled by what they fix: a jargon-killer, a length cap, a no-pitch rule. Reuse beats reinvention, and a vetted library compounds in value over time.
Note the conditions
Write down which model and task each constraint was tested on. A negative that works perfectly in one model may need adjustment in another, so context matters.
Adapting the Process for Images
The same six steps apply to image generation with small changes worth flagging.
Negatives go in their own field
Image tools give you a dedicated negative prompt box. Put your exclusions there as short keywords, not sentences: blurry, extra fingers, watermark, text.
Tune the strength
Many image tools let you weight the negative prompt. If artifacts persist, raise it; if real detail vanishes, lower it. Find the balance by running the compare step repeatedly.
A Worked Example From Start to Finish
To make the process concrete, here is one short pass through all six steps on a single task: generating a product description for a coffee subscription.
Walking the loop
The baseline prompt, "Write a product description for a monthly coffee subscription," produced an 180-word block that opened with a rhetorical question, used the word elevate twice, and ended with an exclamation. Naming the problems gave three observations: too long, a repeated buzzword, and an over-eager closer. Dual-drafting each, the length problem inverted cleanly to "keep it under 80 words," the buzzword had no replacement so it stayed a negative, and the closer inverted to "end with a plain factual sentence about shipping." The assembled prompt grouped the two real negatives in a rules block and put the length and closing instructions in the body. The compared output came in at 74 words, dropped the buzzword, and closed flatly as intended. One overcorrection appeared, the new copy felt slightly flat, so a single positive was added asking for one concrete sensory detail. That fixed it without reintroducing the buzzword, and the final rules went into the library labeled with the model and date.
Why the walkthrough matters
Seen end to end, the six steps take only a few minutes once they are habit. The discipline is not in the length of each step but in never skipping one, especially the baseline and the holistic compare.
Frequently Asked Questions
Do I really need a baseline before adding constraints?
Yes, and skipping it is the most common reason people waste effort. Without a baseline you cannot tell whether a constraint changed anything or whether the model even had the problem you assumed. The baseline is your control output; it makes the final comparison meaningful and often reveals that a planned constraint is unnecessary.
How do I know whether to use a negative or a positive version?
Draft both, then choose the one that gives the model a clearer, more checkable target. Positives usually win because they name what to aim for, while negatives only mark what to avoid. Keep a negative only when no positive phrasing captures your meaning, such as a fabrication ban or a hard topic boundary.
Why change only one constraint at a time when iterating?
Because if you change several constraints at once and the output shifts, you cannot tell which change caused it. Adjusting one variable per run turns guessing into diagnosis. It is slower per step but far faster overall, since you stop chasing problems you have already solved.
What does overcorrection look like and how do I catch it?
Overcorrection is when a constraint succeeds but harms the output another way, like a no-jargon rule producing prose so plain it reads as condescending. You catch it in the compare step by judging the output on its own merits, not just checking that the forbidden thing is gone.
Key Takeaways
- Follow the steps in order: baseline, name problems, dual-draft each fix, assemble a structured prompt, run and compare, then save what works.
- Always generate a constraint-free baseline first so you can measure whether your negatives actually changed anything.
- Draft both a negative and a positive version of each fix and keep the clearer, more checkable one.
- Group hard exclusions in a short, labeled rules block, and iterate one constraint at a time.
- Save tested constraints with their model and task conditions to build a reusable library.