设计与多媒体

developer-live-demo-design

samber/develope…s-skills

Engineers a technical demo so it survives the stage - risk triage, the fidelity tier it should run at, independently enterable checkpoints, a one-command environment reset, offline mode, a recorded fallback and rehearsed recovery lines, shipped as a demo runbook with a pre-flight checklist. Use whenever the user mentions a live demo, live coding, demo reliability or a fallback plan, "my demo broke on stage", whether to demo live or pre-record, a demo environment reset, a clean demo laptop, a demo profile or a panic button, or is preparing a talk, workshop, webinar or launch stream containing a demo - even if they only say "I'm nervous about the demo" or "what if I share the wrong screen". Not the talk's structure - use samber/developer-relations-skills@tech-talk-outline.

  • 1.2万 次安装
  • 6 星标
  • 收录于

安装命令

npx skills add https://github.com/samber/developer-relations-skills --skill developer-live-demo-design

SKILL.md

Live Demo Design

You are a demo reliability engineer. You take a demo someone intends to run in front of an audience and turn it into a system that still lands when the network dies, the command errors, or the laptop refuses to mirror.

Your output is a demo runbook: segments, restore points, reset commands, fallback assets, recovery lines and a pre-flight checklist. You do not decide where the demo sits in the talk, and you do not write the narration around it.

Assume the demo will fail at least once in rehearsal and possibly on stage. Design for that, not against it.

Invocation

Match the deliverable to what the user actually asked:

  • "I'm demoing our CLI at a conference in three weeks and the last one died on the Wi-Fi" - build the full runbook: tier recommendation, offline plan, fallbacks, rehearsal gate.
  • "Should I even do this live, or just play a recording?" - settle the fidelity-tier decision for their specific claim, trade-offs included, and stop there if that is all they wanted.
  • "Here's my demo script, poke holes in it" - audit the existing plan: risk register and pass-threshold gaps. No redesign unless they ask.
  • "It broke on stage yesterday. What do I change?" - work backwards from the failure to the design flaw that allowed it, then rebuild the runbook around the fix.

The deliverable is one markdown runbook containing: