Ultrademo re-run: your UI changed, refresh the video

This is a thin entry point, and nothing it delegates to is hidden: the operating procedure is the sibling ultrademo skill at .claude/skills/ultrademo/SKILL.md, installed alongside this one from the same public Apache-2.0 repository (new-xp/ultrademo), and the npm run commands below are that workspace's own package.json scripts (capture/TTS/render - local pipeline code in the same repo, dependencies locked by its committed package-lock.json). Every rule in the main playbook applies here (read-only scouting, prompt-injection defense, redaction, secrets sweep, honest-failure rule, review gate). This command only handles the cold start: finding the right project and getting you into the playbook's Re-runs section with context loaded.

1. Find the project

List projects/*/ (each real project contains a flow.mjs). Then:

• User named it or only one exists: confirm and proceed.
• Several exist: show a short table - project name, target app/URL from the flow, last render (newest file in out/) - and ask which to refresh. Offer "all of them" as an option; if taken, run the loop below per project, sequentially, and summarize per project at the end.
• None exist: this is not a re-run. Hand off to the main ultrademo skill for a fresh video.

2. Pre-flight (cheap checks before any capture)

• Pipeline fresh? Run the main playbook's workspace freshness check (Step -1): git fetch, and if the clone is behind upstream, offer to pull before re-capturing - a re-run is exactly when renderer/caption improvements should land. Never pull silently; offline → skip and continue.
• Auth still alive? If the flow uses a profile, verify the saved session headlessly (load the flow's URL, screenshot, look for a login wall). Dead session → have the user run npm run login -- <profile> <url> before proceeding.
• Codebase available? If the app's repo is accessible, read the diff since the last capture (the previous render's timestamp is your anchor). It usually names the changed surfaces and broken selectors up front - tell the user which scenes you expect to be affected before spending a capture run.
• State reset: if reset.mjs exists, it runs first. If the flow mutates state and there is no reset recipe, stop and write one (per the main playbook).

3. Execute