Most advice on prompting models through dependent decisions stays at the level of principles. Principles are fine until you are staring at a real problem and need to know what to do first, who is responsible for it, and what comes next. A playbook is different from a guide because it is organized around moves you can actually run, each with a trigger that tells you when to use it and an owner who is accountable for it.
This is that kind of resource. It treats sequential decision making as a set of named plays that fit together into an operating sequence: how you decide a chain is warranted, how you build it, how you harden it, and how you keep it alive once it is in regular use. Each play states when it fires and who owns it, so the practice becomes something a team can run rather than something one person improvises.
The plays are sequenced, but they are not rigid. Real work loops back, and several of these run continuously rather than once. Read them as a connected system, not a checklist you complete and abandon.
The Setup Plays
These plays run before you write a single prompt. They determine whether a chain is the right tool and what it has to accomplish.
The Dependency Check
Trigger: You are about to build a multi-step chain. Owner: The person designing the workflow.
Before committing to a chain, confirm the problem actually contains dependent decisions, where a choice at one stage changes what later stages should do. If a single structured prompt can produce the result reliably, run that instead. This play exists to stop you from paying the chain's reliability tax on a problem that does not need it.
The Decision Inventory
Trigger: The dependency check passed. Owner: Workflow designer.
List the genuinely distinct decisions the problem requires, and only those. This inventory becomes the skeleton of the chain. Resist adding steps for granularity; the inventory should be the minimum set of real decision points, because every extra one adds failure surface.
The Build Plays
These plays turn the decision inventory into a working chain.
The Step Specification
Trigger: You have a decision inventory. Owner: Whoever writes the prompts.
For each decision, specify its inputs, its allowed outputs, and the constraints that govern it. A specified step is one a reader can understand and a model can execute without guessing. Vague steps are where ambiguity and variation enter, so this play is where most chain quality is won or lost.
The State Restatement
Trigger: Any chain longer than a few steps. Owner: Prompt author.
Build the chain so that governing constraints are restated at each major decision point rather than stated once at the start. This directly counters state drift, the gradual loss of early rules as the chain grows. It is cheap insurance against one of the most common silent failures.
The Checkpoint Placement
Trigger: The chain handles anything consequential. Owner: Workflow designer, with the accountable owner's sign-off.
Decide where intermediate results get verified before later steps build on them. Place checkpoints at the points where an undetected error would do the most downstream damage. This play is what stops a small early mistake from compounding invisibly through the whole sequence.
The Hardening Plays
These plays move a chain from "works on my examples" to "trustworthy in real use."
The Varied-Input Test
Trigger: The chain works on its original examples. Owner: Whoever will deploy it.
Run the chain against inputs that differ meaningfully from the ones it was built on. Chains get implicitly tuned to their examples, and this play exposes the hidden coupling and brittle assumptions that only surface on unfamiliar input. Reliability comes from testing the edges, not from the chain working once.
The Coupling Probe
Trigger: You are about to rely on a chain in production. Owner: Prompt author.
Deliberately change one step and observe what happens downstream. Steps are coupled by default, and this play makes that coupling visible so it stops being a source of surprise. A chain whose coupling you understand is one you can maintain; one whose coupling you do not is a trap.
The Failure-Mode Log
Trigger: Continuous, from first real use onward. Owner: The accountable owner.
Record every way the chain fails in practice, where it commits too early, where it drifts, where it produces confident nonsense. This log turns individual debugging into shared knowledge and feeds back into the step specifications. It is the play that makes the chain get better over time instead of just aging.
The Operating Plays
These plays keep a chain healthy after it is in regular use.
The Designated Review
Trigger: The chain produces any consequential output. Owner: A named human reviewer.
Ensure there is always a defined point where a human inspects results before they propagate. The compounding-error problem means consequential chains cannot safely run fully unsupervised. This play assigns the review explicitly so it does not get skipped by default.
The Decision Record
Trigger: Every consequential run. Owner: Accountable owner.
Capture the prompts, intermediate outputs, and final result so any decision can be reconstructed later. Without a record, every error becomes an unsolvable mystery and there is nothing to defend an outcome with. This play is the difference between a traceable process and a black box.
The Maintenance Cadence
Trigger: Recurring, on a set schedule. Owner: Accountable owner.
Review the chain periodically against current needs and current model behavior. Models change and requirements drift, so an unmaintained chain quietly decays. This play assigns explicit responsibility for keeping it current rather than letting it rot.
The Recovery Plays
Even well-run chains fail. These plays cover what to do when one does, so a failure becomes a lesson instead of a recurring wound.
The Trace-Back
Trigger: A chain produced a wrong outcome. Owner: Accountable owner, using the decision record.
Walk forward through the captured intermediate outputs to find the first step whose result was wrong. Everything after it inherited the error, so the first bad step is the one to fix. This play depends entirely on having kept a decision record, which is why that operating play matters so much. Without the record, trace-back becomes guesswork.
The Structure Review
Trigger: A chain fails repeatedly despite prompt fixes. Owner: Workflow designer.
When rewording a step does not stop the failures, examine the chain's shape instead. Ask whether a step should be split, merged, or removed, whether a checkpoint is missing, or whether a step depends on information it never receives. Many persistent failures are structural, and this play stops the team from endlessly polishing wording on a chain that needs rebuilding.
The Postmortem Feed
Trigger: After resolving any significant failure. Owner: Accountable owner.
Once a failure is understood and fixed, feed what you learned back into the failure-mode log and the step specifications so the same problem cannot recur silently. This play closes the loop, turning each failure into a permanent improvement rather than a one-time repair. A chain that runs this play steadily hardens; one that does not keeps relearning the same lessons.
Frequently Asked Questions
Do I have to run every play?
No. The setup and build plays apply to almost any chain. The hardening and operating plays scale with stakes: a low-stakes internal chain needs less than a consequential one. Match the plays to how much being wrong would cost.
Who should own the playbook overall?
A named person accountable for the chain's outcomes, supported by whoever has the deepest prompting skill. Ownership without expertise produces plays that do not work; expertise without ownership produces plays nobody runs.
How is a playbook different from a workflow?
A workflow is the documented, repeatable process for running a chain end to end. A playbook is the set of named moves, each with a trigger and owner, that you assemble into that workflow and use to handle the situations that come up. The two are complementary.
What is the most important single play?
Checkpoint placement, for consequential chains. It directly counters compounding error, which is the failure mode that does the most quiet damage. State restatement is a close second.
How do these plays handle a team rather than a solo user?
Ownership and the operating plays carry most of the team load by assigning clear accountability and review. Rolling them out consistently across people is itself a change-management effort beyond the plays themselves.
When should I retire a chain?
When the maintenance cadence reveals it no longer fits current needs or model behavior, and updating it would cost more than rebuilding. A failure-mode log full of recurring problems is a strong signal it is time.
Key Takeaways
- Treat sequential decision prompting as named plays with explicit triggers and owners, assembled into an operating sequence, not a loose set of principles.
- Setup plays decide whether a chain is warranted and inventory only the genuinely distinct decisions, avoiding the over-decomposition trap.
- Build plays specify each step, restate state at every major step to fight drift, and place checkpoints where undetected errors would do the most damage.
- Hardening plays test varied inputs, probe coupling, and log failure modes so the chain becomes trustworthy and improves over time.
- Operating plays assign designated human review, a durable decision record, and a maintenance cadence so consequential chains stay accountable and current.
To put these plays into a documented process and scale them, see Building a Repeatable Workflow for Prompting for Sequential Decision Making, Getting Sequential-Decision Prompting to Stick With a Whole Team, and The Hidden Risks of Prompting for Sequential Decision Making.