Ask a working creator to show you their negative prompts. You’ll usually get one of two things. A single heroic string pasted from a forum, unchanged for a year. Or a notes app full of fragments — “the one that fixed hands,” “market scene??” — with no record of which shot each fragment saved or why.
Both approaches leak credits. The forum string guards against failures you may never have. The fragments can’t be found at the exact moment you need them — mid-session, shot on screen. What actually works is a small personal library organised by failure type. Built from your own footage. Pruned like you mean it. That’s the system I run for my Seedance 2.5 and Veo work, and here’s the full layout: the shape of the library, the modules I keep, how new terms earn their place, and where the library lives so it gets used instead of admired.
A Library Organised By Failure, Not By Tool
The organising decision matters more than any single term in the library. Most creators file negatives by tool — a Runway list, a Veo list, wherever the current box sits. Because that’s where the box is. Wrong axis. Tools change mid-year. Failures don’t. A hand fails the same way in every generator I’ve used. A sign melts the same alphabet regardless of brand. File by tool, and every tool switch means rebuilding — and rebuilding means forum strings in the meantime. File by failure, and the library survives every migration intact. You just re-dialect it. Minutes.
Failure-based filing also matches how you actually work. At the prompt box you’re not thinking “what does this tool dislike?” You’re looking at a storyboard panel thinking “close-up with hands and a cup — what usually goes wrong here?” A library indexed by what goes wrong answers the question you’re really asking. My modules, as you’ll see below, are named after failure families: faces, hands and contact, products, text, backgrounds and crowds. One look at the board tells me which modules a shot needs. No searching. No trying to remember which project produced which magic string.
Third benefit, and nobody expects it: failure-based libraries teach you your own patterns. After a few months your library is a map of how your pipeline fails — which shot types eat your credits, which defects follow you between projects. That map has changed how I board scenes more than any single prompt trick. When the library keeps telling you walking shots fail, you start boarding fewer walks and more cuts. It stops being a spellbook and becomes production data.
The Base String: Short And Universal
Every library starts with a base string — the handful of terms that ride on genuinely every shot. Mine covers the model’s global habits, not any scene: flicker, temporal jitter, warping, watermarks, overlay text, general quality collapse. Six ideas, worded for the tool I’m in. If your base string needs a scrollbar, it’s not a base string. It’s the whole library dumped at the door, and it’ll dilute everything behind it. My longer argument for restraint lives in the piece on negative prompts generally, but the operational rule is simple: the base handles what the model does everywhere, modules handle what the shot invites.
Two things make a base string trustworthy. First, stability: it changes rarely, and only when QC across several projects shows a defect arriving everywhere — or a term going dead because the model stopped producing that failure. Second, portability: the base has to be expressible in every tool you use, including tools with no negative field, where it folds into positive language — steady light, clean surfaces, one continuous take. If a term can’t be translated, it probably names an interface quirk, not a failure. It doesn’t belong in the base.
I keep the base visually separate in the document, too. Its own line, clearly marked, never edited casually mid-session. Mid-session edits are how libraries get corrupted: one frustrating shot adds three terms at midnight, and a month later nobody remembers they were ever meant for that shot alone. The base is policy. Modules are tactics. Shot-specific additions are conversation. Separate compartments — or they merge into soup.
Face And Hands Module
This module earns its keep most often, because faces and hands are where generated people fall apart. My face set is structure-only: face morphing, identity change, asymmetric eyes, distorted teeth when mouths open. Skin surface terms are banned from this module on purpose — the plastic look is a worse failure than the pores I’d be protecting against, a trade I’ve written about in the over-negating article in this series. If skin needs help, it gets positive language in the main prompt. Not bans in the library.
Hands get their own sub-module because hands fail at specific, nameable moments: contact and counting. The terms: extra fingers, fused fingers, merged hands, distorted grip. But the honest entry in this module isn’t a term at all. It’s a note to self that the library has limits here. When hands are the subject, the fix that actually works is shot design: simpler actions, one clear grip, shorter duration, a willingness to cut away. I keep that note physically inside the module so future me doesn’t burn four generations relearning it. A library that only stores strings stores half the lesson. Mine stores the judgement next to the string.
Terms enter this module the way they enter all of them: by catching a failure I can point at in a paused frame from my own footage. I don’t import terms from other people’s lists anymore. Someone else’s module solves someone else’s shots — and their ten terms for crowds do nothing for my close-ups except crowd the box.
Product And Text Module
Product failures are geometry failures with a logo attached. The module: deformed shape, melted edges, duplicate product, distorted reflection — with the text set (gibberish text, fake letters, misspelled words, warped logo) attached when labels or packaging are in frame. These two travel together in my work because product shots are usually text-risk shots, and because the professional answer to both is often the same: keep the object clean and simple in generation, let the edit carry anything the audience must read precisely.
Which is why the most important line in this module is also a note, not a term: clean plate first. If the shot’s job is the label, the generation’s job is a blank, stable, well-lit label-shaped surface — and Premiere gets the real artwork. I’ve written that workflow up in full in the clean-plate article in this series, and the library entry just points at it. Libraries that hold only negatives train you to solve every problem with negatives. Some problems are assignments for a different stage of production. A good library says so.
One product-specific lesson the library holds: reflections invent. Glossy packaging and glass generate rooms, windows, occasionally people that were never in the scene. “Distorted reflection” is my term, but the positive half does more work — describe a simple, matte environment and the reflection has something sane to show. The module carries both the term and that reminder, because the term alone fixed maybe half the cases I threw it at.
Background And Crowd Module
Backgrounds fail by drawing attention: warping architecture that breathes, textures that crawl, extras who duplicate, melt, or decide they’re the star. The module: warping background, wobbling buildings, crawling textures, duplicate people, merging faces, floating heads — drawn on only when the shot actually has depth and life behind the subject. Tight close-up against a plain wall? This module stays in the drawer. A term for a failure the shot can’t have is dead weight, and dead weight dilutes live protection.
The deeper habit filed here is negative-by-design before negative-by-prompt. If the board can give me an empty street instead of a busy one, a quiet café instead of a packed one, the crowd module often never gets opened. The best background negative is a background with nothing in it to go wrong. When a crowd is genuinely the point of the shot, the rules change: keep people distant, soft, moving simply — and let the count be “a few” rather than “a dense crowd.” Dense crowds are where merging lives. I’d rather sell “busy” with six readable figures than fifty melting ones.
Architecture deserves its own line in the module: straight lines are the audience’s lie detector. Bent doorframes and leaning walls announce generation faster than almost any face artifact, because viewers know what buildings do. Interior or exterior alike, geometry terms get priority in this module — ahead of crowd terms — whenever lines dominate the frame.
Testing And Pruning Your Own Library
A library you never test becomes a superstition with good filing. My pruning rhythm is unglamorous and it works. Every project, QC notes record which negative terms were riding on shots that still failed, and which failures arrived uninvited. End of project — not mid-session, not at midnight — I review those notes against the library. A term that never caught anything across a whole project becomes a removal candidate. A failure that appeared twice without a term becomes an entry candidate — worded once, in one module. One in, one out isn’t a hard law, but the instinct keeps modules lean. Most hold four to seven terms, and have for a long time.
Twice a year or so — or whenever a tool changes significantly — I run a small subtraction test on a familiar shot type: full module versus base alone, same frame, same prompt. Three generations, and it’s retired more terms than any opinion I’ve read online. Models improve quietly. A defect you’ve banned for a year may simply not exist anymore, and you’d never know — because the ban gets the credit. Retiring dead terms isn’t housekeeping for its own sake. Every dead term in the box taxes the living ones. So pruning is literally protection getting stronger. The QC checklist habit is what feeds this whole loop; without honest QC notes, pruning is just guessing.
Where The Library Lives In Your Workflow
Format and location decide whether any of this survives deadline pressure. My library is one page inside the same document as my reusable prompt template — base string at the top, modules below, each with its judgement notes, and a positive-language translation beside any module I use in tools without a negative field. One document, opened for every project. Not a folder of text files named “final,” “final2,” and “USE_THIS_ONE.” If your library takes more than ten seconds to consult at the prompt box, it gets consulted never.
Version it, lightly. When a term enters or leaves, I note the date and the project that taught me. That single line of provenance has settled more arguments with myself than I can count. Six months later, “why is ‘sliding feet’ here?” has an answer attached — and the answer is a shot I can go look at. A library with memory compounds. A library without it gets rebuilt from forum posts every year, and the footage shows it.
Build yours the same way: start from your next project’s QC, file by failure, keep every module short enough to say out loud, store the judgement with the string. A month from now you’ll stop thinking of negatives as a text box you fill in. You’ll think of them as what they actually are in a working pipeline — a short, personal, evidence-based list of the ways your footage fails, written down so it fails less. That’s the whole library. Everything else is other people’s weather.