用途：voiceover 把“配音脚本”当作规格，取代传统 PRD。一个功能先以“假如已上线，用户会怎么录制演示旁白”的形式写出来，脚本获批前不写任何代码。
主要能力与流程： 第一阶段——对齐文字（不写代码）。用一句话描述功能，只追问为演示配音所需的信息；端到端写出配音脚本，每个画面一段编号文字，多数功能 4–8 段，口语化、现在时、以最终用户为主角，描述观众看到什么及其意义，不写实现细节。若某段难以配音，说明功能或该段有问题，需重塑。反复改文字而非代码，直到用户真的愿意照着录。 第二阶段——干净起步并编码演示。获批后建立隔离工作区，保持用户检出不受影响： git fetch origin dev git worktree add ../_worktrees/openwork-<slug> -b feat/<slug> origin/dev 然后在 worktree 内把获批旁白直接翻译成规格：创建 evals/specs/<slug>.slow.test.ts，从 @openwork/testkit 导入 test，把每段编码为用户操作、可观察断言与证据声明；不另建旁白文件。证据是环境自动采集的，无需创建、传入或管理 roll handle。 第三阶段——构建到演示成立。由 orchestrator 拆解工作并委派 executor 子代理编码，遵循 write-a-spec → run-tests，规格失败时加载 diagnose-a-red-run，修复到每条获批声明都有可观察断言。 第四阶段——交付带证据的 PR： git push -u origin feat/<slug> gh pr create --base dev --fill 随后加载 publish-evidence。pnpm fraimz:publish 仍是发布已完成 testkit 证据带的兼容命令，它不运行测试。自定义截图或视频可补充证据带，但不能替代其判定证据。
脚本格式：标题为“# <功能> — <一句话声明>”，可选非旁白上下文，随后每段编号旁白一到两句，能让人对着屏幕念出并正好对应那个状态。获批的对话直接翻译成规格，不写入单独文件。
适用场景：希望以演示优先、先对齐用户可见效果再开发的团队与个人。
限制：资料未提供具体安装方式、收费、价格、平台支持与效果数据；依赖 @openwork/testkit、gh、git worktree 等环境。