Pitchcraft｜路演构造术
把真实产品和可靠材料组织成能讲清楚、看得懂、方便修改的路演。默认中文、比赛答辩场景、产品自身的视觉风格。共同优化速度、内容质量、视觉质量和修改成本，不以更多生成次数或更多流程文档代表质量。
一套入口，两个制作阶段
- 图片初稿：使用
rw-consulting-ppt完成结论、证据主体、视觉层级与完整页面生成。每页一张 PNG，图片版 PPTX 每页恰好一张图。 - 可编辑定稿：使用
image-ppt-to-editable将认可的页面恢复为可见的原生文字、适当的原生图形与有意义的独立素材；底图不得重复留字。最终调用当前 Presentations 技能的组装与验证能力。
这两个契约分别作用于不同文件。RW 的“零可编辑文本”只检查图片初稿，不限制后续转换；转换阶段不得借机重新设计认可的初稿。图片版是可直接使用的正式交付，并非必须继续转换。明确提供两种终点：图片 PPT，或图片 PPT 加可编辑 PPT。按用户选择执行；未说明时在首次简短对齐中确认一次，不默认为必须制作两版。用户只要图片、样张或检查时按其范围停止。
本 skill 负责编排、事实和路演表达，复用两个下游技能，不复制整套提示词、抠图脚本或 PPT 组装器。开始相关阶段时，按当前技能目录找到并读取下游 SKILL.md，再加载它要求的相关引用；不要硬编码某次插件版本路径。所需技能或生成能力缺失时，说明缺失项，完成不依赖它的工作，但不能以不同格式冒充最终交付。
进入点与授权
| 当前输入 | 从哪里开始 |
|---|---|
| 仓库、资料或讲稿，尚无成稿 | 核对证据、故事线、图片样张，再完成两阶段 |
| 已有认可的整页 PNG、图片 PPT/PDF | 直接转换，复用原文、素材与风格，不重新生成初稿 |
| 已有文本框和拆好的图片，仍有漏字或残字 | 直接走 image-ppt-to-editable 的既有 PPT 修复；图片对象不重新拆分或合并 |
| 用户只改某页、只试样张或只做检查 | 限定到指定范围，不自动扩成整套重做 |
以用户最新确认的文件、内容与风格为准。进场先清点已有产物和实际完成状态，保留源文件并另存。已有批准、已知时长和已选风格持续有效，不重复询问。
工作节奏
- Standard（默认）：将受众、时长、故事线和样页选择压缩成一次简短对齐；生成 1–2 张代表样页，按 RW 的样张规则等待认可后批量。已明确认可的故事线或样张不再审批一次。
- Emergency：用户明确要求“不要停、一口气完成”时，直接执行其已授权范围，减少外部确认；仍完成内部事实、整页和文件检查。仅说“快”不等于取消用户已要求的样张确认。
- Final：在制作基础上补证据核对、真实计时排练、转场、答辩和 Demo 失败预案。没有实际计时，只能称为预计时间，不能声称排练通过。
不要为了遵循模式替用户增加待办。用户已要求完整可编辑交付时，图片初稿认可即进入转换；只有转换样张存在实质性取舍或用户明确要求再看时才额外等待。
1. 核对内容、产品与视觉来源
仓库输入先读项目 AGENTS.md、HANDOFF.md、TASKS.md，保持只读扫描；读 产品与视觉来源。需要扫描时运行本 skill 的脚本：
bashpython3 <skill-dir>/scripts/scan_product_repo.py <local-path-or-github-url> --out <work-dir>/repo-scan
脚本支持仓库 URL 与 PR URL；默认分支可能不代表产品。用户指定分支、版本或文件优先，脚本计数和颜色频率只作线索。资料型输入不强求仓库，不为做 PPT 新建 Git 项目。
以一份简短记录确定：产品与用户问题、可演示流程、最强证据、确认文案、来源与缺口、认可素材、配色/字体/材质/密度、排除的旧 Demo 内容。区分已演示、已实现、文档声称、计划、假设与历史材料，不把测试通过当真实用户成效。
沿用产品风格或用户认可样页的整页节奏，不只套 Logo 和颜色。真实界面素材用于证明实际流程；示意图不能冒充产品运行证据。使用已提供或已有合法素材，不截图、不上传截图。
2. 建立定时故事线与逐页正文
读 故事线与时间。只补问真正影响结果且无法从材料获得的信息：受众、时长、期望判断和交付范围。仅转换既有 PPT 时无需重新询问路演时长。
把方向卡、正文与逐页 brief 合并维护，避免多份近义文档反复对齐。每页记录：
- 一个完整结论与它在讲述中的作用，标题不喊空口号。
- 一个能支持结论的主要证据图、过程、案例或对比。
- 必须保留的准确文字、姓名、数字、单位、网址和来源。
- 证据状态与不能暗示的结论。
- 视觉方向、资产引用、演讲秒数和下一页转场。
正文先定再生成。首次转换优先用已确认正文与坐标核对，OCR 只补定位和发现遗漏；不要丢掉上游正文后从图片重新猜一遍。
3. RW 图片初稿
进入 rw-consulting-ppt，读 本技能的生成边界，按需加载 RW 的视觉治理引用。输入已确定的正文、证据和产品风格，沿用它们，不再次问一轮相同问题。
通过原生 imagegen 生成完整 16:9 页面，文字也在该页面图中；禁止用 HTML、代码绘图或原生 PPT 排版栅格化来替代图片初稿。用代表样页验证标题层级、证据主体和文字密度，认可后锁定整套风格。
稳定命名为 slide_01.png 等，逐页核对必保文字、证据含义与实际比例；局部问题只改受影响页面。必要的图中文字纠错应发生在认可图片初稿之前，不能默许图片版有错而只在可编辑版中偷偷修正。
用既有脚本机械打包图片版，不编写另一套打包器：
bashpython3 <skill-dir>/scripts/package_image_deck.py <slide-image-dir> --out <output-dir>/roadshow-image-draft.pptx
4. 从认可初稿转换为可编辑稿
转换前必须读 两阶段交接与续做 和 image-ppt-to-editable。先完成一张代表页的底图清理、文字恢复、组装与整页检查，再按页或短批次推进；不积累大量素材而迟迟没有完整页面。
原初稿为整页位图时，以有意义的完整视觉对象划定素材边界，避免文字一块、箭头一块的碎切；已拆好的 PPT 则保持原图片数量、位置、尺寸、裁切、旋转和组织关系。两种情况不可混淆。
复用原素材和已经可用的去字成果。页脚、空白条和可复用底纹不默认单独生成。检查生成图是否新增留白或改变比例，检查跨图文本、中文字形度量、旋转、文字颜色、真实透明度与照片/界面保护范围。
图片素材里的目标文字必须真正清掉；原生文字应可见可编辑，不能用隐藏文本或遮盖脏底图虚报完成。复杂照片可保留为位图，图表只有源数据可靠才称数据可编辑。
5. 检查并交付
读 输出与验收。分别检查图片版和可编辑版，不对两个版本使用同一组对象数量规则。批量前验证中文渲染器；结构通过后再看完整页面。只复查修复所影响的页面与共享资源引用，不为了更保险反复全量重做。
路演按所选终点交付图片 PPT 或再加可编辑 PPT；完整路演按需附讲稿/时间表、Demo 预案、评委问答和简短来源说明。用户仅要 PPT 或转换时不强制扩展附加材料。
用户询问进度时直接报已回装且检查的页数，生成图片数另列。以整页和可打开的 PPT 展示成果，少输出细碎过程图和重复承诺。已认可页面冻结，全部约定问题解决、必要检查通过并另存后停止。
调用示例
用 $pitchcraft，根据这个仓库做 8 分钟答辩：先 RW 图片初稿，再给可编辑 PPT。用 $pitchcraft，沿用这些已认可 PNG，直接转可编辑，不重新生成。用 $pitchcraft，只清这份已拆好 PPT 的残字并补可编辑文字，保持图片组织。用 $pitchcraft，只做前两张图片样稿，等我看过再继续。
速度与局部修改的补充判断见 执行经验。
