Communitygithub.com

zairuilab/consulting-deck

基于证据、图表驱动、原生可编辑的咨询级PowerPoint技能

consulting-deck 是什么?

该技能是一个独立的演示文稿创作系统,专注于生成可直接决策的、原生可编辑的.pptx文件。它强调以证据为先导,通过图表作为主要分析语言,而非装饰性总结。技能支持多种创作模式(创建、修订、模板、审计),并引导用户遵循渐进式参考文档加载流程,从问题界定、故事线构建到布局选择和质量检查。它要求所有文本、图表、表格和简单图形在最终输出中保持可编辑性,避免使用扁平化截图,并确保所有主张都有可追溯的来源。该技能适用于需要生成咨级别演示文稿的AI代理(如Claude Code、Cursor、Codex),支持创建全新演示文稿、基于已有项目修订、应用品牌模板或审计现有文稿。其工作流程强调在项目工作区中保留可编辑的中间文件,并依赖机器可读的关卡文件作为决策依据。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add zairuilab/consulting-deck

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

咨询演示文稿(Consulting Deck)

创建可直接用于决策的演示文稿,而非装饰性摘要。构建清晰的论证,追溯每一项实质性主张,按沟通任务选择布局,并交付原生可编辑的.pptx文件,其中的文本、图表、表格和简单图形均可编辑。

将此视为由 彭 · 智珠在睿 创建的独立演示文稿系统。请不要暗示与麦肯锡、波士顿咨询公司、贝恩或其他咨询公司存在关联。除非用户提供了授权资产并明确要求使用,否则不得复制其徽标、专有模板或受保护的品牌资产。

加载正确的指导

逐步加载指导:

  1. 每次创建或修订路径,请从 references/harness-system.md、references/workflow.md 和 references/presentation-modes.md 开始。
  2. 对于主题、开放型业务问题、战略选择或从头开始的研究请求,请阅读 references/problem-solving-system.md。不要将假设树强加于忠实于来源的摘要请求。
  3. 构建主导思想和幻灯片序列时,阅读 references/storyline-system.md。
  4. 仅在存在定量证据或实质性展示项时,阅读 references/chart-system.md 和 references/charts-and-data.md。
  5. 规划方法示例和完整幻灯片系统时,阅读 references/visual-system.md 和 references/layout-library.md。
  6. 在验证和交付前,阅读 references/quality-gates.md。
  7. 仅在使用品牌、徽标、字体或PPTX模板时,阅读 references/brand-system.md。
  8. 在选择PPTX生产路径前,阅读 references/runtime-adapters.md。
  9. 在创建、恢复或修改已保存的演示文稿项目时,阅读 references/workspace-schema.md。

路由请求

选择且仅选择一条主要路径:

  • 创建 — 将源材料或主题转化为新的可编辑演示文稿。
  • 修订 — 修改现有已保存的演示文稿项目,并重新生成受影响的幻灯片。
  • 模板 — 应用用户提供的品牌或原生PowerPoint模板。
  • 审计 — 检查现有演示文稿,除非用户要求,否则不做更改。

请勿静默组合路径。模板请求可以优化创建或修订路径,但底层已保存的项目仍是唯一的事实来源。

建立生产契约

在开始创作之前:

  1. 确定受众、决策、演示背景、语言、页数、演示模式、密度模式、分析路径和来源边界。
  2. 当主机的当前原生PowerPoint功能可以创建可编辑对象并为每张幻灯片提供检查渲染时,请使用该功能。
  3. 仅当PptxGenJS已经可用或用户批准安装时,将其作为备选方案使用。切勿用HTML替代所请求的PPTX。
  4. 保留可编辑的项目工作区。切勿让最终的.pptx成为唯一的事实来源。
  5. 保持默认输出品牌中立。仅当用户明确选择Peng预设时,才应用 assets/brands/peng.json。
  6. 使用 references/harness-system.md 中的分阶段框架。不要直接从源文件跳转到幻灯片渲染代码。
  7. 将机器可读的关卡文件视为唯一的事实来源。除非对应的JSON文件存在且包含 "passed": true,否则绝不要声称某关卡已通过。

应用咨询标准

要求满足以下所有条件:

  • 以主导思想和答案优先的幻灯片标题为引领。
  • 对于问题解决路径,在广泛研究之前,先定义问题边界,构建议题树,并维护可证伪的假设。
  • 每张幻灯片有一个沟通任务和一个主要结论。
  • 确保横向逻辑在幻灯片之间连贯,纵向逻辑在每张幻灯片内部充分。
  • 区分事实、计算、来源解释和假设。
  • 在可见的脚注或演讲者备注中引用外部主张和资产。
  • 将图表作为主要的分析语言,而非次要的装饰层。
  • 在渲染每个实质性展示项之前,编写一份说明性的 charts.json 记录。
  • 使用 references/chart-system.md 中基于问题的图表家族、标注系统和渲染层级。
  • 对于用户可能需要检查或编辑的数据,使用原生图表。使用Vizro的可视化词汇和可选原型路径进行选择和验证,而非将其作为压平最终PowerPoint的许可。
  • 在研究分析模式下,在创建概念性摘要之前,重建来源的实质性展示项。满足 references/presentation-modes.md 中关于证据导向和原生图表的要求。
  • 使用 references/layout-library.md 中的语义布局;不要仅仅为了填充空间而发明布局。
  • 仅在封面、章节分隔页和少量决定性见解幻灯片上使用标题即结构的视觉手法。
  • 在交付前,以全尺寸渲染并检查每张幻灯片。
  • 保持机器检查和专家评审分开。几何脚本无法证明证据质量、图表真实性或高管清晰度。
  • 在 slides.json 中记录真实的跨幻灯片前置依赖关系。按依赖安全顺序生成,然后按面向受众的显示顺序组装。

使用两种密度模式

  • 演讲者主导 — 更少的文字,更大的字号,更多的页面,更强的节奏感。
  • 阅读优先 — 更多自包含的证据、注释和脚注。

根据演示背景选择一种模式。不要创建模糊的中间模式。当内容不合适时,拆分幻灯片或精炼论点,而不是减小字号。

密度模式不等于演示模式。阅读优先的高管故事和研究分析型演示文稿可能具有相似的文本密度,但展示项、脚注和概念性页面的比例不同。

预览视觉方向

当用户未提供锁定模板或明确视觉参考时:

  1. 从 references/visual-system.md 创建三个紧凑的视觉方向。
  2. 为每个方向展示一个真实的封面、一个分析/数据幻灯片和一个框架/行动幻灯片。
  3. 保持预览内容忠于用户的素材;切勿在幻灯片内部显示诸如“方案A”之类的内部标签。
  4. 要求用户选择一次,然后一致地应用所选系统。

仅当用户明确要求直接进行或提供了清晰的视觉参考时,才跳过此关卡。在项目工作区中记录所选方向。

保持可编辑性

  • 保持文本为文本。
  • 保持表格为表格。
  • 在切实可行的情况下,保持图表为原生图表。
  • 保持图表数据和图表意图与幻灯片布局代码分离。
  • 保持简单的矩阵、时间线、流程和议题树为原生形状。
  • 为照片、纹理艺术品或插图使用图片——不要为整个文字密集的幻灯片使用图片。
  • 切勿交付页面为扁平化截图的演示文稿。

从已保存项目迭代

对于诸如“更改幻灯片3的标题”之类的请求,请编辑项目源并重新生成受影响的输出。保留源材料、证据ID、图表数据、幻灯片ID和演讲者备注。重新运行所有受影响的质量检查以及最终的演示文稿级别检查。

学习而不改变已安装的技能

将每次实质性修正分类为一次性或可重复的。将可重复的经验记录在演示文稿工作区的 qa/experience-log.md 中;在常规演示文稿制作过程中,不要静默编辑已安装的技能。仅通过经过审查、版本控制的技能更新,将重复的经验提升到此技能中。

交付

交付最终的.pptx文件以及一份简洁的摘要。将中间计划、预览和质量检查文件保留在项目工作区内,除非用户要求查看。明确说明任何未经核实的声明、字体替换、兼容性限制或剩余警告。

相关技能