Demo Scenario Builder

demo-scenario-builder produces a tailored demo package in chat. It reuses prior account context first and only calls out for research to fill missing terminology or workflow clues.

What this skill is

A conversational demo-prep workflow. You hand it an account, a product, a persona, and success criteria, and it returns:

• A short summary.
• A demo narrative.
• A talk track.
• Likely objections with responses.
• Deterministic seed data.
• A fallback plan for when the live environment fails.
• Citations, or assumptions when grounding was incomplete.

It can call Firecrawl search, scrape, and interact for vocabulary and workflow clues, and it can push the result to Google Docs, Google Sheets, or a GitHub issue when you explicitly ask for writeback.

Trigger conditions

Use this skill when the user asks for:

• A tailored demo.
• A demo script.
• Objection handling.
• Seeded demo data.
• A fallback plan for a customer walkthrough.

Intake order

Codex asks one question at a time, in this order:

1. Account or prior brief.
2. notes.product — what you are demoing.
3. notes.persona — who you are demoing to.
4. notes.successCriteria — what “a good demo” means here.

Output shape

The artifact is returned in chat with these sections:

1. Summary
2. Demo narrative
3. Talk track
4. Likely objections
5. Seed data
6. Fallback plan
7. Citations or assumptions

How to best use this skill

Run an Account Intel Brief first. The demo builder explicitly reuses prior account context before doing new research. If a brief is already in chat, the demo will pick it up automatically and skip redundant intake.

Be specific about persona. “VP of RevOps”, “platform engineer at a Series B SaaS”, “head of integrations at a retailer” all produce meaningfully different demos. “A technical buyer” is too vague.

Define success criteria up front. Success criteria shape the narrative and the talk track. “They say yes to a POC by end of call” produces a very different package than “They sign off on a security review path”.

Expect deterministic seed data. Seed data is derived from the inputs you provide, not from a random generator. If you run the skill twice with the same inputs, you get the same seed rows — which is useful for rehearsal and for sharing with teammates.

Read the fallback plan before you go live. The fallback is not a nice-to-have. It is what you switch to when the live environment fails mid demo. Rehearse it.

Save and writeback are opt-in. By default the package is returned in chat. You can ask Codex to save the markdown, create a Google Sheet for the seed data, or open a GitHub issue to track demo prep — each requires confirmation and a connected Composio toolkit.

How to combine with other skills

• With Account Intel Brief. Run the brief first. The demo reuses its company snapshot, stack signals, and initiatives so you are not paying for the same research twice.
• With Integration Fit Gap Analyzer. If the account is likely to push on a specific integration during the demo, run the fit-gap first and reference it. The demo builder will thread the fit-gap’s answers into the “Likely objections” section.
• With POC Handoff Orchestrator. The demo’s narrative, objections, and seed data are all signal for the POC plan. Keep the demo artifact in the same chat or reference it via artifactRefs when running the handoff.

Example invocations

Explicit:

$demo-scenario-builder outtake.ai

Natural language:

Build a demo scenario for Outtake.ai selling Solutioneer to a RevOps lead. Success is signoff on a POC by end of the call.

Example normalized input (for reference):

{
  "account": { "name": "Acme Health" },
  "objective": "Build a tailored demo package",
  "notes": {
    "targetPersona": "solutions architect",
    "useCase": "customer-specific technical discovery demo",
    "sellerNotes": ["Show a fallback path if the live environment fails"]
  },
  "artifactRefs": [],
  "destinations": {},
  "providerMode": "auto"
}

Provider behavior

• With FIRECRAWL_API_KEY — Firecrawl fills missing terminology and workflow clues via search, scrape, and interact.
• Without FIRECRAWL_API_KEY — the package stays assumption-based. Codex will say so.
• External writeback — requires COMPOSIO_API_KEY and a connected toolkit. Supported toolkits: googlesuper (Docs and Sheets) and github (issue creation). See Connect Google Docs & Sheets and Connect GitHub.