A guide tells you what is true. A playbook tells you what to do, when to do it, and who is responsible. This is the second kind. It assumes you already understand that different model architectures behave differently and that you now need a repeatable way to act on that understanding inside real projects.
The structure is a set of named plays. Each play has a trigger that tells you when to run it, an owner who is accountable for it, and an output that feeds the next play. You do not run all of them all the time. You run the one whose trigger has fired.
Treat the plays as modular. A small team might collapse several owners into one person. The point is that every play has a clear answer to "who does this and when," so nothing falls through the gap between roles.
Play One: Target Declaration
Every prompt destined for production starts here. Before anyone tunes wording, the prompt's intended model targets are declared and recorded.
Trigger and owner
- Trigger: a new prompt is created for production use.
- Owner: the prompt author.
- Output: a labeled prompt with declared target architectures and models.
This play exists to kill the single most common failure: a prompt reused on a model it was never meant for. Declaring the target up front makes accidental reuse visible later. Standardizing Cross-Architecture Prompting Without Slowing Anyone Down explains why this labeling anchors everything else.
Play Two: Architecture Fit Check
Before heavy tuning, sanity-check whether the chosen architecture suits the task. There is no point optimizing a prompt for a model whose architecture fights the requirements.
Trigger and owner
- Trigger: target declared, before optimization begins.
- Owner: the prompt author, with input from anyone who knows the models.
- Output: a go or reconsider decision on the model choice.
The check is quick: does the task need strict constraints, native reasoning, long context, or low latency, and does the chosen architecture support that? If the answer is no, change the model now, not after you have invested in tuning.
Play Three: Validation Pass
The core play. The prompt is run against its declared targets on realistic and adversarial inputs, and compliance is checked explicitly.
Trigger and owner
- Trigger: a tuned prompt is ready, or a model is swapped.
- Owner: a reviewer who did not write the prompt.
- Output: a pass or fail with recorded evidence per target.
Independent review matters here because authors read their own prompts charitably. A second person checking constraint compliance against stress inputs catches the quiet failures. The mechanics are detailed in Adapting One Prompt to Several Models, Step by Step.
Play Four: Portability Decision
When a prompt needs to run on more than one architecture, decide the structure: one shared prompt, a shared core with overrides, or fully separate prompts.
Trigger and owner
- Trigger: a prompt is needed on a second architecture.
- Owner: the standard maintainer.
- Output: a chosen prompt structure with documented rationale.
The default should be the lightest structure that passes validation on all targets. Forking is a cost, so the burden of proof sits with separating, not sharing. Cross-Model Prompting Principles Worth Defending covers how to build a portable core that survives this decision.
Play Five: Model Swap Response
The play that fires when a model is changed underneath an existing prompt, whether by a version update or a deliberate switch.
Trigger and owner
- Trigger: a model version update or architecture switch in production.
- Owner: the library steward.
- Output: revalidated prompts and an updated rollback plan.
This is where set-and-forget teams get burned. A model swap invalidates prior validation, so the prompt re-enters Play Three. Treat every swap as a trigger to revalidate, never as a transparent substitution.
Play Six: Incident Review
When a cross-architecture failure reaches production, this play turns the failure into a durable improvement.
Trigger and owner
- Trigger: a production incident traced to architecture differences.
- Owner: the standard maintainer.
- Output: an updated standard and, if warranted, a new validation case.
The objective is to ensure the same class of failure cannot recur silently. Each incident either confirms the standard or improves it. Over time this is what makes the playbook better than any individual's intuition.
Play Seven: Library Hygiene
The maintenance play that keeps the whole system trustworthy over time. Without it, the prompt library accumulates stale entries until people stop trusting it and start writing from scratch, which defeats the point.
Trigger and owner
- Trigger: a regular cadence, such as monthly, plus any model retirement.
- Owner: the library steward.
- Output: a pruned library with current, accurate metadata.
The hygiene play removes prompts validated only against retired models, flags entries whose targets are now stale, and confirms metadata still matches reality. A library people trust is one they reuse; a library they distrust is dead weight. This play is unglamorous, which is exactly why it needs a named owner and a fixed cadence rather than depending on someone noticing the rot.
Sequencing the Plays
The plays connect into a loop. A new prompt runs One through Three. A multi-model need adds Four. Production life triggers Five and Six as conditions arise, while Seven runs on a steady cadence underneath all of it.
The default sequence
- Target Declaration for every production prompt.
- Architecture Fit Check before tuning.
- Validation Pass before shipping.
- Portability Decision when a second architecture appears.
- Model Swap Response whenever a model changes.
- Incident Review whenever a failure escapes.
- Library Hygiene on a steady cadence regardless of the others.
Run the play whose trigger has fired, assign its owner, and feed its output forward. That discipline, not any single clever technique, is what makes cross-architecture prompting reliable at scale.
Frequently Asked Questions
Do I have to run all the plays for every prompt?
No. Every production prompt runs Target Declaration, Architecture Fit Check, and Validation Pass. The remaining plays fire only when their triggers occur: a second architecture, a model swap, a production incident, or the regular hygiene cadence. Run the play whose trigger has fired, not the whole set every time.
Who owns these plays on a small team?
One person can own several. The plays separate responsibilities so nothing falls through the gap between roles, but a small team might have the author, reviewer, and maintainer be two people or even one wearing different hats. The point is a clear answer to who does each play and when.
What is the most important play to adopt first?
Target Declaration, because it prevents the single most common failure: reusing a prompt on a model it was never validated for. Labeling targets up front makes accidental reuse visible and anchors every later play. It is also the cheapest play to adopt.
How is the Validation Pass different from just testing my prompt?
It requires an independent reviewer, realistic and adversarial inputs, explicit constraint checking, and recorded evidence per target. Authors read their own prompts charitably and miss quiet failures. The independence and the stress inputs are what make it catch problems casual testing does not.
When does a model version update trigger the playbook?
Always. A version update is a Model Swap Response trigger that sends the prompt back through validation. Prior validation was true for a specific model version, so an update can change behavior. Treat every update as a reason to revalidate, never as a transparent substitution.
How does Incident Review improve the playbook over time?
Each production failure traced to architecture differences updates the standard and, when warranted, adds a new validation case. This ensures the same class of failure cannot recur silently. Accumulated over many incidents, the standard encodes hard-won knowledge no individual carries in their head.
Key Takeaways
- A playbook differs from a guide by attaching triggers, owners, and outputs to every action.
- Target Declaration prevents the most common failure and anchors every later play.
- The Validation Pass needs an independent reviewer and adversarial inputs to catch quiet failures.
- The Portability Decision defaults to the lightest structure that passes validation.
- Every model swap or version update retriggers validation; never substitute transparently.
- Incident Review turns each escaped failure into a durable improvement to the standard.