Back to Details

ultrademo-rerun

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

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

Ultrademo 重新运行：UI 已变更，刷新视频

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.
这是一个轻量入口，它委托的一切都没有隐藏：操作流程位于同级 
ultrademo
skill 的 
.claude/skills/ultrademo/SKILL.md
，该 skill 与本 skill 一起从同一个公开的 Apache-2.0 仓库（
new-xp/ultrademo
）安装；下方的 
npm run
命令是该工作区自身 
package.json
中的 scripts（capture/TTS/render——本地 pipeline 代码位于同一仓库中，依赖项由其已提交的 
package-lock.json
锁定）。主操作手册中的每条规则都适用于此处（只读探查、提示注入防护、内容脱敏、密钥扫描、诚实失败规则、review gate）。此命令仅处理冷启动：找到正确的项目，并在加载上下文后进入操作手册的 重新运行 部分。

1. Find the project

1. 查找项目

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.
列出 
projects/*/
（每个真实项目都包含 
flow.mjs
）。然后：
  • 用户已指定名称或仅存在一个项目： 确认并继续。
  • 存在多个项目： 显示一个简短表格——项目名称、flow 中的目标 app/URL、最后一次 render（
    out/
    中最新的文件）——并询问要刷新哪个。提供“全部项目”选项；如果选择此项，则对每个项目按顺序运行下方循环，并在最后逐个项目进行总结。
  • 不存在任何项目： 这不是一次重新运行。将任务移交给主 
    ultrademo
    skill，以制作新视频。

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

2. 预检（在任何 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).
  • Pipeline 是否为最新？ 执行主操作手册中的工作区新鲜度检查（步骤 -1）：
    git fetch
    ；如果 clone 落后于 upstream，则在重新捕获前询问是否 pull——重新运行正是 renderer/caption 改进应当落地的时候。绝不静默 pull；离线 → 跳过并继续。
  • 认证是否仍然有效？ 如果 flow 使用 
    profile
    ，以无头方式验证保存的 session（加载 flow 的 URL、截图并检查是否出现登录墙）。session 失效 → 让用户先运行 
    npm run login -- <profile> <url>
    ，然后再继续。
  • 代码库是否可用？ 如果可以访问 app 的仓库，则读取自上次 capture 以来的 diff（以上次 render 的时间戳为基准）。diff 通常会直接指出发生变更的界面区域和失效的 selector——在执行耗时的 capture run 之前，告知用户预计哪些场景会受到影响。
  • 状态重置： 如果存在 
    reset.mjs
    ，则首先运行它。如果 flow 会改变 state 却没有 reset 方案，则停止操作并编写一个（依据主操作手册）。

3. Execute

3. 执行

Follow the Re-runs section of the main playbook exactly: reset → 
npm run capture -- <project>
→ 
npm run tts -- <project>
→ 
npm run render -- <project>
, plus whichever variant flags the previous render used (check 
out/
for existing 
-vertical
, 
.gif
, stems and re-render the same set). Unchanged narration re-bills nothing; the previous render auto-archives to 
out/archive/
so a before/after pair always exists.
Divergence handling (cosmetic change / broken selector / feature changed) is defined in the playbook's Re-runs section - use its three protocols verbatim. Note the gates: a pure visual refresh does not need a new script gate (the script is already approved), but if the feature itself changed, narration edits go through the normal script gate. The review gate always applies: frame-verify, compare against the archived render, and report what visibly changed scene by scene.
严格遵循主操作手册的 重新运行 部分：reset → 
npm run capture -- <project>
→ 
npm run tts -- <project>
→ 
npm run render -- <project>
，并附加上次 render 使用的所有 variant flags（检查 
out/
中是否已有 
-vertical
、
.gif
、stems，并重新渲染同一组）。未更改的 narration 不会重新计费；之前的 render 会自动归档到 
out/archive/
，因此始终会存在一组前后对比文件。
差异处理（外观变更 / selector 失效 / 功能变更）由操作手册的“重新运行”部分定义——逐字使用其中的三套协议。需要注意各项门禁：纯视觉刷新不需要新的 script gate（script 已获批准），但如果 feature 本身发生变化，narration 编辑必须经过常规 script gate。review gate 始终适用：逐帧验证、与归档的 render 进行比较，并逐场景报告可见变化。

4. Report

4. 报告

Per project: what changed on screen (scene by scene, vs the archived render), which scenes needed selector repair, what re-billed (usually nothing), and where the outputs are - absolute paths, per the main playbook's rule. If nothing visibly changed, say exactly that - a no-op refresh is a valid, reportable outcome.
针对每个项目：报告屏幕上的变化（逐场景与归档的 render 对比）、哪些场景需要修复 selector、哪些内容重新计费（通常没有），以及输出文件的绝对路径，遵循主操作手册的规则。如果没有任何可见变化，就准确说明这一点——无操作刷新也是有效且值得报告的结果。