agentleFS
LOSTTEMPERLOSTTEMPER/agent-skill/beautify-presentations/SKILL.md

beautify-presentations

Skill0 starsChanged 3 months agoMITView on GitHub

Diagnose, redesign, and visually polish PowerPoint, PPTX, presentation, slide-deck, and Google Slides deliverables with coherent art direction, narrative hierarchy, accessibility, and render-based QA. Use when the user asks to 美化PPT、优化演示稿、统一视觉风格、提升设计感或艺术性、选择PPT风格、重构旧PPT、制作高端/咨询/发布会/杂志/电影感/包豪斯/孟菲斯/科技/拼贴/粗野主义/日式等风格,或审查一套演示的视觉质量;support both diagnosis-only requests and authorized creation/editing workflows.

The file

Files
SKILL.md

PPT 美化与艺术指导

把“美化”视为目标驱动的信息设计,不把它降级为换颜色、换字体或堆装饰。先保证内容、叙事和视觉层级成立,再建立艺术方向,最后通过逐页渲染验收交付。

必须联用的能力

  1. 加载并遵守当前环境中的 Presentations Skill,使用它完成 PPTX 或 Google Slides 的读取、创建、编辑、渲染、来源备注和文件交付。
  2. 把 Presentations Skill 的硬性文件操作、字体、重叠、来源和渲染要求视为底线;发生冲突时采用更严格的要求。
  3. 需要原创摄影、插画、纹理、3D 或艺术化信息图时,使用 imagegen;需要真实人物、地点、产品或事件时,优先使用合法的图像搜索。不要用代码绘制装饰图像。
  4. 不使用 python-pptx。按 Presentations Skill 指定的当前实现工具和工作目录完成 PPTX 操作。

先选择任务模式

只选择一个主模式,避免诊断、改稿和新建互相混淆。

模式用户意图允许动作默认交付
diagnose“哪里不好看”“给建议”“评审这套 PPT”只读检查,不改文件问题清单、优先级、风格建议
polish“不改结构,只统一和精修”保留叙事与页序,修正视觉系统和局部文案适配新副本 PPTX
redesign“彻底美化”“换一种风格”“重做版式”在不改变事实含义的前提下重排、拆页、合页、重做视觉新副本 PPTX
create“从文档/提纲做一套有设计感的 PPT”建立叙事、页面系统和视觉方向新 PPTX

若用户只要求诊断,不实施修改。若用户授权编辑,默认保留原文件并导出新副本;只有用户明确要求时才原位覆盖。

建立最小任务上下文

在开始实施前记录以下字段。能从源文件、对话或品牌材料中推断的先推断并标注假设;只有不同答案会显著改变设计或产生不可逆返工时才提问。

task_mode: diagnose | polish | redesign | create
audience:
purpose:
decision_or_action:
presentation_mode: live | reading | hybrid
venue_and_device:
duration:
language:
source_file:
brand_assets:
required_content:
editable_content:
forbidden_changes:
output_format:
deadline:

把以下四项视为必须先确认的高价值信息:

  • 是否存在必须遵循的品牌或客户模板;
  • 是现场演讲、独立阅读,还是混合交付;
  • 是否允许改写标题、拆页、合页和调整页序;
  • 哪些数字、法务表述、引用和审批内容不可改变。

若用户没有给出视觉方向,先形成两个或三个彼此明确不同的候选方向,用一句策略、关键词、配色倾向、图像方向和风险说明表达,不只给风格名。默认选择一个主风格,最多搭配一个辅助风格。

核心工作流

1. 完整检查源材料

对已有 PPTX:

  1. 按 Presentations Skill 检查全部幻灯片、母版、版式、备注和外部来源。
  2. 渲染全套并查看联系表,同时逐页查看代表页和异常页。
  3. 建立页面清单:页码、页面任务、主要主张、证据、页面原型、密度、视觉问题、内容风险、处理建议。
  4. 标记重复页面、孤立结论、无来源数据、错误图表、不可读文本、低质量图片、布局漂移和不一致组件。
  5. 识别用户提供的模板或品牌材料是否构成不可更换的视觉约束。

对新建演示:

  1. 先整理事实、材料、推理和未知,不把网络材料直接写成用户事实。
  2. 为全套演示写出观众在每个阶段应理解或决定什么。
  3. 在设计页面前确定故事线和逐页认知任务。

2. 先修复语义,再修复外观

为每页写一句“这页必须让观众得到什么”。按照以下顺序处理:

  1. 核对事实、数据、口径、单位、时间范围和来源。
  2. 把主题型标题改为主张型标题,但不得超出证据能够支持的程度。
  3. 删除不服务主张的噪声;保留关键术语、数字、定义和结构信号。
  4. 把相互竞争的多个认知任务拆页;把没有独立价值的碎片合并。
  5. 把方法细节、定义、来源和备查数据移到备注或附录,而不是直接丢失。
  6. 记录任何实质性改写;不擅自改变法律、合规、财务或客户承诺。

一页不必只有一条信息,但必须只有一个主要认知任务和一个清晰的第一视觉焦点。

3. 选择主风格与辅助风格

需要选择或混合风格时,完整读取 references/style-catalog.md。至少按以下四条轴判断:

  • 信息密度:极简展示 ←→ 密集阅读;
  • 情绪温度:克制理性 ←→ 亲和活泼;
  • 材质感:光洁数字 ←→ 手工触觉;
  • 主导媒介:文字网格、数据、摄影、几何、装饰、3D 或纹理。

优先匹配任务,不优先匹配流行词:

  • 管理层决策、经营复盘、投融资:高管咨询或瑞士理性网格;
  • 产品发布、现场演讲、愿景:极简产品发布;
  • 趋势、文化、品牌故事:编辑杂志;
  • 情绪与影像驱动:电影感摄影;
  • 奢华、仪式、传统工艺:Art Deco;
  • 设计、建筑、创新文化:包豪斯;
  • 年轻、教育、共创:孟菲斯;
  • AI、云、网络安全、深科技:未来科技;
  • 概念探索、作品集、档案叙事:手工拼贴;
  • 挑战者品牌、先锋文化:新粗野主义;
  • 酒店、疗愈、工艺、静谧文化:日式静谧。

不要把风格标签当作装饰快捷键。Bauhaus 不等于随机红黄蓝,Art Deco 不等于黑金边框,科技感不等于所有元素发光,日式不等于文化符号堆叠。

4. 生成可验证的 Style Spec

在实现页面前生成一份 JSON Style Spec,至少包含:

{
  "name": "项目内可读名称",
  "presentationMode": "live",
  "primaryStyle": "minimal-product-launch",
  "auxiliaryStyle": "swiss-grid",
  "intent": ["克制", "精确", "产品主导"],
  "antiIntent": ["模板感", "霓虹滥用", "满屏卡片"],
  "palette": {
    "background": "#F7F7F4",
    "surface": "#FFFFFF",
    "text": "#111111",
    "mutedText": "#5C5C5C",
    "accent": "#E5484D"
  },
  "typography": {
    "display": "Inter",
    "body": "Inter",
    "cjkFallback": "Noto Sans CJK SC",
    "deckTitlePt": 56,
    "slideTitlePt": 36,
    "bodyPt": 18
  },
  "grid": {"columns": 12, "marginPct": 5.5, "gutterPct": 1.5},
  "imageDirection": ["真实产品特写", "统一冷中性色调", "保留文字负空间"],
  "chartRules": ["直接标注", "只强调关键序列", "写明单位和来源"],
  "shapeRules": ["无阴影", "细线", "小圆角"],
  "motionRules": ["只用淡入和连续关系动画"],
  "forbidden": ["随机渐变", "低对比玻璃卡片", "无意义装饰图标"]
}

把 BEAUTIFY_SKILL_DIR 设为本 Skill 的绝对目录,把 STYLE_SPEC_JSON 设为规范文件的绝对路径,再运行以下命令。出现错误时先修复 Style Spec,再做整套页面:

node "$BEAUTIFY_SKILL_DIR/scripts/validate-style-spec.mjs" "$STYLE_SPEC_JSON"

脚本检查字段完整性、风格 ID、颜色格式、文字对比度、字号下限、网格范围和多风格拼盘风险。脚本通过不代表设计一定优秀,只代表规范具备基本可执行性。

5. 建立设计系统,不逐页自由发挥

至少定义以下 Token 和规则:

  • 背景、表面、正文、弱化文字、强调、正向、警示和风险色;
  • 拉丁字体、中文字体、fallback、字号阶梯、字重、行距和数字样式;
  • 页面边距、栏数、间距、对齐锚点和基线;
  • 图片题材、构图、裁切、调色、颗粒和禁止题材;
  • 形状圆角、描边、阴影、材质和图标体系;
  • 图表色板、网格线、直接标注、来源、单位和重点方式;
  • 封面、章节、内容、数据、图像、引文、总结和结尾原型;
  • 动效范围、节奏和禁用项。

优先使用一个平面构图,不把每页做成由卡片、徽章、标签和按钮拼出的伪界面。重复建立秩序,变化建立节奏。

6. 先做代表页,再扩展整套

在完整实施前先完成并渲染最能暴露问题的代表页:

  1. 封面或开场页;
  2. 章节页;
  3. 一页普通内容;
  4. 一页最复杂的数据或流程内容;
  5. 一页图片主导或总结页。

检查这些页面是否形成同一视觉语言,同时具有不同轮廓。若代表页不成立,不扩展整套。用户明确要求风格确认时,在此暂停;否则记录假设并继续。

7. 按场景控制密度和节奏

现场演讲 live

  • 让页面与讲述同步,减少完整段落。
  • 使用更大字体、更清晰视觉焦点和更强节奏变化。
  • 把详细证据、定义和来源放入备注或附录。
  • 不把固定的“每页若干字”当作科学定律;按观看距离实测。

独立阅读 reading

  • 保留完整上下文、图注、单位、来源、页码和导航。
  • 允许更高信息密度,但仍保持明确分组和主张型标题。
  • 不照搬纸媒过小字号;按目标屏幕和导出尺寸检查。

混合交付 hybrid

  • 让主叙事接近现场版;用备注、附录或第二套阅读版补足细节。
  • 不让同一页面同时承担舞台海报和完整报告两种相反任务。

8. 实施并保持可追溯

  1. 按 Presentations Skill 选择视觉路由并实施。
  2. 保留原始内容、版本和来源记录;在新副本中进行修改。
  3. 为外部非平凡主张和外部视觉资产在 speaker notes 中写入 [Sources]。
  4. 为每种外部图片记录原始 URL、作者或机构、授权状态、检索时间和使用页面。
  5. 不直接打包或复制第三方模板、Behance 作品或版权不明的图片;只提炼设计原则或使用获得授权的资产。
  6. 需要删改不可靠主张时,向用户明确说明,不用视觉权威感掩盖证据不足。

9. 渲染、评分和修复

完整读取 references/quality-gates.md,然后:

  1. 渲染每一页最终幻灯片。
  2. 查看整套联系表,检查节奏、风格漂移和页面轮廓重复。
  3. 逐页全尺寸检查文字换行、裁切、重叠、图片清晰度、图表口径和来源。
  4. 修复所有 P0 和 P1;P2 只在不破坏已确认方向时优化。
  5. 重新渲染受影响页面;发生母版、字体或布局级修改时重新渲染整套。
  6. 只有在内容正确、视觉一致、技术可靠三项都通过后才交付。

不可退让的质量底线

  • 不把虚假、无来源或口径错误的数据“包装得更可信”。
  • 不牺牲可读性来换取风格;不只用颜色表达状态或分类。
  • 不通过缩小字号解决内容过载;优先删减、重写、拆页或换版式。
  • 不让标题、横幅或单行标签意外换行。
  • 不保留任何未检查的重叠、越界、裁切、占位符或缺失字体。
  • 不混用超过一个主风格和一个辅助风格。
  • 不在相邻页面机械复用同一构图;保持系统一致但页面轮廓有变化。
  • 不复用同一张非背景图片填充多个页面。
  • 不用无关装饰制造“艺术性”;每个表达性元素必须承担情绪、层级、关系或隐喻。
  • 不擅自改变事实、数据、法律表述、客户承诺和已审批内容。

诊断输出格式

在 diagnose 模式下,先读取 references/quality-gates.md 并严格沿用其中的 P0/P1/P2 定义,再按以下结构交付。不要为了强调重要性随意把 P1 升级为 P0;例如错误数据、不可读关键文字和版权风险属于 P0,栏目式标题、层级混乱和风格漂移通常属于 P1。

  1. 一句话总体判断;
  2. 当前使用场景与关键假设;
  3. P0/P1/P2 问题清单,标明页码和对象;
  4. 内容、叙事、层级、视觉系统、艺术方向、无障碍、技术可靠性七维评分;
  5. 两到三个风格方向及各自适用条件、代价和风险;
  6. 推荐方向及最小验证动作;
  7. 若用户授权修改,说明预计会保留、重构和删除什么。

不要只给“更换字体、统一颜色、增加留白”一类无法验收的建议。每条建议都写成可定位、可操作、可验证的修改。

编辑交付格式

交付时简要说明:

  • 选用的主风格、辅助风格和选择依据;
  • 代表性的叙事或视觉修改;
  • 已完成并验证的项目;
  • 基于假设完成但仍需用户确认的项目;
  • 被保留的内容风险或外部阻断;
  • 最终 PPTX 文件,并按 Presentations Skill 的格式引用一次。

不要把临时规范、脚本、渲染图和中间文件作为最终交付,除非用户明确要求。

参考资源路由

  • 需要解释设计感、艺术性、认知原则、历史来源或方法边界时,读取 references/foundations.md。
  • 需要选择、组合或执行具体视觉风格时,读取 references/style-catalog.md。
  • 需要验收、评分、处理无障碍、版权、图表或输出问题时,读取 references/quality-gates.md。
  • 需要建立或检查 Style Spec 时,运行 scripts/validate-style-spec.mjs。

只读取当前任务真正需要的参考文件;不要为了显示完整而一次加载全部资源。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.