ai-demo-assistant

name	ai-demo-assistant
description	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.
cowork	{"category":"productivity","icon":"Rocket"}

AI Demo Assistant

Turns 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.

What can and can't be auto-seeded

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.

When NOT to Use

• Sending real email, booking real calendar events, or writing to a production tenant. This skill targets demo tenants and the operator's own OneDrive with fictional content only.
• Real customer data or PII. All generated content is fictional dummy data.
• Generic single-file asks ("make a deck", "write an email") with no demo framing — use the docx/pptx/xlsx skills directly.

Inputs (collect before building)

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.

Workflow

Phase 1 — Propose scenarios (confirmation gate)

1. From the LOB + personas, infer 3–5 realistic, high-impact Copilot 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.
2. Present the proposed scenarios as a short numbered list — each with a one-line title, the persona it serves, and the Copilot "wow moment" it demonstrates.
3. Stop and ask the operator to approve, edit, or swap scenarios before building anything. Do not generate files until scenarios are confirmed.
4. Pre-approval exception: if the operator supplied their own scenario list (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.

Phase 2 — Build the content pack (after approval)

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:

• Word: a representative document per scenario where it fits (e.g., 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.
• PowerPoint: a customer-branded-style deck (e.g., S02_QBR_Deck.pptx — a QBR 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.
• Excel: a data workbook with believable dummy rows and named sheets and 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.
• Compute any totals/percentages with a code tool before embedding them; never 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:

1. Persona roster — the fictional cast with the tenant-account mapping table described above.

2. Scenario overview — the approved scenarios and their personas.

3. Email thread scripts — for each scenario: subject, fictional participants (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.

4. Teams chat scripts — short, natural 1:1 and group chat exchanges per 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.

5. Teams structure — a single reusable team name + description, and one channel per scenario with its purpose, so the operator builds it once and reuses across demos.

6. Calendar meetings — per scenario: subject, attendees (from the roster), relative date/time placeholders, an agenda, and pre-read links pointing to the generated files by exact filename.

7. Meeting transcript/script — for the headline scenario (or each, if the 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.

8. Sample prompt workflows — for each scenario, an ordered workflow of the 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:

   • Microsoft 365 Copilot Chat — the standalone, work-grounded chat (the Copilot app, Teams/Edge side panel, or m365.cloud.microsoft); best for cross-app "catch me up across everything" prompts.
   • Copilot in Outlook — summarize a thread, draft a reply, coaching tips.
   • Copilot in Teams — summarize a chat or channel; and Copilot in Teams meetings for live/after-meeting recap and action items.

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.

Phase 3 — Seed files to OneDrive (optional, on request)

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.

1. Confirm the target. Default to the operator's own OneDrive (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.
2. Create the customer folder. Derive a folder name from the customer name, 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.
3. Upload the generated Office files from output/ into that folder using the 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.
4. Verify and report. List the destination folder (GetDriveChildren) and confirm 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.

Phase 4 — Optional Teams chats & meeting recording

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:

• Messages are timestamped now — Graph cannot backdate them. Recency prompts work; "last Tuesday" framing in the script won't match the real timestamp.
• A signed-in account posts only as itself. A multi-persona chat looks real 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.
• Use PostMessage/PostChannelMessage with resolved recipients. Do not fabricate 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:

• Deliver the meeting transcript/script from Phase 2 (item 7) as the seedable artifact (a text/VTT file Copilot-grounded prompts can draw on if the operator seeds it as a file).
• If a genuine recording is required, instruct the operator to start a Teams 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.

Phase 5 — Deliver

1. Run the delivery gate: list the output directory and verify that every 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.
2. Give the operator a short summary: scenarios built, files produced (by name), 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).

Guardrails

• Scoped live seeding only. The only live writes this skill performs are (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.
• Confirm destination before writing. Resolve and restate the target OneDrive/account in one line before creating folders or uploading. Never guess a drive or post to an unconfirmed chat/channel.
• No backdating, no fake recordings. Do not claim messages were backdated or that a meeting recording/transcript was seeded — neither is possible.
• All data is fictional. Use invented names, companies, numbers, and dates. 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.
• No fabricated real facts. Dummy data is fine; do not assert real-world statistics, real people, or real quotes as fact.
• Confirmation gate on scenarios. Always get operator approval of the scenario list before building files (Phase 1 → Phase 2), unless pre-approved per the Phase 1 exception.
• Numeric accuracy. Compute any embedded totals/percentages with a code tool.
• Internal consistency. One persona roster, one filename convention, and every live prompt traceable to seeded content. Consistency is what makes the demo feel real.
• Folder-per-customer. Seed each demo into its own customer-named OneDrive folder so runs don't collide.
• Reusable across runs. Keep customer/LOB/persona/tenant-domain/seeding target as variables so the same flow works for any segment and LOB.