Simulate a crisis with your team.
The factory has vanished. Or the supplier really has gone down. A crisis exercise can be gloriously silly or uncomfortably realistic. Let AI build the scenario and keep it moving while your team discovers how it makes decisions together.
Try it now
Copy the prompt into your AI tool of choice, then answer its questions as they come.
Paste it into any AI chat to start. For most people, this is all you need.
Everything on this page in one paste: the prompt plus the full plan, every step and what to check. Use it for longer moves, to plan ahead, to share with a colleague, or if your AI can't open links.
How it goes
What the AI will do
- Investigate the team’s responsibilities and design a crisis exercise in the tone and format you choose.
- Facilitate unfolding events live or asynchronously, record actual decisions and turn the debrief into practical improvements.
What to have ready
- The team and anything you want it to practice; a rough idea is enough.
- Available incident records, plans and working context; participation from the actual team when the exercise runs.
Where you come in
- Choose silly or serious, live or asynchronous, and what the team should learn.
- Take part in the scenario, then review what the team’s actual choices reveal.
What you'll get
A completed team exercise with a decision timeline, debrief and agreed improvements—or a ready-to-run package if participation or delivery is still pending.
You're done when
A completed team exercise with a decision timeline, debrief and agreed improvements—or a ready-to-run package if participation or delivery is still pending.
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. ### Choose the experience with me Help me run a crisis scenario with my actual team. It can be a playful game, a serious rehearsal or somewhere between. It can take place all at once, remotely or in person, or asynchronously through clearly labeled emails or messages. Ask what tone and format I want rather than assume a grim emergency drill. Use any context already supplied. Ask focused questions one at a time to establish the team, what we hope to learn, tone, live or asynchronous format, available time and intended participants. A silly scenario can expose real coordination patterns; a serious scenario can rehearse a specific concern. Offer a couple of concrete premises if they help me choose. Wait for choices that determine the design, while doing independent source investigation. ### Ground the exercise in how this team works Inspect available connections and search incident reports, response plans, escalation messages, project handoffs, relevant emails and chats, calendar invitations, team responsibilities and meeting transcripts. Use team, project and incident names to establish dependencies, who has information, who can decide and where earlier coordination worked or broke down. Establish roles and expressed concerns from records or participants, not inferred personality labels. Check the existing communication and meeting tools. For asynchronous play, investigate what you can actually schedule, send and receive. For live play, establish how participants see updates and return decisions. Try relevant access before requesting a user-only setup action. If records are unavailable, use a short interview and examples to design an explicitly invented exercise; do not call it a reconstruction of actual incidents. Agree the scope, participants, duration, channels, fictional premise and learning purpose. Define any limits on content or interruptions that matter for this team. Keep preparation proportionate: a short playful session does not need a company-wide investigation. ### Build the scenario and its separate views Write a runnable exercise with an opening situation, participant roles, initial information, a sequence of timed or decision-triggered developments, plausible branching consequences and a clear end. Use the team’s real dependencies where appropriate, while separating factual background from invented events. Make it possible for reasonable people to disagree and for more than one response to work. Do not rig every choice to prove the facilitator’s preferred lesson. Prepare a facilitator-only event plan containing hidden developments, release conditions, likely branches, time limits and debrief prompts. Prepare separate participant briefs containing only what each role would know at that point. Store and distribute them through genuinely separate access paths where the tools support it; a heading marked private inside a shared document does not keep a reveal hidden. If you cannot control access, give the confidential plan only to the facilitator and keep it out of shared materials. Label every fictional message, email subject, document, dashboard or injected update prominently SCENARIO. Explain the exercise framing to participants before it begins, including asynchronous players who may join later. Fictional requests must never trigger real payments, emergency calls, customer notices or production changes. The team records what it would do within the exercise. For a larger exercise, assign bounded preparation or supporting-role tasks to agents with explicit source material, allowed knowledge, return format and completion conditions. Preserve hidden information boundaries. Let a separate reviewer inspect the actual participant materials and event logic for confusing instructions, accidental reveals and impossible choices, then repair them. Without separate agents, perform distinct preparation and checking passes. ### Run it live or asynchronously For a live remote or in-person session, provide the opening brief and facilitate one development at a time. Ask participants for their decisions, reasoning, information requests and intended communications. Wait for their actual responses before advancing a dependent branch. Keep time according to the agreed pace, allow necessary clarifications and record who chose what with the information then available. If you cannot join the meeting directly, give the facilitator the ready-to-use materials and accept the real decisions through a shared record or relay; do not invent attendance or responses. For asynchronous play, prepare the SCENARIO-labeled messages, intended recipients, schedule or release triggers and return channel. Show the organizer the delivery plan and obtain authorization before sending or scheduling communications. Existing authorization for the exact plan is sufficient; do not ask again for each routine release. Check actual send/schedule confirmations and incoming responses where supported. Release decision-dependent developments only after the relevant reply or a previously agreed timeout rule. Maintain a single current game state so delayed or out-of-order replies do not create contradictory events. If you cannot send, schedule or monitor messages, provide the organizer with the complete delivery queue and collect replies through an available route. Be clear that it requires that participation and is not running automatically. For either format, pause for a real-world issue or a participant’s agreed stop signal. Unanswered messages remain missing input, not simulated consent. ### Debrief what people actually did End at the agreed completion condition or time and clearly close the scenario. Reconstruct the event and decision timeline from the actual record, preserving which information each participant had at the time. Distinguish sound judgment under uncertainty from a fortunate result, and a fictional game consequence from evidence about what would happen in reality. Ask participants what surprised them, what helped, what information or authority they lacked and what they would change. Use their responses to examine coordination, communication, escalation and decisions against the agreed purpose. Avoid turning a playful performance into an unsupported assessment of a person’s competence. Produce a concise debrief with effective responses, specific gaps and proposed improvements tied to events. Let the team choose changes and owners; do not assign commitments on their behalf. Save the runnable materials, actual timeline and agreed changes. If the team has not played yet, deliver the prepared package and exact remaining delivery or participation step, explicitly distinguishing readiness from a completed exercise. 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.
View full AI instructions
Simulate a crisis with your team.
What the AI will do
- Investigate the team’s responsibilities and design a crisis exercise in the tone and format you choose.
- Facilitate unfolding events live or asynchronously, record actual decisions and turn the debrief into practical improvements.
What you can provide
- The team and anything you want it to practice; a rough idea is enough.
- Available incident records, plans and working context; participation from the actual team when the exercise runs.
Where you'll take part
- Choose silly or serious, live or asynchronous, and what the team should learn.
- Take part in the scenario, then review what the team’s actual choices reveal.
What you'll get
A completed team exercise with a decision timeline, debrief and agreed improvements—or a ready-to-run package if participation or delivery is still pending.
Activity context
The factory has vanished. Or the supplier really has gone down. A crisis exercise can be gloriously silly or uncomfortably realistic. Let AI build the scenario and keep it moving while your team discovers how it makes decisions together.
For the user
Start with your team and the kind of experience you want. You can play together remotely or in person, or let developments arrive over email or messages during an agreed period. Every fictional communication is clearly marked SCENARIO. The AI does the preparation and facilitation; people make the decisions.
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
Choose the experience with me
Help me run a crisis scenario with my actual team. It can be a playful game, a serious rehearsal or somewhere between. It can take place all at once, remotely or in person, or asynchronously through clearly labeled emails or messages. Ask what tone and format I want rather than assume a grim emergency drill.
Use any context already supplied. Ask focused questions one at a time to establish the team, what we hope to learn, tone, live or asynchronous format, available time and intended participants. A silly scenario can expose real coordination patterns; a serious scenario can rehearse a specific concern. Offer a couple of concrete premises if they help me choose. Wait for choices that determine the design, while doing independent source investigation.
Ground the exercise in how this team works
Inspect available connections and search incident reports, response plans, escalation messages, project handoffs, relevant emails and chats, calendar invitations, team responsibilities and meeting transcripts. Use team, project and incident names to establish dependencies, who has information, who can decide and where earlier coordination worked or broke down. Establish roles and expressed concerns from records or participants, not inferred personality labels.
Check the existing communication and meeting tools. For asynchronous play, investigate what you can actually schedule, send and receive. For live play, establish how participants see updates and return decisions. Try relevant access before requesting a user-only setup action. If records are unavailable, use a short interview and examples to design an explicitly invented exercise; do not call it a reconstruction of actual incidents.
Agree the scope, participants, duration, channels, fictional premise and learning purpose. Define any limits on content or interruptions that matter for this team. Keep preparation proportionate: a short playful session does not need a company-wide investigation.
Build the scenario and its separate views
Write a runnable exercise with an opening situation, participant roles, initial information, a sequence of timed or decision-triggered developments, plausible branching consequences and a clear end. Use the team’s real dependencies where appropriate, while separating factual background from invented events. Make it possible for reasonable people to disagree and for more than one response to work. Do not rig every choice to prove the facilitator’s preferred lesson.
Prepare a facilitator-only event plan containing hidden developments, release conditions, likely branches, time limits and debrief prompts. Prepare separate participant briefs containing only what each role would know at that point. Store and distribute them through genuinely separate access paths where the tools support it; a heading marked private inside a shared document does not keep a reveal hidden. If you cannot control access, give the confidential plan only to the facilitator and keep it out of shared materials.
Label every fictional message, email subject, document, dashboard or injected update prominently SCENARIO. Explain the exercise framing to participants before it begins, including asynchronous players who may join later. Fictional requests must never trigger real payments, emergency calls, customer notices or production changes. The team records what it would do within the exercise.
For a larger exercise, assign bounded preparation or supporting-role tasks to agents with explicit source material, allowed knowledge, return format and completion conditions. Preserve hidden information boundaries. Let a separate reviewer inspect the actual participant materials and event logic for confusing instructions, accidental reveals and impossible choices, then repair them. Without separate agents, perform distinct preparation and checking passes.
Run it live or asynchronously
For a live remote or in-person session, provide the opening brief and facilitate one development at a time. Ask participants for their decisions, reasoning, information requests and intended communications. Wait for their actual responses before advancing a dependent branch. Keep time according to the agreed pace, allow necessary clarifications and record who chose what with the information then available. If you cannot join the meeting directly, give the facilitator the ready-to-use materials and accept the real decisions through a shared record or relay; do not invent attendance or responses.
For asynchronous play, prepare the SCENARIO-labeled messages, intended recipients, schedule or release triggers and return channel. Show the organizer the delivery plan and obtain authorization before sending or scheduling communications. Existing authorization for the exact plan is sufficient; do not ask again for each routine release. Check actual send/schedule confirmations and incoming responses where supported. Release decision-dependent developments only after the relevant reply or a previously agreed timeout rule. Maintain a single current game state so delayed or out-of-order replies do not create contradictory events.
If you cannot send, schedule or monitor messages, provide the organizer with the complete delivery queue and collect replies through an available route. Be clear that it requires that participation and is not running automatically. For either format, pause for a real-world issue or a participant’s agreed stop signal. Unanswered messages remain missing input, not simulated consent.
Debrief what people actually did
End at the agreed completion condition or time and clearly close the scenario. Reconstruct the event and decision timeline from the actual record, preserving which information each participant had at the time. Distinguish sound judgment under uncertainty from a fortunate result, and a fictional game consequence from evidence about what would happen in reality.
Ask participants what surprised them, what helped, what information or authority they lacked and what they would change. Use their responses to examine coordination, communication, escalation and decisions against the agreed purpose. Avoid turning a playful performance into an unsupported assessment of a person’s competence.
Produce a concise debrief with effective responses, specific gaps and proposed improvements tied to events. Let the team choose changes and owners; do not assign commitments on their behalf. Save the runnable materials, actual timeline and agreed changes. If the team has not played yet, deliver the prepared package and exact remaining delivery or participation step, explicitly distinguishing readiness from a completed exercise.
Done when
A completed team exercise with a decision timeline, debrief and agreed improvements—or a ready-to-run package if participation or delivery is still pending.
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.
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.