A checklist is only useful if it is short enough to actually run and specific enough to catch real problems. This one is built to sit beside you while you write a negative prompt, not to be admired and forgotten. Each item is a yes-or-no question you can answer in seconds, paired with a one-line justification so you understand why it earns a spot. Run the whole thing before you accept any constraint into production work.
The checklist is organized into four phases that mirror how a constraint moves from idea to reuse: before you write it, while you write it, while you test it, and after it works. You do not need every item every time, but skipping a phase is usually where things go wrong. For the reasoning that underpins these items in depth, the practices in Opinionated Rules for Constraints That Hold are the long form.
Print it, bookmark it, or paste it into your prompt notes. It is meant to be worn down with use.
Before You Write the Constraint
The cheapest fixes happen before you add anything. These items prevent you from constraining the wrong thing.
The pre-writing checks
- Do I have a constraint-free baseline output to compare against? Without a control, you cannot prove the constraint did anything.
- Have I named the problem in observable, countable terms? Vague complaints produce vague, ignored constraints.
- Could a positive instruction solve this instead? A target is followed more reliably than a prohibition, so earn the negative.
- Is this a genuine boundary, fabrication risk, or artifact with no positive form? Those are the cases negatives are actually built for.
If you cannot answer the first two, stop and fix that first. The baseline-then-define sequence is the foundation of Build a Working Exclusion in Six Concrete Steps.
While You Write the Constraint
These items shape the wording so the model can follow it.
The drafting checks
- Is the constraint gradeable by a stranger without asking what I meant? If not, it is too fuzzy to enforce.
- Have I paired the negative with a positive alternative where one exists? An alternative removes the model's guesswork.
- Did I avoid naming the exact thing I want suppressed when possible? Naming it can summon it through the pink-elephant effect.
- Is the constraint scoped so it will not swallow things I want to keep? Over-broad bans cause overcorrection.
The structure checks
- Are hard exclusions grouped in a labeled rules block? Structure raises adherence over buried prose.
- Is my list of negatives short, ideally a handful at most? Too many constraints degrade all of them.
While You Test the Constraint
A constraint is unproven until you have looked at the output with intent.
The testing checks
- Did each named problem actually disappear in the new output? Compliance is never safe to assume.
- Did anything new break, especially tone or substance? Watch for overcorrection that trades one flaw for another.
- Is the output still good on its own merits, not merely cleaner? Judge holistically, not just pass-fail on the banned item.
- Did I change only one constraint since the last run? One variable per iteration lets you trace cause to effect.
This testing discipline is exactly what the Case Study: Negative Prompting in Practice demonstrates across multiple rounds.
After the Constraint Works
The final phase turns a one-time win into lasting leverage.
The closing checks
- Did I record which model and version this was tested on? A negative validated on one model is not validated everywhere.
- Did I save the constraint to a labeled library with the problem it fixes? Reuse beats reinventing the same negative later.
- Have I noted any conditions or exceptions discovered during testing? Future you will not remember the edge case you just solved.
Adapting the Checklist for Images
Image generation shifts a few items, so keep this short addendum in mind.
Image-specific checks
- Am I using the dedicated negative prompt field rather than cramming negatives into the positive prompt? The field is purpose-built for steering away.
- Are my negatives terse keywords rather than sentences? Image negatives reward density over grammar.
- Have I tuned the negative strength, raising it if artifacts persist and lowering it if real detail vanishes? The right weight is found empirically.
- Have I started from a standard cleanup baseline before adding scene-specific negatives? A reusable hygiene set catches the common artifacts so your custom negatives can target the rest.
Using the Checklist Under Time Pressure
In real work you rarely have the luxury of running every item slowly, so it helps to know which checks are load-bearing and which are polish.
The three checks you should never skip
Even on the tightest deadline, three items earn their seconds. Capture a baseline, because without it you are guessing rather than measuring. Make the constraint gradeable, because a fuzzy negative is the single most common reason a constraint is silently ignored. And glance for overcorrection, because a constraint that quietly damages tone or substance is worse than no constraint at all. If you do nothing else, do these three.
The checks you can defer on low-stakes work
Library closure, recording the tested model, and noting exceptions all serve future reuse rather than the current output. For a genuine one-off that will never run again, deferring them is a reasonable trade. The danger is misjudging what is truly one-off; many prompts you think are disposable end up reused, and the undocumented constraint costs you later. When in doubt, spend the extra ten seconds to save it.
Turning the checklist into a habit
The first few times, run the list explicitly and slowly. After a dozen passes the questions fold into how you write, and you will catch a vague prohibition or a missing replacement before you have even finished typing it. The checklist is training wheels you eventually internalize, not a permanent crutch, and the practices it instills are reinforced across the sibling articles in this cluster.
Frequently Asked Questions
Do I have to run every checklist item every time?
No. The checklist is a safety net, not a ritual. For a quick throwaway prompt you might run only the drafting and testing items. For anything going into production or a reusable library, run all four phases. The one item you should almost never skip is the baseline, because without it you cannot prove your constraint changed anything.
Why is the baseline item listed first and treated as non-negotiable?
Because nearly every wasted hour in negative prompting traces back to not having a control. Without a constraint-free baseline, you cannot tell whether your negative did anything, made things worse, or addressed a problem the model never actually had. Capturing the baseline takes seconds and turns the rest of the checklist from guesswork into measurement.
How short should my list of negatives be?
Short enough to scan at a glance, typically a handful at most. Constraints compete for the model's attention, so a long list degrades adherence to all of them unpredictably. When your rules block grows, the checklist nudges you to replace several abstract bans with one concrete example, which the model follows far more reliably.
Does this checklist work for both chat and image models?
Yes, with the image addendum. The core phases, baseline, gradeable wording, holistic testing, and saving the result, apply universally. Image generation adds a few specifics: use the dedicated negative field, keep negatives as terse keywords, and tune the negative strength empirically rather than guessing at it.
Key Takeaways
- Run the checklist in four phases: before writing, while writing, while testing, and after it works.
- Never skip the baseline; without a control you cannot prove a constraint did anything.
- Make every constraint gradeable, scoped, and paired with a positive, and keep the negatives list short.
- Test holistically for overcorrection and change one constraint per iteration so you can trace cause and effect.
- Record the tested model and save the working constraint to a labeled library to turn effort into reusable leverage.