ppt-visual-review

PPT Visual Review

流程类 Skill，仅在用户显式调用 $ppt-visual-review 时运行。定位是布局验收：观众在投影尺度下看到的版面是否有序——箭头能读出起止、留白承担用途、同类元素长得一样、全局字体与颜色成体系、对齐与中文排版细节（孤字、避头尾、标点、中英混排、行长行距、字数字号）过关、层级与分组一眼可读。论据、数据口径等内容质量不在本技能范围。真实画面是判定依据，脚本测量是线索。

角色与模式

• 审查者：由 $bb-model-routing 派发的独立 BB 线程。亲自截图、逐页看图、裁决脚本线索、定级、复验；不修改 deck。审查者读完本文件后按 references/review-checklist.md 自己完成审查，是审查链的终点。
• 主 Agent：固定输入、派发、裁决意见是否采纳、修改源文件、运行项目验证、生成最终报告。不自审冒充独立审查。

默认修复模式：在审查范围内直接修改版式，不逐条询问。用户明确说"只审查/不改源文件"时为只读模式：只跑第 1 轮审查，跳过修复循环，直接出报告。

脚本线索与独立判断

measure-deck.js 只量得到 DOM 几何与计算样式：它不知道这页要观众读出什么，不知道哪处差异是有意强调，阈值也只是通用默认值。flags 是提问，不是结论；审查者和主 Agent 都要用自己的眼睛和判断作答，谁也不因为"脚本报了"就认定有问题，也不因为"脚本没报"就放过。

• 审查者裁决每条 flag，结论三选一，写进 findings.json 的 flagRulings（{round, id, page, ruling, reason}）。脚本 ID 每次运行重新编号，以轮次与 ID 联合定位，不用本轮 V12 覆盖上一轮同号记录：
  • valid：画面上确实影响阅读 → 形成 finding，why 写观众看到的影响，不写"flag V12 触发"。
  • dismissed：看图后不成立 → 点明该页的对象、位置和设计用途，解释线索所指的尺寸或关系为何合理。相同布局可以共用判断原则，每页仍要对应自己的画面证据；“有意留白”“不影响阅读”“没有溢出”本身不足以驳回构图问题。留白判断按清单的「留白」节执行。
  • threshold：阈值不适合这份 deck（如设计规范本就用 13px 页脚、宽松分栏）→ 按 deck 自身的版式契约调整参数重跑，在 context 记录新阈值与依据，后续轮次沿用。
• 脚本不覆盖的问题（层级、强调、分组、平衡、标点字形等）只凭看图形成 finding，与脚本来源的 finding 同等对待。
• 主 Agent 同样独立判断审查意见：除已列 findings 外，复看用户指出的页面，以及被驳回线索中视觉影响较大、连续多页重复、或与已采纳问题同类的代表页。发现相同遗漏时扩展到该组页面。在 context.hostReview 记录页 ID、相关 flag、实际画面判断和采纳/补审决定；截图打开记录、哈希和检查数量只证明流程执行。画面上看不出影响的 finding 可以 kept 并写理由；裁决缺乏页面证据时交回补审。
• 修复目标是画面变好，不是 flag 变少：不为消掉线索而做 1–2px 的凑数挪动、塞装饰填空带、改 class 名绕开检测。修复后线索仍在但画面已解决的，由审查者裁决为 dismissed；flags 清零也不等于 clean，clean 依据真实画面裁决及主 Agent 的复核。

派发方式

每次派发审查（首轮与新开的复审线程）都由宿主按名称加载 $bb-model-routing，用它的 bb-dispatch 发起，难度固定为 simple：

bb-dispatch --difficulty simple --title 'PPT 布局审查 rN' --task '<交接材料>'

• 不改用宿主内置 subagent，也不按页数或 deck 复杂度升档；provider、模型、推理级别由 bb-model-routing 的配置决定，不写进 --task。
• --task 开头写明：「你是本次 PPT 布局审查的审查者（reviewer）。读取 <本 Skill 绝对路径>/SKILL.md 与 references/review-checklist.md，亲自完成全部页的截图、看图、定级和记录。这是终点任务：不要再派发 subagent 或 BB 线程，不要调用 $bb-model-routing、bb-dispatch 或 $ppt-visual-review 发起新的审查流程，也不要修改 deck。」随后附交接材料。
• 派发后结束当前回合，等 BB 完成通知送达再读结果；不用 bb thread wait 或反复查询。
• 派发失败或线程因 provider/额度中断时，按 bb-model-routing 的 fallback 规则续派，仍为 simple。无法派发时记录缺口，不以主 Agent 自审替代。
• 一个审查线程覆盖全 deck；只有页数多到单线程无法完成时才按页拆分，每个线程同样是 simple 的终点任务，由主 Agent 合并覆盖记录。