microsoft/ai-demo-assistant
| Builds a scenario-driven content pack for a Microsoft 365 Copilot customer demo. From a customer name, line of business, and target personas, it proposes demo scenarios for operator approval, then generates fictional Word/PowerPoint/Excel example files plus an AI Demo Delivery Plan (persona roster with tenant-account mapping, email and Teams chat scripts, calendar meetings with agendas, a meeting transcript, and app-tagged Copilot prompt workflows grounded in the generated content). After approval it can OPTIONALLY seed the Office files into a customer-named OneDrive folder and optionally post the Teams chat scripts live; email, calendar, and recordings are drafted for manual loading. Use when the user asks to "set up a Copilot demo", "build demo content for a customer", "seed a demo tenant", "create a demo delivery plan", "fill a demo tenant with realistic content", or "generate demo scenarios and sample files". Do NOT use for sending real email, booking real calendar events, or production-tenant data.
npx skills add https://github.com/microsoft/cat-agent-skills --skill ai-demo-assistantTurns a customer name + line of business + target personas into a polished,
scenario-driven content pack for a Microsoft 365 Copilot demo: example
files plus a written delivery/provisioning plan. After operator approval, it can
**optionally seed the generated Office files into a customer-named OneDrive
folder and optionally post the Teams chat scripts live** — both gated on
explicit confirmation. Everything else (email threads, calendar invites, meeting
transcripts) is drafted for a human to load.
| Asset | Auto-seed? | How |
|-------|-----------|-----|
| Word / PowerPoint / Excel files | Yes | Create a customer-named OneDrive folder and upload the files (Phase 3). |
| Teams chat messages | Optional, with constraints | Posts live via Graph; see Phase 4 caveats (timestamped now; one account posts only as itself). |
| Email threads | No | Drafted as scripts for manual paste/seed. Do not auto-send. |
| Calendar meetings | No | Drafted as scripts with agendas for manual creation. Do not auto-book. |
| Meeting recordings / transcripts | No — not possible via any API | Generate a transcript/script; to get a real recording, a person reads it aloud in a recorded Teams meeting. See Phase 4. |
The hard limits exist because Graph has no endpoint to backdate messages or to
inject a recording/transcript — those are produced only by a live recorded
meeting. Never claim a recording was seeded.
tenant**. This skill targets demo tenants and the operator's own OneDrive with
fictional content only.
framing — use the docx/pptx/xlsx skills directly.
| Input | Required | Example |
|-------|----------|---------|
| Customer name | Yes | "Contoso Manufacturing" |
| Line of business (LOB) | Yes | "Field Service Operations" |
| Target personas / roles | Yes | "Service Dispatcher, Field Tech, Ops Director" |
| Segment / size | Optional (default: Enterprise) | "SMB", "Public Sector" |
| Region / language / tone | Optional (default: US English, professional) | "UK English, formal" |
| # of scenarios | Optional (default: propose 3–5) | "4" |
| Demo tenant domain | Optional (default: placeholder {tenant-domain}) | "M365x84272.onmicrosoft.com" |
| OneDrive seeding target | Optional (default: operator's own OneDrive) | "seed to my OneDrive" / a specific account |
| Teams seeding | Optional (default: scripts only, no live post) | "post the chats too" |
If customer, LOB, or personas are missing, ask one concise question to fill
the gaps. Do not over-interview — reasonable defaults cover everything else.
Seeding target and Teams seeding are only needed at Phase 3/4; don't block the
build on them.
scenarios** that map to a day-in-the-life of the named personas. Each scenario
should show Copilot saving time across Outlook, Teams, and Office.
title, the persona it serves, and the Copilot "wow moment" it demonstrates.
building anything. Do not generate files until scenarios are confirmed.
(or explicitly said "just build it") in the initial request, treat that as
approval — restate the scenario set in one line and proceed to Phase 2. The
gate exists to prevent wasted builds, not to force a redundant round trip.
For the approved scenario set, generate every asset below. Use the customer name,
LOB, and personas throughout so content feels native. Save all deliverables to
the standard output directory for the current environment (the designated
output/ folder).
**Before generating any Office file, read the relevant skill's SKILL.md
(docx / pptx / xlsx) and follow it** — these skills encode the validation and
rendering steps that keep files from arriving corrupted or ugly.
Persona roster (build first — everything else references it).
Create a small cast of fictional characters: name, title, which scenarios they
appear in, and a mapping column for the demo tenant account the operator will
use to seed as them (use real demo-tenant aliases if the operator provided a
tenant domain, otherwise {firstname}@{tenant-domain} placeholders the operator
can find-and-replace). Reuse this exact cast — same spellings, same titles —
across every email thread, chat script, meeting invite, and document byline.
Inconsistent names across artifacts are the fastest way to make a demo feel
fake and to confuse the person seeding the tenant.
File naming and cross-reference consistency.
Name every generated file with the pattern S<NN>_<ScenarioShortName>_<DocType>.<ext>
(e.g., S01_EscalationTriage_ServiceReport.docx). Any filename mentioned in an
email script, chat script, agenda, pre-read list, or the manifest must exactly
match a generated file — a plan that references files that don't exist (or are
named differently) breaks the operator's seeding run.
A. Office example files (dummy data, clearly fictional)
Name each file per the convention above and give it real, specific content so
the manifest descriptions (item 9) and the prompt workflows (item 8) have
something concrete to point at:
S01_EscalationTriage_ServiceReport.docx — a field service report with named
sections such as Incident Summary, Root-Cause Analysis, Parts Replaced,
Customer Impact, Recommended Follow-up). Target 2–4 pages — enough substance
for Copilot to summarize impressively, no more.
S02_QBR_Deck.pptx — aQBR with an SLA scorecard, a ticket-volume trend slide, a cost summary, and a
roadmap). Target 8–12 slides, each with a clear, descriptive title.
columns** (e.g., S01_EscalationTriage_TicketLog.xlsx — a "Tickets" sheet with
TicketID, OpenedDate, Site, Priority, Status, AssignedTech, AgeDays, Resolution
columns). Target 30–80 rows — enough for Copilot to find real patterns, small
enough to stay readable.
hand-calculate numbers in a file.
These size targets exist because example files only need to be rich enough to
make the live prompts land; oversized assets slow the build and add nothing to
the demo.
B. AI Demo Delivery Plan
Default to a single Word doc (it's the operator- and customer-facing artifact);
use markdown only if the operator asks for a lighter/faster format. Contains the
provisioning recipe a human loads into the demo tenant:
described above.
(from the roster), and full body text for a realistic 2–4 message thread,
ready to paste/seed. Threads should carry real substance — context, a
decision or two, and an open question — so that "summarize this thread"
produces a genuinely impressive answer. Reference the generated files as
attachments/pre-reads by exact filename.
scenario, using roster names. Keep each line attributed to a roster persona so
the optional live-post step (Phase 4) knows who would send what.
channel per scenario with its purpose, so the operator builds it once and
reuses across demos.
relative date/time placeholders, an agenda, and pre-read links pointing to
the generated files by exact filename.
operator asks), a realistic meeting transcript in speaker-attributed form
(Name: line), 12–25 turns, covering context, a decision, and an action item
so that "summarize the meeting and list action items" lands. This is the
substitute for a recording — see Phase 4 for how it becomes a real recording.
exact Copilot prompts the presenter runs, written so each step builds on the
one before it into a day-in-the-life narrative (typically *catch up → analyze →
draft → polish → share*). Present each workflow as a numbered sequence, and
tag every prompt with the specific Copilot app it runs in so the presenter
knows exactly where to click. Use these canonical app names:
Copilot app, Teams/Edge side panel, or m365.cloud.microsoft); best for
cross-app "catch me up across everything" prompts.
meetings** for live/after-meeting recap and action items.
Word file.
Write every prompt with the CRAFT framework so each one is a complete,
copy-paste-ready Copilot prompt instead of a vague ask:
on Demo Day −2…").
analyst…").
risks…").
table", "an email under 150 words").
also sets the tone.
**Name the grounding file(s) inline in the prompt whenever it sharpens the
result** — e.g. *"In S01_EscalationTriage_TicketLog.xlsx, which open
tickets…"* — in addition to the separate → grounds on: note. Naming the file
inside the prompt is what makes file-scoped prompts (Copilot in
Excel/Word/PowerPoint) reliably attach to the right artifact live on stage.
Format each step as App — "exact prompt" with a → grounds on: note naming
the artifact(s) it draws from. Example workflow:
Scenario 1 — Escalation triage (persona: Service Dispatcher)
1. Microsoft 365 Copilot Chat — "Ahead of my morning triage, act as my operations
assistant and catch me up on everything about the Northwind escalation from the
last week. Give me a short bulleted brief — what happened, current status, and
what needs my decision — in a concise, professional tone for a dispatcher."
→ grounds on: S01_EscalationTriage_EmailThread, S01_EscalationTriage_TeamsChat,
S01_EscalationTriage_StandupTranscript
2. Copilot in Outlook — "Act as a customer-facing service manager. Summarize the
Northwind escalation email thread, then draft a reply proposing the Tuesday
repair window, as a ready-to-send email under 150 words in a reassuring,
professional tone for the customer."
→ grounds on: S01_EscalationTriage_EmailThread
3. Copilot in Excel — "In S01_EscalationTriage_TicketLog.xlsx, act as a data
analyst: find the open tickets tied to the Northwind site and calculate their
average age in days. Present it as a small table sorted oldest-first, for the
Ops Director."
→ grounds on: S01_EscalationTriage_TicketLog.xlsx
4. Copilot in Word — "Using S01_EscalationTriage_ServiceReport.docx, act as a
technical writer and turn this field service report into a 5-bullet executive
summary in a crisp, outcome-focused tone for the Ops Director."
→ grounds on: S01_EscalationTriage_ServiceReport.docx
5. Copilot in Teams — "Act as a meeting scribe. Recap the escalation stand-up and
list the action items as a table with owner and due-date columns, in a clear,
neutral tone for the team."
→ grounds on: S01_EscalationTriage_StandupTranscript
Every prompt must be answerable from content that exists in this pack —
before finalizing, walk each step back to the specific thread, chat, meeting,
transcript, or file it draws on (note it inline as shown above) and strengthen
the content if the answer would be thin. A prompt with nothing behind it is a
live-demo failure waiting to happen.
exact file name, a detailed description of the file's contents, which
scenario / prompt-workflow step it supports, and where it gets seeded
(which mailbox, channel, calendar, or OneDrive/SharePoint location). The
description must be specific enough that the operator knows exactly what each
file holds without opening it — name the Word section headings and page
count, the PowerPoint slide titles, and the Excel sheet/tab names with
their column headers and row count. One-line "a budget spreadsheet"
descriptions are not enough. Example rows:
| File name | Contents (detailed) | Supports | Seed to |
|-----------|---------------------|----------|---------|
| S01_EscalationTriage_ServiceReport.docx | 3-page field service report. Sections: Incident Summary, Root-Cause Analysis, Parts Replaced, Customer Impact, Recommended Follow-up. ~20 fictional part/labor line items. | Scenario 1, prompt 4 | Dispatcher OneDrive → "Copilot Demo - Northwind" |
| S01_EscalationTriage_TicketLog.xlsx | Single sheet "Tickets" (62 rows). Columns: TicketID, OpenedDate, Site, Priority, Status, AssignedTech, AgeDays, Resolution. Mix of open/closed across 4 sites. | Scenario 1, prompt 3 | Dispatcher OneDrive folder |
| S02_QBR_Deck.pptx | 10-slide QBR deck. Slides: Title, Agenda, SLA Scorecard, Ticket-Volume Trend, Top 5 Escalations, Cost Summary, Roadmap, Risks, Asks, Next Steps. | Scenario 2, prompts 1–2 | Ops Director OneDrive folder |
For files seeded in Phase 3, include the live OneDrive folder path/link once
created. This table is the operator's load checklist.
10. Seeding timing note — instruct the operator to load content **24–72
hours before the demo**. Copilot answers from the Microsoft Graph semantic
index, and freshly seeded content often isn't surfaced for hours; seeding
minutes before going on stage is the most common cause of dead demos. This
applies to OneDrive-seeded files too — seed them on the same schedule.
11. Appendix — Sample file contents — close the Delivery Plan with an
appendix that walks through each generated sample file in detail, one
subsection per file. For every file give the exact file name, its type and size
(page / slide / row count), and a structured description of what's inside: for
Word, each section heading and what it covers; for PowerPoint, every
slide title and the key point on it; for Excel, each sheet/tab name with its
column headers and what the rows represent. Call out the two or three "hero"
details in each file that the sample prompts (item 8) rely on, so a presenter
reading only the appendix knows exactly what Copilot will find. This appendix is
the narrative companion to the seeding-checklist table (item 9): the table says
*where each file goes*, the appendix says *what's inside it*.
Date convention: use relative dates anchored to demo day ("Demo Day −5",
"Demo Day −2, 9:00 AM") in all scripts and meetings rather than hard-coded
calendar dates. This keeps the pack evergreen across runs and ensures
recency-based prompts ("summarize my recent emails about the escalation")
actually work when the operator seeds on schedule.
Run this when the operator asks to seed/upload the files to OneDrive (e.g.,
"seed the files to my OneDrive", "put these in OneDrive"). If they didn't ask,
skip this phase and leave files in output/ for manual loading.
(GetDefaultDrive, no site_id). If they named a different account/drive,
resolve it explicitly — never guess a drive. Confirm the destination in one
line before writing.
prefixed for tidiness: Copilot Demo - {Customer} (sanitize illegal
characters \ / : * ? " < > |). Place it under a stable parent
(Copilot Demos/ at the OneDrive root — create the parent first if missing).
Use CreateFolder. If a same-named folder already exists, reuse it rather
than failing; tell the operator you're reusing it.
output/ into that folder usingthe available OneDrive upload capability. Upload only the demo Office files
and the Delivery Plan — not scratch/working files. If the runtime cannot
upload a given binary file directly, place it into a customer-named subfolder
of the synced workspace output and report that OneDrive-sync location instead;
never silently drop a file.
GetDriveChildren) andconfirm every intended file is present. Give the operator the folder link and
the list of seeded files. Update the manifest's "where it gets seeded" column
with the live OneDrive path.
Folder-per-customer is the rule — one customer-named folder per demo so runs
don't collide and the operator can find/clean up a demo's assets in one place.
Teams chat seeding (optional, on explicit request). Only post live if the
operator says to (e.g., "post the chats too"). Otherwise the chat scripts in
the Delivery Plan are the deliverable. Before posting, state these constraints in
one line so expectations are right:
work; "last Tuesday" framing in the script won't match the real timestamp.
only if each persona's tenant account posts its own lines; from one account,
all lines appear from that one user. Tell the operator which is happening.
PostMessage/PostChannelMessage with resolved recipients. Do notfabricate chat IDs.
Meeting recording — generate a transcript, not a recording. There is **no
API to create or upload a Teams meeting recording or transcript** — they exist
only after a real recorded meeting. So:
seedable artifact (a text/VTT file Copilot-grounded prompts can draw on if the
operator seeds it as a file).
meeting with the persona accounts, turn on recording, read the transcript
aloud, and stop — Teams then produces a real recording + transcript tied to the
event. This is the only path to an actual recording; never imply one was
generated programmatically.
file named in the manifest exists on disk, and that no script or agenda
references a file that wasn't generated. If Phase 3 ran, also verify the
OneDrive folder contains the seeded files.
where the Delivery Plan lives, and — if seeded — the OneDrive folder link and
what was posted to Teams. Note that content is fictional dummy data, that
email/calendar/recordings are drafted for manual loading, and the seeding
timing window (24–72h before demo).
(a) creating a OneDrive folder and uploading the generated files (Phase 3), and
(b) optionally posting Teams chat messages (Phase 4) — both only when the
operator asks, and only with fictional content. **Never auto-send email, never
auto-book calendar events, and never write to a production tenant.** If asked
to do those, output the script and explain the operator loads it.
OneDrive/account in one line before creating folders or uploading. Never guess
a drive or post to an unconfirmed chat/channel.
that a meeting recording/transcript was seeded — neither is possible.
Never use the operator's real colleagues, real customer PII, or real internal
figures. Use the demo tenant domain (or {tenant-domain} placeholder) for all
fictional email addresses — never real-looking public domains.
statistics, real people, or real quotes as fact.
scenario list before building files (Phase 1 → Phase 2), unless pre-approved
per the Phase 1 exception.
every live prompt traceable to seeded content. Consistency is what makes the
demo feel real.
folder so runs don't collide.
target as variables so the same flow works for any segment and LOB.
Take microsoft/ai-demo-assistant from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.