Pick a depth. Each prompt opens in your AI pre-loaded with the lesson. Click a row to preview the prompt.
A short screen capture communicates more than a page of architecture description, and it is the only artifact that survives a reviewer who has fifteen repositories to get through. Ninety seconds is the constraint that makes it good: it forces you to show the behaviour rather than the codebase. The strongest demos show something breaking and recovering, because that is the part a reader cannot infer from your README — a provider going down and traffic rerouting, a pull request failing CI, a red-team finding being filed and then closed on the next run.
Script it before recording. The structure below fits in ninety seconds and puts the interesting part in the middle where attention is highest.
# demo_script.md
0:00-0:10 The claim, on screen as text. "Traffic keeps flowing when a
provider fails." No talking head, no logo animation.
0:10-0:30 Healthy state. Dashboard: three providers, steady p95,
breakers closed. Establish what normal looks like.
0:30-0:55 Break it. Hit the chaos endpoint, inject 100% errors into
provider A. Show the error rate climb, the breaker trip,
traffic shift to provider B. THIS is the demo.
0:55-1:15 Recovery. Chaos off. Half-open probe succeeds, breaker closes,
traffic returns. Point at the circuit-state timeline panel.
1:15-1:30 The number, on screen. "99.2% availability across 40 minutes
of induced provider failure." End.
# Record at 1080p, no audio commentary needed (captions are enough,
# and reviewers often watch muted). Put the mp4 in the repo AND
# embed it at the top of the README.python3 main.py