Inside the script: site variables, setup section, prompts, presenter text, reset, and the global config that keeps personal URLs out of the shared repo.
Takeaway 01
Variables and sections give the file a clean shape — readable as a script.
Takeaway 02
Plain text in the file becomes the on-screen narration for the presenter.
Takeaway 03
A separate global config holds your personal URLs so the demo file stays generic.
Site Variables at the Top
Every demo file starts by declaring the site and library it targets. These are variables, not hard-coded values, so a teammate can clone the demo and point it at their own tenant without editing the script.
Variables make demos portable. Without them, every demo file would carry one author's tenant URL and break for everyone else.
Three Sections: Setup, Demo, Reset
The body of the file is divided into named sections — setup, demo, and (optionally) reset. The runner uses these to map the four run modes onto blocks of the file. Setup-only runs just the setup section; demo-only runs just the demo section; both runs them in sequence.
[setup]
navigate to site
open chat
start new chat
create document library "Contracts"
upload files from assets/contracts
confirm pane is fresh
pause "Setup complete — ready to demo"
[demo]
prompt "List every change. Tell which favor us, which favor the vendor."
wait for response
pause "Talk through the comparison"
...
[reset]
# read-only demo — nothing to reset
Reset is optional. If your demo is read-only (like the comparison demo), you write an empty reset section. The runner respects that.
Actions and Prompts
Actions go inside square brackets in the original syntax. They are the verbs the runner understands: navigate, open chat, upload, prompt, wait for, pause. Prompts are passed to AI in SharePoint as if you typed them into Copilot.
Prompts are the only AI-touching action. Everything else is browser orchestration. That keeps the runner's surface area small.
A prompt is not pre-baked into the script's response. The runner sends the prompt live and waits for the real AI response. The demo is real every time.
Presenter Text Is Just Plain Text
Any line in the demo file that is not an action becomes presenter text — the narration the runner displays on screen at that point. "Legal just sent over a revised MSA. You can open them side by side or let AI do the comparison" is one such line.
The script doubles as the talk track. The author writes the lines he plans to say in the file itself, and the runner shows them at the right moment.
This is also what feeds the AI-generated demo video pipeline (Video 07). The same presenter text becomes the narration script that ElevenLabs reads.
Waiting for AI Completion
AI responses are multi-turn and streaming. The runner does not advance the moment a prompt is sent — it waits for the AI command to actually finish before unlocking the next step. The presenter sees the streaming output in real time; the runner watches for completion.
The wait condition is "command done," not "first response chunk." That prevents the runner from stepping over the AI mid-thought.
The runner scrolls automatically to the bottom of the response when it is complete, so the presenter sees the end of the AI's answer without manually scrolling.
Global Config — Personal URLs Out of the Repo
Demo files live in a shared GitHub repo. To keep one user's tenant URL out of every demo, the runner reads a separate global config that overrides variables at runtime. You set your personal site URL once in the config; the demo files stay generic.
Config separation makes the demo repo a true shared asset. Forks do not have to fix URLs — they just edit one config file locally.
The config also allows per-demo overrides. If your "brand reviews" demo needs to point at a specific site, you can override just that demo's site variable without touching the script.
Flashcards — Guide 02
02 · Applied
Site Variable
tap to reveal →
A named placeholder for the SharePoint site URL declared at the top of a demo file. Makes demos portable across tenants without editing the script body.
← tap to flip back
02 · Applied
Demo File Sections
tap to reveal →
The setup, demo, and reset blocks inside a demo file. The runner maps these onto its four run modes so each mode executes a defined slice of the script.
← tap to flip back
02 · Applied
Action
tap to reveal →
A verb the runner understands — navigate, open chat, upload, prompt, wait for, pause. Actions drive browser and AI behavior; non-action lines become narration.
← tap to flip back
02 · Applied
Presenter Text
tap to reveal →
Plain text lines in the demo file that the runner displays on screen at the corresponding step. Doubles as the talk track and the TTS narration script.
← tap to flip back
02 · Applied
Wait For Completion
tap to reveal →
A pause that waits for an AI command to fully finish — not the first streaming chunk. Prevents the runner from advancing mid-response.
← tap to flip back
02 · Applied
Global Config
tap to reveal →
A separate file that holds the user's personal tenant URLs and per-demo overrides. Keeps demo scripts generic and committable to a shared repo.
← tap to flip back
02 · Applied
Typing Speed Config
tap to reveal →
A configurable rate that controls how fast the runner types prompts into chat. Tunable so the demo can look human or run quickly during practice.