Make your big idea a game.

What the AI will do

• Find the idea and audience context, then turn the central insight into choices players can make and consequences they can experience.
• Use researched workplace-game examples to develop a playable version, test the rules and prepare a debrief that connects play to the idea.

What you can provide

• An idea in any usable form: a rough explanation, deck, memo, talk or argument.
• The intended players and setting if you know them; the AI will look for relevant audience and event records.

Where you'll take part

• Clarify the insight, choose the game experience and review the first playable version.
• Play a short pilot or bring actual participants when possible, then judge whether the game helps them grasp what matters.

What you'll get

A playable game with clear rules, materials and facilitation notes, a debrief tied to your idea, and an honest account of what was checked and what actual players understood.

Activity context

Instead of telling colleagues that local incentives can damage the whole company, let each of them run one part of it. Instead of explaining why priorities are hard, give everyone a budget too small to buy everything. The game gives your idea something people can do—and something worth talking about afterward.

For the user

Bring the idea you want people to understand. The AI will investigate its evidence and audience, show you a few game mechanics that could express it, and build the chosen version. You will settle the central point and try the result; actual player responses will help distinguish a clever set of rules from an idea people have understood.

Guidance for the AI

These are general instructions, not a description of this user's particular AI system, tools, access, or circumstances. Adapt the method to the user's goal and the capabilities you can actually use, while preserving the activity's essential sequence, review points, and intended result.

Start with the activity and the user's context

Read the complete activity and guide the user through it. Use the activity prompt yourself; the user does not need to paste it again. Keep the responsibilities of the user, the AI, and any colleague clear.

Begin with what the user has already supplied. Establish the intended result and resolve missing context through focused questions when needed. Work within the activity's stated scope, permissions, required confirmations, and stopping points, including any deliberate order for introducing information. Make progress with the available information and reasonable, clearly identified assumptions where the activity allows them.

Check the capabilities needed for this work

Inspect relevant available tools, connectors, and data. Use small, relevant, non-destructive checks to establish whether necessary access or a capability actually works. Naming a product does not establish access to it. Let this activity determine what needs checking; do not impose a universal preliminary questionnaire or a full system audit.

When useful access is missing:

• Explain what you cannot reach and how that material would help.
• Investigate practical setup, connection, export, or other access alternatives before asking the user to gather material or troubleshoot.
• If progress depends on access, request only the specific user action or permission needed to enable it or provide the material another way. Continue useful independent work while awaiting the response.
• Offer to walk the user through an export or upload. Welcome files, links, copied text, rough notes, or an interview as supported by your system and the activity, and use the best available route. If the missing access is optional, continue with what is available.

Ask focused questions and respect the answers

Ask questions only when necessary to complete the work well or satisfy the activity's required review points. Build on answers already supplied. Ask one question at a time, or a small group of closely related questions. Wait on work that depends on the answer, and continue useful work that does not. Explain unfamiliar language with examples where helpful.

Confirm answers or decisions you supply on the user's behalf before treating them as the user's final answers or decisions. This does not require separate approval of every sourced finding; follow the activity's specific review requirements.

Keep evidence and independent contributions distinct

Distinguish evidence, inference, and missing information. Check your work against the source material.

Use independent agents when your system actually supports delegation and independent investigation or review would improve the work:

• Give each agent a bounded brief and the context appropriate to its role.
• Keep discovery independent until synthesis where the activity requires it. Preserve any requirement for the user or colleagues to contribute before seeing other explanations.
• Follow the activity's stated fallback and any required confirmation when independent agents or fresh contexts are unavailable. Preserve reviewer isolation where required; describe shared-context or sequential passes accurately.

Produce, check, and revise the result

Do the substantive investigation and production. Carry the activity through to the most complete, usable result within its scope, rather than ending with a plan or handing the main work back to the user. When missing information does not prevent useful work, proceed with clearly identified assumptions where the activity permits them.

Check the result against the activity's completion criteria. At each substantive delivery, state what is complete and any material unfinished work, assumptions, helpful missing information, and remaining uncertainty. Explain how these affect what the user can use, and help the user revise the result.

Preserve the activity's stopping point. Do not turn a rehearsal, investigation, or test-design activity into execution that the user has not authorized.

Your AI prompt

Help me turn my big idea into a playable game for the intended audience. Make the important insight part of the players' decisions and consequences, and build the actual game in a feasible format.

1. Find the idea, evidence and audience

Read my rough explanation, deck, memo or other supplied material. Inspect and try access to the idea's drafts, supporting research, project documents, relevant email, chat and WhatsApp exchanges, meeting transcripts and past presentations. Search the idea's language and associated projects to establish the argument, its evidence, competing interpretations and questions people have already raised. Use the planned event's calendar invitation, attendee list, correspondence and relevant company roles to establish who will play, what they know, their expressed concerns and the situations in which the idea matters to them. Keep documented views separate from likely reactions inferred by us.

Summarize the central insight and what a player might understand by encountering it. Identify what the sources support, what is a hypothesis and what would be distorted by a simplified game. Ask one focused question at a time about consequential gaps, including the intended tone, setting, available time and whether players will be together or remote. Wait for agreement on the central point and any important creative choice. If records are unavailable, investigate connection or export options, then work from material I can provide and label the narrower basis.

2. Use workplace-game examples to choose a mechanism

These original-source examples provide different starting points. The descriptions establish game mechanics, not a claim that games generally improve learning:

• Buy a Feature: Luke Hohmann gives customers play money and priced features, including features that require people to pool their budgets. Scarcity creates negotiation over priorities. A proposed adaptation is to let players experience the tradeoffs behind our idea by deciding what to fund together. Creator's instructions.
• Speed Boat: Hohmann has customers place complaints beneath a boat as anchors and discuss what each represents. A shared visual metaphor makes constraints available for participants to describe and compare. It is a facilitated elicitation game, not a predictive simulation; a proposed adaptation is to let participants construct a picture of what holds a system back. Creator's instructions.
• Beer Game: MIT Sloan describes participants taking management roles in a supply chain, with materials for running and debriefing the game. A proposed adaptation is to distribute control of one business system among players and let them experience how decisions elsewhere affect their situation. MIT Sloan's game description.
• World Climate: Climate Interactive describes a role-play of international negotiations whose proposals receive feedback from C-ROADS. A proposed workplace adaptation is to give players distinct interests, have them negotiate and show consequences through an explicit model. Our model would need its own justified assumptions; an AI's invented numbers are not measured predictions. Climate Interactive's explanation.

Open the examples most relevant to this idea and inspect their actual mechanism. If a source cannot be read, use the bounded descriptions above or ask for the text; do not pretend to have inspected unavailable rules. Search additional original game or facilitator sources only if a specific design question remains. Attribute borrowed concepts and create our own materials rather than reproducing a commercial game wholesale.

Propose two or three genuinely different ways the audience could encounter the insight. For each, explain the player's role, meaningful choice, constraint, consequence and debrief question; show a miniature sample turn so I can feel the difference. Recommend one and let me choose. The mechanism must express the idea: adding trivia points to an explanation is insufficient when the intended learning depends on experiencing a tradeoff.

3. Build a playable first version

Inspect what this environment can create, run and share. Choose the simplest medium that can deliver the agreed experience: a browser game, a chat-facilitated round, a spreadsheet model, printable cards and a board, or a live negotiation with role briefs. Build in the chosen format. If the preferred runtime is unavailable, investigate a supported route and agree a working alternative. A rules outline alone does not fulfill a request for a browser game; a complete printable kit can fulfill an agreed tabletop game.

Specify the objective, player roles, setup, materials, opening state, legal actions, information each player sees, turn order or timing, consequence rules, scoring if useful, ending and reset. Give enough detail that a new facilitator can run it. Provide player instructions separately from facilitator notes and any reveal. Do not expose an intended discovery in the opening if learning depends on encountering it through play.

For every important consequence, identify the evidence or declared illustrative assumption behind it. Use worked examples to check the rules. Make uncertain relationships adjustable where useful. Avoid designing an inevitable victory for my argument: allow plausible choices and outcomes, including one that challenges or limits the central claim. If the idea cannot survive an honest game, show me the problem and revise the framing with me.

Divide substantial work usefully: an evidence pass establishes the supported insight; a design pass creates rules and materials from that brief; a separate tester receives the actual game and player-facing instructions without the designer's explanation of the intended lesson. Give each bounded inputs, source references and a concrete deliverable. Use waves if needed. Without separate agents, use clearly separated passes and identify that review shared context.

4. Play, observe and repair

Run a complete internal playthrough, testing initial setup, meaningful choices, calculation or state changes, ending and replay. Try at least one plausible unexpected move and one situation that might stall play. Have a fresh tester attempt to start from the delivered materials. Repair unclear instructions, broken logic, unusable controls and outcomes that contradict the declared rules; repeat affected checks. AI playtests assess the artifact and simulated reactions, not what real people learned.

Show me the playable version and incorporate my corrections. When actual participants are available, help run a short pilot using the agreed format. Record the choices they made, confusion they expressed and explanations they offered after play. Ask neutral questions about what happened, why they think it happened and where they see the connection to their work before telling them the intended lesson. Compare their answers with the central insight. Preserve surprises and misunderstandings instead of supplying a flattering learning result.

If no human pilot is available, deliver a working internally checked game and the ready-to-run pilot materials, making clear that audience comprehension remains untested. Do not invent player responses or postpone delivery merely because a pilot is still to come.

5. Deliver the game and its debrief

Provide the playable file, link or complete kit; concise player instructions; facilitator setup, timing and reset notes; and a debrief grounded in the actual game events. Connect choices and consequences to the business idea, explain the simplifications and ask where the analogy breaks down. Include source links for the underlying idea and borrowed mechanisms.

Summarize what was tested, the changes made and what any actual pilot established. Invite my review and make the final useful adjustments. Finish with something people can play and a clear way to discuss what the experience does—and does not—show about the real world.

Done when

You have a playable version in the agreed format, complete materials and rules, and a debrief that connects the experience to your idea. The game has been checked through a full playthrough; any actual audience pilot and remaining uncertainty about comprehension are clearly described.

Research & resources

Read the supporting research. Download research as Markdown.

These instructions were written in September 2026 using the frontier models available at the time. You may now have better tools or models, or restrictions that make some tasks harder. Your AI should adapt to the tools and access you actually have and find the best available way to help. Everything here is a starting suggestion for you and your AI, not a proven best practice for every setup. Feel free to rewrite any of it to better meet your needs.