用途：将一份已完成的工作打包成一份让评审者快速理解并批准的文档。评审者与构建者面对同样的未知，还多一层疑问：构建者是否考虑了专家会追问的失败点。好的提案文档一次阅读即可消除这两类疑问。
主要能力与结构：按怀疑者的阅读顺序组织文档。先放演示——展示工作运行的样子，GIF 或截图优于文字。接着是问题与赌注，最多两段：解决什么、为何选择该方案而非其他。然后是“专家会问什么”，列出该领域评审者会提出的 3-5 个难题（边界情况、规模、失败模式、迁移），逐一诚实回答，包括“未处理，原因是在当前阶段可接受”。再是偏离计划之处，直接取自实现说明，因为评审中发现的意外会损害信任。最后是“本次变更不包含什么”，划定范围，避免评审发散。
使用方式：收集规格或计划、原型或演示、实现说明和 diff；若用户可见行为有变化，索取演示录像或截图并放在最前。保持一页，规格、说明和 diff 用链接而非内联。根据场合匹配媒介：可粘贴到 Slack 的文档、PR 描述或独立 HTML 页面，不清楚时先询问。
限制与护栏：绝不夸大，隐藏已知弱点会把一次批准变成永久信誉损失。“专家会问什么”是核心，如果容易写，说明问题不够难。如果工作尚未就绪，诚实的提案就是状态更新，说明这一点也是该技能的一部分。
适用场景：需要向评审者快速传达已完成工作并争取批准的场合，如代码评审、方案评审、原型演示。具体平台、收费、价格等信息暂未提供。