Build Your Recipe

You arrive with a problem. You leave with a recipe: a short, ordered plan that names which reasoning frameworks to use, in what order, and, just as important, which ones to leave out. Answer one question per axis in the builder below and copy out a recipe card, or read the same steps as prose.

One example runs through the whole page. So you can watch a recipe come together instead of studying rules in the abstract, every step below is applied to the same real problem:

"Build a comprehensive set of charts in our support team's Dashboard sheet that show how the metrics we track, ticket volume, response time, agent load, CSAT, influence each other."

It makes a good tour because it's a build task, not a single-answer question: it will use five of the seven axes, skip one, and nest two frameworks on one axis, the moves real work actually needs. Each step below shows the call we make for it, and the finished recipe card waits at the end of the page.

First, what's an axis? The thirteen frameworks in the playbook aren't thirteen rival options. They do seven different kinds of job, and each kind is one axis, the way a dish has different kinds of ingredient: a base, a main, a cooking method, a seasoning. You pick at most one framework per axis, and you skip the axes your problem doesn't need. That's the whole trick, and it's why this page asks seven small questions instead of one impossible one ("which of thirteen frameworks do I want?").

Here are the seven axes, in the order this page walks them:

Why the letters jump around. A through G are catalog codes from the frameworks page, where the axes are listed alphabetically. But you don't assemble a prompt alphabetically, you build in the order above: rules first, then structure, then outside help, then checking, then a final nudge. This page uses build order everywhere, so the letters read E, D, A, C, F, B, G. That's deliberate, not a typo.

Three moves people miss. These separate a real recipe from a pile of ingredients:

• Skipping is normal. Most good recipes leave axes out. Nothing to look up or compute? Skip Grounding. No single answer to vote on? Skip Sampling. Skipping is a decision, not a gap, you don't reach for every spice on every dish.
• Two frameworks share an axis only by nesting. The one exception to "one per axis": one framework can run inside another on the same axis, like a filling that bakes inside its pastry. The classic case: PAL (compute in code) running inside a ReAct tool loop, both live on Grounding.
• Look at your real data before picking anything. The most valuable ingredient isn't a framework at all, it's a short list of rules you learn from your actual data. That's Step 0, next, and no framework does it for you. Check what's in the fridge before you plan the menu.

Step 0: Look at your real data first#

Every pick you'll make below depends on facts only you can see: what your data actually looks like, and what would make an answer wrong or misleading. So before choosing anything, open the real thing, the actual spreadsheet, the actual tickets, the actual codebase, and write down a short numbered list of rules a good answer must respect.

Check what's in the fridge before you plan the menu, not halfway through cooking.

What does a "rule" look like? Concrete, and specific to your data, not general advice. For the running example, opening the actual ticket sheet yields rules like:

1. There's only one quarter of data, treat every correlation as a maybe, not a fact.
2. CSAT is rated 1–5. That's a ranking, not a quantity, don't do math on it as if a 4 were twice a 2.

Rules like these don't come from any reasoning technique; they come from looking. But the model can help you write them, paste in a sample of your real data and ask it to name the rules before solving anything. Here's that prompt, filled in for the running example. For your own task you swap only the first two sections, the task and the data sample; the "Step back" ask stays word-for-word:

markdown## Task
Build a comprehensive set of charts in our support team's Dashboard sheet that
show how the metrics we track, ticket volume, response time, agent load,
CSAT, influence each other.

## Input
<input>
date,       tickets, backlog, avg_response_hrs, agents_on, csat
2026-04-06,  142,     31,      5.2,              6,         4
2026-04-07,  158,     37,      6.1,              6,         3
2026-04-08,  201,     58,      9.8,              5,         3    <- launch day
2026-04-09,  187,     71,     11.4,              5,         2
…one row per day, ~90 rows in all
</input>

## Step back
Before solving, list the governing principles this answer must respect, the domain
rules, the traps hiding in this specific data, and what would make a result
misleading. Do not solve yet.

## Output
Principles: a short, numbered list

Notice how much the data sample alone gives the model to work with: it can see the 1–5 CSAT column, the ~90-row size, and the launch-day spike, the raw material for exactly the rules above.

Keep the list. It goes at the top of your recipe card, and it will steer several of the picks you make below.

Wait, isn't this just the Step-Back framework (E1)? Same move, different moment. Step 0 is something you do once, right now, while designing the recipe. Axis E, in the builder below, asks a different question: whether the finished prompt should also make the model restate the governing rules every time it runs. Doing Step 0 doesn't decide axis E for you, but the list you just wrote feeds the prompt either way.

Build it, axis by axis#

The builder opens with the task itself and where the input lives, the same two sections you filled at the top of the Step 0 prompt. They ride along into everything the builder produces: the recipe card, the prompt scaffold (so the paste is self-contained), and the AI critique (so the critic can see what you are actually solving, not just how you plan to solve it). Then answer the questions for each axis. Pick one framework, or mark the axis skip. Work top to bottom; that's the order you'll assemble them in, not alphabetical. Each axis shows the call we make for the running example, so you can see what a real answer looks like, and the Load the running example button fills the whole builder in at once if you'd rather start from the finished recipe and poke at it.

Assemble it, top to bottom#

The order you answered the axes in is the order they stack in. Three placement rules are the only subtlety, and the diagram below lights up the stages your own recipe actually uses:

• **Grounding (C) runs inside the reasoning loop.** The calculator stays in hand while you cook, not before or after.
• **Checking (F) and voting (B) wrap the outside.** You taste the finished dish, and you can only pick the best plate once several exist.
• Steering (G) is woven throughout. Seasoning, not a course of its own.

There is nothing to assemble by hand: the card the builder produces already ends with the matching prompt scaffold, each pick's instruction block stitched in this order below the scissors line. Skipped axes contribute no block.

Filling the {{blanks}}#

The scaffold leaves a few {{blanks}} for you to fill. Here is each one, an example, and where it comes from:

• {{describe the task, one or two sentences}} and {{where the input lives: paths, URLs, sheets}}: only present if you left the task and input fields empty in the builder. Fill them there instead; every downstream output inherits them.
• {{your Step 0 rules}}: the numbered principles you wrote in Step 0. Example: "1. Treat every correlation as tentative on a small sample. 2. Do not do math on the 1 to 5 CSAT scale." You get these by looking at your real data in Step 0 above.
• {{your test / rule / lookup}} (the Self-Refine verifier): the concrete thing the model revises against. Example: "the unit tests in tests/," or "the five Step 0 rules," or "the live prices in the pricing sheet." You get it by naming whatever can prove the answer wrong. If nothing can, skip Self-Eval.
• {{your checker}} (the Reflexion pass/fail signal): what tells an attempt it passed or failed. Example: "the test suite goes green," or "the SQL returns the expected row count."
• {{a few hint words}} (the Directional Stimulus cue): the focus you want to nudge toward. Example: "downside protection, survivable worst case." You get it from what matters most in the answer.

No real verifier for a self-correction step? See Output Eval Rubrics for what makes a good checker, and for scoring the output once you have it.

A complete worked example (for comparison)#

Your card is above. This is a reference-quality recipe to compare yours against, built on the support-dashboard problem that runs through this page.

You've now made every decision one at a time; the card gathers them all in one place. It has two halves. Above the scissors line, the decisions, what you picked, why, and what you skipped, the half worth filing in your decision log. Below it, the paste-ready prompt scaffold. Here's the card for the support-dashboard problem, why column included; press Load the running example in the builder to get the same card with the scaffold attached. (Being a build task rather than a single-answer question, it behaves differently from the Q&A stacks in Reasoning-Framework-Worked-Examples: it skips an axis and nests two frameworks on one, which real work does all the time.)

Step 0, the rules, from looking at the real sheet. The full version of the list started in Step 0:

1. The sample is small (one quarter of daily rows), so treat every link (correlation) you find as a maybe, not a fact.
2. Several metrics can move together without one causing the other, a product launch spikes ticket volume and sinks CSAT at the same time (a shared-event confound).
3. Compare a day to the day before, not to itself (use a lag), yesterday's unresolved backlog drives today's response times.
4. Rank the days rather than trusting the exact numbers (rank correlation), and always show the dot plot (the scatter), not just a single score.
5. The 1–5 CSAT ratings are rankings, not real amounts (an ordinal scale), a 4 isn't "twice" a 2, so don't do math on them as if it were.

That list is the part a pile of frameworks won't give you. It came from looking at the sheet, not from any technique.

The picks.

Assembly (top to bottom). Step-Back → Plan-and-Solve → Skeleton-of-Thought → [per chart: PAL inside ReAct] → Self-Refine, with a light Directional Stimulus cue throughout.

Why this beats a plain prompt. The frameworks give the structure, but the list of principles, go easy on a small sample, watch for things that just move together, compare each day to the one before, rank the days and show the dots, don't do math on 1–5 ratings, is what keeps the charts honest. And that came from Step 0.

Next step: judge the output. Once you have a card, run its prompt in your LLM, then take what it returns to Output Eval Rubrics. A generator there turns your output into a ready-to-run evaluation prompt, and tells you whether the result is trustworthy enough to ship.

See Advanced-AI-Reasoning-Framework-Playbook for what each framework is and when to use it, and Reasoning-Framework-Worked-Examples for more finished stacks, including this one as Example 4.