BP 精修是用于改进已有 BP（商业计划书）的技能，可在 deck 制作前、渲染后或纠正循环中使用，核心原则是在不悄然改变业务事实的前提下提升 BP 质量。
用途与模式 技能支持四种模式：content 面向大纲或 Markdown，聚焦产品定义、故事、文案与页面节奏；evidence 面向大纲加账本/来源，聚焦主张、指标、TAM/SAM/SOM 与假设；visual 面向 PPTX/PDF/幻灯片图片，聚焦层次、图表、布局、品牌与二维码；full 面向完整 BP 工作区，覆盖全部维度加纠正循环。应根据请求推断最小可用模式，例如用户只想审阅大纲时不应要求提供 PDF。若模式选择会实质改变工作内容，才提出一个简短问题；“不专业”默认 full，“文字太技术”默认 content，“图表不好看”默认 visual。
输出约定 输出位于 business-plan/ 目录，包括 reports/bp-review.md、outline.md（仅在请求授权时修补）、deck-manifest.md（视觉修复时更新）以及仅受影响的幻灯片/deck 资产。
工作流程 Step 0 确定来源与模式：以 SKILL.md 目录为 SKILL_DIR，检查提供的来源和已有 BP 工作区，复用受众、阶段、风格与证据定义，并按需读取审阅评分表、图表视觉、用户配置等参考文件。 Step 1 运行确定性大纲审计：当存在大纲时，用脚本 audit_bp.py 读取 outline.md 并输出 bp-review.md；最终交付前使用 --strict。脚本检查结构与证据卫生，不替代投资人判断或视觉检查。 Step 2 以四类对立视角审阅：非技术投资人（十秒后能否复述产品）、品类专家（产品/竞争主张是否幼稚或不精确）、怀疑的合伙人（核心主张是否缺乏证明或夸大牵引力）、设计总监（布局是否降低信任或扭曲含义）。每个问题需记录页码、严重程度、重要性原因和确切修改。 Step 3 润色中保护事实：不得让数字“看起来更好”、不得把假设变成事实、不得编造客户引语或证言、不得在没有买家与价格桥梁的情况下扩大 TAM、不得仅为改善故事而改变产品边界；若修改需要新证据，标记证据阻塞并退回 lov-bp-outline。 Step 4 检查渲染幻灯片：visual/full 模式下创建或检查联络表和正常演示尺寸下的每一页，检查每页一个结论、正文至少 20pt、视觉对齐与留白、图表坐标轴/单位/图例/日期/来源、真实清晰的产品截图、未拉伸的图片与 logo、无文字裁切或中日韩文字损坏、从最终渲染页解码二维码、封面整洁且末页有单一行动、PPTX/PDF 页数一致及文件名规范。 Step 5 应用针对性修复：将修复分类为文案修复（修补大纲并重新生成受影响幻灯片）、证据阻塞（先更新账本/来源再改写）、视觉缺陷（改布局/风格或仅重新生成受影响幻灯片）；不要因单页问题重生成整个 deck，最多重复审计→修复→审计三个循环。 Step 6 交付报告：以结论与评分开头，随后是阻塞项、页面级发现、证据缺口、视觉 QA 和交付状态，使用 bp-review.md 模板；目标为 85 分以上且无阻塞项，但高分不能覆盖编造数据、缺少融资诉求、来源损坏、幻灯片不可读或二维码无效。
运行上下文与反馈 运行前读取 skill.yaml，由宿主提供 skill-runtime/v1 上下文，字段解析顺序为当前请求、项目上下文、个人 Preferences、品牌 Profile、通用默认值；仅使用 Manifest 声明的字段。required 字段缺失时按 Manifest 问题配置向用户提出一个聚焦问题，经明确同意后再保存回答；报错提供可复制的 context_id、字段路径与来源，诊断内容避开秘密、完整私人路径和原始配置。用户提出修改意见时，须先判断是 task-specific（仅本次，只改当前任务）还是 reusable（可跨任务复用）；reusable 需先确定作用域，领域规则更新对应规范技能，通用规则更新共享规范，完成规则更新、版本、lint 与分发核验后再应用到当前任务。reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后须停下等待用户下一步指示，不自动进入发布、提交或其他外部写入。
适用场景与限制 适用于已有 BP 的审阅与润色，包括大纲阶段、deck 制作前、渲染后及纠正循环。限制包括：不能替代投资人判断；需要新证据的修改须退回大纲技能；不改变业务事实；未提及具体平台、价格或收费信息，暂未提供。