demo-runbook

Demo Runbook

Create a demo package that is demo-first, user-empathy-led, and technically credible. Produce two deliverables every time: a demo script and a single-file HTML runbook.

When to use this skill

Use this skill when asked to create or refresh a demo (often a PoC demo) that:

• Starts with an end-to-end live demo before explaining why, what, and how
• Includes a competitive landscape comparison using April Dunford’s respectful approach framing
• Includes technical architecture details, especially LLM patterns (RAG, evals, observability)
• Produces both a talk track and a navigable runbook page

Example triggering requests:

• “Help me create a PoC demo runbook and script for a live demo.”
• “Make a demo-first talk track, then cover why/what/how and architecture.”
• “Create a single HTML runbook with links, diagrams, and sections for tech stack.”
• “Write a respectful competitive comparison and explain our approach.”

Outputs

Always produce both:

1. Demo script as markdown (talk track + what to click + timings)
2. Single-file HTML runbook (visual-first with custom CSS, navigable sections, Mermaid diagrams (flowchart + sequence), in-app hyperlinks, back-to-home navigation)

HTML runbook must:

• Be single-file HTML (no build step required) with custom CSS styling (cards/callouts/layout), not a plain document.
• Include Mermaid diagrams (at least one flowchart and one sequence diagram).
• Include navigation between sections (hash router is fine) and “Back to Home” affordances.
• Include an app links section with real links or TODO placeholders.

When returning outputs, format as:

• === demo-script.md === then the markdown
• === demo-runbook.html === then the full HTML

Input schema

Accept inputs in either bullet form or JSON. If any field is missing, insert a clear TODO placeholder rather than asking questions.

Minimum inputs to request are not required. Proceed with placeholders.

Core narrative

• poc_name: Name of the PoC
• tagline: One-line value statement
• audience: Who is watching (and expected technical depth)
• segment:
  • organisation: The organisation context (industry, size, geography, constraints)
  • buyer: Who buys / signs (budget owner, success metric, risk posture)
  • end_user: Who uses it day-to-day (workflow, pain, what “better” feels like)
• job_to_be_done: What the user is trying to do
• starting_feelings: How they feel at the start (rushed, uncertain, risk-averse, too many tabs)
• desired_feelings: How the product changes that (confidence, clarity, speed, fewer guesses)
• scenario: The demo scenario in plain English
• success_outcome: What “done” looks like for the user
• business_success_outcome: What success looks like for the business (be specific: $ impact or growth/adoption metric + timeframe)