A technique becomes an operating capability when it stops depending on the mood and memory of whoever is at the keyboard. Decomposition prompting works, but most teams apply it inconsistently — sometimes thoroughly, sometimes not at all, depending on who is doing the work and how much time they have. A playbook fixes that by defining a small set of plays, the triggers that tell you which play to run, who owns each one, and the order they fire in. The point is to make the right move the obvious move, so that good decomposition happens by default rather than by inspiration.
This playbook is organized around decisions, not theory. Each play answers a question a practitioner faces in the moment: should I decompose this at all, how should I split it, where do I verify, and what do I do when a step fails. Read end to end, it is a sequence you can run on any complex task. Used as a reference, it is a set of named plays you can reach for when a specific situation arises. Either way, the goal is repeatable reliability rather than one-off cleverness.
If you have not yet built a single chain, run the four-step starter in Splitting One Hard Prompt Into Steps That Work first; this playbook assumes you can already build a basic chain and want to operationalize the practice.
Play One: The Decompose-Or-Not Decision
Trigger
A task is about to be handed to a model and it is non-trivial — multi-stage, high-stakes, or one that has failed as a single prompt before. This play fires before any prompt is written.
The Move
Ask three questions: does the task have distinct phases, has a single prompt failed at it, and would an error be costly. Two yeses mean decompose. Mostly noes mean run a single prompt and move on. Owner: whoever holds the task. The discipline is to make this an explicit decision rather than a default in either direction.
Play Two: The Split
Trigger
The decompose-or-not play returned yes. Now the task must be broken into steps.
The Move
Identify the natural seams — gather, plan, produce, verify is the default skeleton. Map each seam to one step with a single job, and define what each step receives and returns. Resist splitting past the genuine seams; extra steps add handoffs that lose context. Owner: the person building the chain, ideally reviewed by a second set of eyes for high-stakes work. The depth question is treated fully in Advanced Decomposition Prompting.
Play Three: The Handoff Design
Trigger
Steps are defined and you are about to connect them.
The Move
For each seam, decide deliberately what context the next step needs. Carry forward exactly that — not the whole prior output, not a lossy summary. A good handoff is the difference between a chain that preserves intent and one that degrades it stage by stage. Owner: the chain builder. This is the most underrated play and the one beginners skip.
Play Four: The Verification Placement
Trigger
The chain produces output the rest of the chain or a human will rely on.
The Move
Place a check after any step the chain depends on heavily, plus a final check against the definition of done. Make verification steps specific — give them the criteria, not a vague instruction to confirm quality. Owner: the chain builder, with the chain owner accountable for the checks actually working. Test the validators with known-bad input, as warned in The Hidden Risks of Decomposition Prompting.
Play Five: The Failure Recovery
Trigger
A verification check fails or a step produces obviously wrong output.
The Move
Re-run the failing step or the earliest step the error traces back to, not the whole chain. If the same step fails repeatedly, the problem is the step's design, not the run — fix the prompt or the handoff feeding it. Owner: the person running the chain. The recovery play is what makes a chain resilient rather than brittle.
Play Six: The Capture
Trigger
A chain has produced reliable results more than once.
The Move
Document it — purpose, each step's prompt, inputs, outputs, known limits — and move it into a shared library. An undocumented chain that works is a chain that dies when its author forgets it. Owner: the chain builder, handing off to a named maintainer. The capture discipline is detailed in Building a Repeatable Workflow for Decomposition Prompting.
Play Seven: The Maintenance Review
Trigger
A scheduled interval passes, or a model update or requirement change occurs.
The Move
Run the chain against fresh inputs, confirm the verification steps still catch problems, and retire or fix anything that has drifted. Collapse steps that never earn their keep. Owner: the named maintainer. This play keeps the library trustworthy instead of letting it rot, which connects directly to the team practices in Rolling Out Decomposition Prompting Across a Team.
Sequencing The Plays Under Pressure
The Minimum Viable Run
Under time pressure you will not run all seven plays in full. The minimum viable sequence is decompose-or-not, the split, and a single end verification. That alone beats a monolithic prompt on a hard task. The handoff design, multiple verification points, capture, and maintenance are upgrades you add as a workflow proves it will be repeated. Knowing which plays are essential and which are optional is what lets the playbook survive real deadlines.
Escalating From Quick To Durable
Treat the plays as a ladder. The first time you run a task, you might use only the minimum. The second time it recurs, you invest in the handoff design and tighter verification. By the third or fourth recurrence, you capture and assign a maintainer. This escalation matches investment to evidence of reuse, so you never over-build a chain for a task that turns out to be a one-off.
Knowing When To Abandon A Chain
A play the playbook implies but rarely states: retirement. When a workflow stops being run, or a model change makes a chain more trouble than it is worth, the right move is to retire it cleanly rather than keep it on life support. A maintained library is as much about removing dead chains as adding new ones, which keeps the whole system trustworthy.
Frequently Asked Questions
What fires the very first play?
A non-trivial task about to be handed to a model — one that is multi-stage, high-stakes, or has failed as a single prompt before. The decompose-or-not play runs before any prompt is written and forces an explicit decision rather than a default in either direction.
Who should own each play?
Mostly the person building or running the chain, with a named chain owner accountable for the end-to-end result and a maintainer responsible for keeping it current. The key is that ownership is explicit at the chain level, not just the step level, so nothing falls through the cracks.
What is the most commonly skipped play?
The handoff design. Beginners connect steps by passing whatever output is convenient, which degrades intent stage by stage. Deciding deliberately what context each step needs is the play that separates a chain that preserves meaning from one that loses it.
What do I do when a step keeps failing?
Stop re-running it and fix its design. Repeated failure of the same step means the prompt or the handoff feeding it is the problem, not the individual run. The failure-recovery play distinguishes a one-off error, which you re-run, from a structural flaw, which you redesign.
How often should the maintenance review fire?
On a regular schedule and whenever a model updates or requirements change. Chains decay silently because each step keeps running without erroring, so periodic review against fresh inputs is the only way to catch drift before it ships subtly wrong output for weeks.
Can I use the playbook as a reference instead of running it end to end?
Yes. Read end to end it is a full sequence for any complex task, but each play is named and trigger-based so you can reach for the specific one a situation calls for — the split, the handoff design, the failure recovery — without running the whole thing.
Key Takeaways
- A playbook makes good decomposition the default by defining plays, triggers, owners, and sequence instead of relying on inspiration.
- Play one is an explicit decompose-or-not decision based on distinct phases, prior failure, and cost of error.
- The split and the handoff design are where chains succeed or quietly degrade; carry exactly the context each step needs.
- Place verification after high-leverage steps and at the end, make checks specific, and test the validators.
- Recover from failure by re-running the earliest failing step, and redesign any step that fails repeatedly rather than re-running it.
- Capture proven chains into a maintained library and review them on a schedule so they do not rot into untrustworthy assets.