| name | plugin-presentation-card |
| description | 为 Pi 扩展（插件）制作一页展示卡片（HTML），用 kami one-pager 模板。流程：读代码理解插件 → 读文章找定位 → 讨论布局 → 用 kami 出卡 → 反复调内容。必须使用此技能的场景：用户说「做一张展示卡」「做个介绍页」「出一页卡片」「写一个插件宣传页」「做个演示卡」「插件展示」「presentation card」，或完成了某个插件后需要一张介绍卡片。也适用于非 Pi 插件的工具/库/项目，只要用户想做一页介绍。 |
| when_to_use | 插件展示卡, 一页介绍卡, 插件宣传页, presentation card, 演示卡, 介绍页, one-pager, 产品卡, 工具介绍卡 |
Plugin Presentation Card — 插件展示卡制作
用 kami 的 one-pager 模板，为 Pi 扩展（或其他工具）制作一页 A4 展示卡片。这张卡用于文章插图、演示现场投影、社交媒体分享等场景。
核心原则
一页纸的命脉是克制
每个模块只保留最核心的信息。导语能一句话说完就别写三段——下面已经展开解释了。用户会抠字眼，每一句都要经得起推敲。
对比优先于罗列
痛点 vs 解法、旧方式 vs 新方式、处理前 vs 处理后。同屏对比比逐条说明更有视觉冲击力。在布局中刻意制造这种「左右对照」的结构。
叙事线贯穿始终
好的卡片有一条隐形的叙事线：问题 → 解法 → 体验 → 架构 → 安装。每个板块承上启下，不是功能列表堆砌。
截图是视觉锚点
一张好的 TUI/UI 截图抵得上一百字描述。截图的尺寸、位置、配文直接影响页面重心。两张图并排对比时必须统一尺寸，否则视觉上歪一边。
先讨论结构，再填内容
不要一次做完所有内容再给用户看。先用文字草图（ASCII 或描述）和用户对清楚布局，再填充模板。改结构比改措辞代价大得多。
工作流程
0. 加载 kami
加载 kami skill，让它执行自己的前置检查（品牌配置、更新检查等）。
1. 理解插件
先读插件的代码和 README，搞清：
- 这个插件做什么（核心功能）
- 它解决了什么痛点
- 用了哪些 Pi 扩展面（defineTool / renderCall / promptGuidelines / 生命周期事件 等）
- 有什么亮点——与其他同类工具/方式相比，它的核心优势在哪
输出：在心中形成 3-5 个关键信息点。
2. 读文章（如果有）
如果卡片是为某篇文章做的配图/插图，一定要先读那篇文章或章节。目的是：
- 理解插件在文章中的叙事定位——它是"第一个插件"还是"最复杂的插件"？
- 尊重文章给出的信息颗粒度——文章已经写过的内容，卡片不要啰嗦重复
- 从文章里复用精炼表述——作者自己写下的金句往往是最好的卡片文案
3. 讨论布局（必做，不要跳过）
在填模板之前，用 ASCII 草图向用户展示你的布局方案。讨论维度：
| 维度 | 决策点 |
|---|
| 受众 | Pi 开发者 / AI 工具用户 / 技术分享听众 |
| 叙事角度 | 问题→方案对比 / 技术深度 / 功能亮点 |
| 代码示例 | 是否需要？并排对比还是单示例？谁来截图？ |
| 截图 | 几张？截什么内容？并排还是上下？ |
| 输出格式 | HTML+PDF / PNG / 仅 HTML |
建议用这个格式展示布局（替换实际内容）：
┌── HEADER ────────────────────────────────────┐
│ ⬛ 标签 │
│ # 标题 │
│ 副标题 │
│ 作者 · 日期 · 版本 │
├── LEAD ──────────────────────────────────────┤
│ 一句话痛点定调 │
├── TWO-COL ───────────────────────────────────┤
│ 左: 痛点 │ 右: 解法 │
├── 体验/亮点 ──────────────────────────────────┤
│ ... │
├── 截图对比 ───────────────────────────────────┤
│ [图A] [图B] │
├── 架构/扩展面 ────────────────────────────────┤
│ 表格/列表 │
├── 安装 ──────────────────────────────────────┤
│ ⚡ pi install ... │
└── FOOTER ────────────────────────────────────┘
4. 用 kami 模板出卡
布局确认后，拷贝 kami one-pager 模板：
cp <kami-skill-dir>/assets/templates/one-pager.html <output-dir>/<card-name>.html
填充规则：
- 只编辑
<body> 内内容，CSS 不动
- 填写所有
<meta> 占位符（title/author/description/keywords）
- 去掉不用的模块（如 metrics、timeline）
- 不在最终文档中遗留任何
{{...}} 占位符
- 避免画蛇添足——用户没要求的文案不要自己加
内容填充要点
Header：
- Eyebrow：简短标签（"PI 扩展插件" / "工具" / "项目"）
- H1：插件名 + 一句话价值主张，可分两行
- Subtitle：一句话核心论点
- Meta：作者 · 日期 · 版本号
Lead（导语）：
- 一句话定调，点出最大痛点或最有吸引力的一点
- 用户明确要求简短就照做，不要额外加东西
两栏痛点 vs 解法：
- 左栏 2-4 条痛点，每条一短行
- 右栏对应 2-4 条解法，与左边呼应
双通道/体验（如果适用）：
- 如果同一个输出要服务两个不同的角色（如 LLM 模型和终端用户），用左右两栏展示各自收到的内容
- 左栏：一侧角色看到什么
- 右栏：另一侧角色看到什么
截图：
- 使用
.two-col 布局做并排对比，上方加 h2 标题
- 用户截图后嵌入 HTML：
data:image/jpeg;base64,... 转 base64
- 两张截图并排时，务必用 Python（Pillow）裁剪到相同尺寸（裁右边和底边）
- 配文要简洁，点出对比关键
扩展面/架构（可选）：
- 适合 Pi 开发者受众
- 用
table.compact 做两列表格：扩展面名称 | 在插件中的作用
- 标题用「N 个 X · M 个 Y」的格式
安装：
- 用
.callout + span.hl 展示安装命令
Footer：
5. 反复微调
内容填完后，用户会提修改意见。常见修改类型：
- 措辞调整：缩短/重写某句话、修改标注文字
- 结构改动：合并/拆分模块、调整先后顺序
- 截图处理：裁剪、重新截取、统一尺寸
- 删减冗余：去掉不必要的 detail、代码块、装饰性内容
修改策略：
- 每次只改用户指定的内容，不要顺手改旁边没提的
- 用户说「不要画蛇添足」时，意味着你加了没要求的东西——删掉
- 改完让用户刷新浏览器看效果，保持迭代节奏快
6. 收尾
- 嵌入图片：用 Python（Pillow 或 base64 模块）读取 JPG/PNG 文件，转为 base64 data URI，替换 HTML 中的
src 属性。验证没有残留的文件引用（grep -F 检查文件名是否还在 HTML 里）。
- 清理源图：确认所有图片已嵌入 HTML 后，删除独立的图片文件。
- 归入项目目录：创建或确认
docs/presentation-cards/ 目录存在，把 HTML 文件移入。如果需要放到别的路径，先问用户。
- 最终确认：
ls -lh 查看文件大小，确认单文件自包含、浏览器可打开。
模板选择
目前只用 kami 的 one-pager 模板。未来如果出现其他场景：
- 需要多页详细文档 →
long-doc 模板
- 需要 slides →
slides-weasy 模板
Kami 资源
以下文件按需读取，不要一次性全加载：
| 场景 | 读取 |
|---|
| 首次制作新卡 | CHEATSHEET.md + one-pager.html 模板 |
| 调整布局/间距 | 模板 HTML（CSS 只读）+ CHEATSHEET.md |
| 添加 SVG 图表 | references/diagrams.md |
| 质检 | references/anti-patterns.md |
直接加载 kami skill，由它管理自己的文件和路径。
停止条件
- 用户说「可以了」「就这样」「满意了」「没要改的了」
- 连续三轮反馈只改措辞、不改结构——说明内容已定型
- 用户明确说不需要再做任何调整
