Most teams discover adversarial prompt testing the hard way: a prompt breaks in front of a client, someone spends an afternoon poking at it until they find the cause, they patch it, and the knowledge evaporates. The next break starts from zero. The work was real, but it left nothing behind that a colleague could reuse.
A workflow fixes that. Where a playbook tells you which plays exist, a workflow tells you the exact path an input takes from "we want to test this" to "this finding is recorded and hardened." It is the difference between a skilled individual and a repeatable practice. The point of writing it down is not bureaucracy — it is that the next person, including future you, can run the same process and get the same coverage.
This article walks through building that workflow as a hand-off-able process: the stages, the artifacts each stage produces, and the rules that keep it from rotting.
Why Repeatability Is the Whole Point
A one-off adversarial session is useful exactly once. A repeatable workflow compounds. Every break you find becomes a permanent test, every test becomes a guardrail, and the guardrails accumulate into a prompt that is genuinely hard to knock over.
The Cost of Ad-Hoc Testing
When testing lives only in someone's head, three things go wrong. Coverage is invisible, so you cannot tell what you have not tested. Findings are lost, so the same break recurs. And the work cannot be delegated, so it bottlenecks on one person who eventually leaves or gets busy.
What "Hand-Off-Able" Requires
For a workflow to survive a hand-off, a new person needs three things: the inputs to run, the criteria for pass or fail, and the place to record results. If any of those lives only in tribal knowledge, the hand-off fails. The rest of this article is about making all three explicit.
The Workflow Stages
A clean adversarial workflow moves through five stages. Each produces an artifact, and the artifact is what makes the stage repeatable.
Stage 1: Define the Contract
Before you attack a prompt, write down what it is supposed to do and refuse to do. This contract is the reference you grade against. Without it, "did this output fail?" becomes a matter of opinion, and opinions do not transfer between people.
Stage 2: Assemble the Attack Set
Pull the relevant attacks from your shared corpus and add any specific to this prompt. The output of this stage is a concrete list of inputs, not a vague intention to "try some injections."
Stage 3: Execute and Record
Run every attack, capture the raw output, and mark each as pass, fail, or borderline. Record the actual model output, not a summary — future debugging depends on the exact text.
Stage 4: Triage and Classify
Sort the failures into categories and severity. A leaked system prompt is more urgent than a slightly off-tone refusal. This stage decides what gets fixed now versus logged for later.
Stage 5: Harden and Re-Test
Apply the fix, then re-run the failing attacks plus the full set to confirm you did not regress something else. Hardening one weakness while opening another is a classic and avoidable mistake.
Artifacts That Make It Repeatable
The workflow lives or dies by the documents it produces. Three artifacts carry the weight.
The Prompt Contract
A short, plain-language statement of intended and forbidden behavior, versioned alongside the prompt. When the prompt changes, the contract changes with it. This is the single most reused document in the workflow.
The Attack Corpus
A shared, growing file of attack inputs, each tagged by the failure category it targets. The corpus is the team's accumulated memory of every way a prompt has ever broken. Treat it as a first-class asset, the way the adversarial prompt stress testing playbook treats its named plays.
The Findings Log
A dated record of each test run: which prompt, which attacks, what failed, and what was done about it. The findings log is what lets a new team member see history instead of starting blind.
Making It Hand-Off-Able
A workflow that only its author can run is not a workflow. A few practices make it genuinely transferable.
Write for the Newcomer
Document each stage as if the reader has never tested a prompt before. Spell out where files live, how to run an attack, and how to decide pass or fail. The test of good documentation is whether someone unfamiliar can run it without asking you a question.
Standardize the Vocabulary
Use the same names for the same things everywhere — failure categories, severity levels, status labels. Shared vocabulary is what lets two people compare notes without translation. This matters even more once you layer in chained reasoning, as covered in Mastering Multi-Step Prompts That Decide One Move at a Time.
Keep the Artifacts Together
Store the contract, corpus, and findings log alongside the prompt in version control. Separated artifacts drift apart; co-located ones stay in sync because they move through the same reviews.
Automating the Repetitive Parts
Once the manual workflow is solid, automation amplifies it. Automate the boring parts first.
Batch Execution
A simple script that runs every attack in the corpus against a prompt and dumps the outputs saves hours and removes the temptation to skip cases. Manual execution does not scale past a few dozen attacks.
Regression Gates
Wire the attack set into your change process so a prompt edit cannot merge while a known attack still breaks it. This turns hard-won findings into permanent protection, the same instinct behind Build a Step Ladder of Prompts for Decisions That Chain.
Keeping the Workflow Alive
A documented workflow still rots if nobody tends it. Build in maintenance.
Prune and Promote
Periodically remove near-duplicate attacks and promote newly discovered breaks into the standing corpus. A lean, current corpus gets run; a bloated one gets skipped.
Review on Model Changes
Every meaningful model version change is a reason to revisit the contract and re-run the full set. Behavior that was safe on one version can regress on another, and the workflow is your early warning system.
Frequently Asked Questions
How long does it take to set up this workflow the first time?
A first usable version takes a day or two: write the contract, seed the corpus with a dozen real attacks, and create the findings log. It improves continuously after that, but you do not need it complete before it starts paying off.
Do I need engineering skills to run the workflow?
The manual workflow needs none — it is reading, writing, and judgment. Engineering skills help only when you automate batch execution and regression gates, and even those can be simple scripts.
How is this different from just keeping a list of test prompts?
A list of test prompts is one artifact. The workflow adds the contract that defines pass or fail, the triage that prioritizes fixes, and the documented stages that make the whole thing transferable to someone else.
What goes in the prompt contract exactly?
A short statement of what the prompt should do, what it must never do, and how it should behave when inputs are ambiguous or hostile. Keep it to a page; a contract nobody reads is worse than none.
How do I stop the corpus from becoming overwhelming?
Tag every attack by failure category and prune near-duplicates regularly. Fifty distinct, real attacks give better coverage than a thousand variations of the same injection string.
Can this workflow run alongside our normal QA?
Yes, and it should. Normal QA confirms cooperative behavior; this workflow confirms hostile-input resilience. They share artifacts like version control but answer different questions.
Key Takeaways
- A repeatable workflow turns one-off adversarial sessions into compounding, transferable coverage.
- Move every input through five stages: define the contract, assemble attacks, execute and record, triage, then harden and re-test.
- Three artifacts make it repeatable — the prompt contract, the attack corpus, and the findings log.
- Write documentation for a newcomer and standardize vocabulary so the workflow survives hand-offs.
- Automate batch execution and regression gates only after the manual process is solid.
- Prune the corpus and re-run on model changes to keep the workflow from rotting.