DEV Community

Cover image for The Pizza-Builder Pattern: Stop Guessing, Start Building a Menu
Prasad MK
Prasad MK

Posted on

The Pizza-Builder Pattern: Stop Guessing, Start Building a Menu

Ask an AI to "write a novel" and you get one of two outcomes, and both annoy me.

It guesses. Genre, protagonist, tone, all invented on the spot. You read the output, realize it missed, and burn a full generation cycle starting over.

Or it interrogates you. One clarifying question at a time, four turns deep, until you've typed more than the request would've taken to write yourself.

I got tired of both, so I built a Claude skill called pizza-builder. One screen, one menu, done.

Why a pizza counter

Build-your-own works for a reason most people never stop to think about. Someone already figured out which decisions matter (base, sauce, cheese, toppings) and narrowed each one to a short list of good options.

You don't invent a pizza from nothing. You compose one from a menu somebody designed well.

I applied that same logic to AI requests. Turns out the fix isn't a better prompt. It's a better structure.

The rules that make the menu work

Find the real decision points, not generic categories.
Weak: "Genre: Fantasy / Sci-fi / Mystery / Other"
Sharp: "Cozy small-town mystery / Hard sci-fi with a ticking clock / Literary fiction about a family secret / Epic fantasy with a political core"

Specific options let you react instantly. Generic labels just restate the question back at you, and nobody's ever been helped by that.

Match the question to its actual shape. Not every decision is "pick one of four." I count seven shapes that actually show up:

  • Toggle for a plain yes/no fact, like whether this needs to survive a reboot
  • Radio for a short list where picking one rules out the rest
  • Dropdown for six or more options, so the screen stays scannable instead of a wall of buttons
  • Skip option for anything an expert might actively argue against, like not bothering with a cache
  • Slider for a spectrum, "70% tomato, 30% pesto," instead of a fake list pretending to be a continuum
  • Checkbox for anything genuinely additive
  • Free text for a number, name, or path, because forcing that into buttons just looks tidy and helps nobody

Give every option a real "you decide." Not a shrug. A stated pick, with a reason, the way a good server tells you "I'll bring you the fish, it's better tonight" instead of handing the decision right back to you.

Synthesize, don't summarize. Four specific picks need to produce something that couldn't exist without all four combined. If the output just mentions each keyword once, the synthesis failed, not the menu.

The failure that taught me the hard rule

A sunset-image picker I built once generated a prompt that said "no horizon element" in one line and "bands from horizon to zenith" two lines later. Code ran fine. Buttons worked. The image came out as flat color stripes, because the prompt itself was fighting with itself and nobody caught it.

Same picker, different bug: it generated this line and shipped it straight to the user. "Can you write me a detailed, ready-to-use prompt for this, and flag anything I should reconsider?"

Every automated check passed. Syntax clean, buttons functional, nothing throwing errors. And the output was a question thrown back at the person who'd already answered five questions to get there.

That one stung more than the horizon bug, honestly, because it revealed something worse: passing tests tells you the code runs, not that the content does anything. So now every generated prompt gets read against three failure shapes before it ships, not just executed:

  • Missing anchor: nothing stated that makes the subject actually recognizable
  • Self-contradiction: one line quietly undercutting another
  • Punt-back: a question aimed at the reader instead of an answer

The mechanical test for the last one is almost embarrassingly simple: does the output contain "can you," "write me," or a question mark pointed at the user? If so, it's asking for the work instead of doing it, and I'd rather catch that before someone else does.

When to use this, and when not to

Route on structure, never on topic. I learned this the hard way, too. Any list of "domains this applies to" is guaranteed to miss the next domain, so I stopped keeping one.

Use the menu when:

  • There's no single obvious interpretation
  • A wrong guess costs a real redo: a full draft, a rendered image, a deck
  • The request has three or more independent decisions, not just one missing detail

Skip it when:

  • There's a clear default (a headline: just write two or three and move on)
  • The task is cheap to redo (a tweet, a rename)
  • You want an actual opinion, not a menu dressed up as one ("Python or JavaScript?")

Get the skill

The full SKILL.md lives here: https://github.com/prasad-m-k/claude-skills/tree/main/pizza-builder

Claude: Add it as a custom skill. Download the file, upload it in Claude's skill settings (or drop it into your skills folder on Claude Code), and it triggers on its own when a request fits.

ChatGPT: No native skill system, but the pattern still works fine. Create a Custom GPT or Project and paste the SKILL.md content into its instructions field. It'll follow the same dimension-and-shape logic when it builds a clarification screen.

Gemini (Gems): Same move. Create a Gem, paste the file into its instructions, and it runs the same rules: find the real decision points, classify their shape, build the menu fresh every time.

None of these platforms need the exact file structure. The value sits in the rules, not the format, so paste it in wherever the model keeps its persistent instructions and it holds.

The real takeaway

Early versions of this skill shipped a fixed template with pre-built dimension renderers. It only covered three of the seven shapes. Every new request had to get checked against that file's limits, and that check kept getting skipped, because who remembers to check a limit they don't know exists.

I didn't fix it with a bigger template. I deleted the template. Every menu gets built fresh now, against whatever the current rules say, every single time. Nothing cached, so nothing drifts out of sync while I'm not looking.

If I take one thing away from building this, it's that a good clarification system isn't a form with extra fields bolted on. It's a habit of figuring out, fresh, every time, which decisions actually matter and how each one deserves to be asked.

Top comments (0)