Newest addition to the workshop: a game. A real, playable, works-on-the-kids-tablet game — winged weather friends flying over a storybook meadow, growing flowers to summon a rainbow. The chief designer is eight years old. The concept art was a marker sketch. The engineer was an AI coding agent.

This isn’t an Aillex pipeline post — it’s a story about the one prompting decision that made the whole project work, because it applies to everything on this site.

The prompt line that did the heavy lifting

The very first message to the coding agent ended like this:

“Before you write any code or take any action, other than gathering helpful information from the internet, please ask clarifying questions for all things that you are unsure of and list any assumptions that you are making.”

That’s it. That’s the trick.

Every failed AI project I’ve had follows the same arc: you give a vague, excited description; the model makes fifty silent guesses; it confidently builds the wrong thing; you spend the rest of the session un-building it. The guesses were the problem — not the code.

This line reverses the arc. Instead of fifty silent guesses, we got a list of questions — and answering them with the chief designer became the actual game-design session.

Questions become the design document

A kid’s game pitch is a beautiful, vague thing: “the weather friends shine on the flowers and they grow and you get a rainbow!” An engine can’t run that. But look what it becomes when the clarifying pass forces decisions:

  • What happens if you shine the wrong weather on a flower? → It gets sick — sad face, droopy, greenish. (Her call. Immediately followed by: “but you can make it better!” — which became a healing window.)
  • Can you lose? → Three wilted friends and you get a friendly try-again screen. Wilted friends sprout back, so a level is never impossible.
  • Do the sun and the cloud interact? → Rain knocks out the sun (X eyes!). Sun makes the cloud angry — and an angry cloud rains harder, which some thirsty plants want. A punishment mechanic became a strategy mechanic in one sentence.
  • How do you win? → Collect all seven rainbow colors; all four weather friends fly into formation and paint the rainbow together.

None of that was in the pitch. All of it came out of the question pass. The resulting design doc — difficulty tables, healing-window timings, touch controls — reads like a professional spec, and an eight-year-old made most of the calls.

The assumptions list matters just as much

The second half of the line — list any assumptions you are making — catches the guesses that questions miss. “I’m assuming keyboard and mouse” surfaced early; the correction (“it has to work on a kids’ tablet”) changed the architecture: pointer events for mouse/touch/pen, and a genuinely thoughtful touch design where dragging your finger moves the friend with the beam off, so sweeping across the meadow can’t accidentally sicken anyone. That’s the kind of edge case that sinks projects when it’s discovered late.

Boring tech, deliberately

Vanilla HTML5 canvas and JavaScript. No engine, no build step, four JS files, runs offline in any browser. When your engineer is an AI, dependency-free is a superpower: nothing to install, nothing to version-mismatch, and the whole game is small enough for the agent to hold in its head at once.

Why this belongs on this site

Everything else here — the voice cloning, the lip-sync, the video pipelines — got built through the same loop: describe, let the model surface its uncertainty, decide, then build. The game just proves the loop works on anything, including a collaboration where the product owner is eight and communicates in marker sketch.

Steal the line. Put it at the end of your first prompt on every project:

Before you write any code or take any action, ask clarifying questions for everything you’re unsure of, and list the assumptions you’re making.

The answers are the project.