已废弃，改用 bento-infographic（发布会 bento 信息图）。原用途：当使用者贴出产品资料、发布稿、规格表、卖点清单或网页摘录，说"做一张产品总结面板"、"生成发布会那种 summary slide"、"把这些卖点做成一张图"、"bento 风格的产品总览"时使用。
分两步：先产出 panel-brief.md（定位、核心卖点、支撑卖点、数字锚点、信息分组、每条的来源或未确认标记、版式建议、舍弃项与原因），等使用者确认后再产出单文件 panel.html（16:9 横版、内联 CSS、bento 卡片布局、light/dark 双主题、适合截图）。
只借鉴信息层级与面板结构，不复制任何厂商的资产、商标、截图或图标。不编造参数，无出处的数字标注或省略。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
已废弃（0.1.2）：改用
bento-infographic。使用者点名要本 skill 时，说明一句，改用它。
把一堆散落的产品资料，收成一张能直接截图用的 16:9 总结面板。
必须分两步走。 第一步只产出策划稿，第二步才产出 HTML。中间要等使用者确认。 一步到位的做法看起来快，实际是把"哪些卖点值得上、哪条数字有出处"这些判断藏进了 HTML 里， 使用者要么全盘接受，要么推倒重来。
不适用于 / Not for：
keynote-deck-builder，这个技能只出一张 16:9 的静态面板ui-design-system-builder使用者给什么都行，越原始越好：
需要问的只有两件事，其余从材料里读：
材料不足时说清楚缺什么，不要用常识补齐。
用 templates/panel-brief.md 起草。这一步不写任何 HTML。
必须包含的几块：
| 块 | 要求 |
|---|---|
| 产品名称与一句话定位 | 定位不超过 20 字，说清是什么、给谁 |
| 核心卖点 | 3 到 5 条，每条一个短标题加一句话 |
| 支撑卖点 | 6 到 12 条，构成面板的中小卡片 |
| 数字锚点 | 48MP、4K120、3x、2000 nits 这类，逐条标出处 |
| 信息分组 | Design / Display / Performance / Camera / AI / Battery / Safety / Ecosystem 之类，按材料实际有的分，不硬凑 |
| 来源标记 | 每条卖点后面跟出处；材料里没有的写 【未确认】 |
| 版式建议 | hero 区放什么、哪一条上最大卡、哪几条上大卡、哪些进小卡 |
| 舍弃项 | 哪些信息没上，为什么 |
舍弃项那一块不能省。使用者最常见的反馈是"某某卖点怎么没了"，写清楚为什么被舍弃， 比等他问一遍再解释省事。
写完停下，等确认。不要在同一轮里顺手把 HTML 也生成了。
确认之后，用 templates/panel.html 填充。
overflow: hidden，截图即所见<html data-theme="light"> 是默认，切换按钮放在舞台外面，
这样截图里不会出现按钮一张面板只有一个视觉重心：
三档之间的字号要拉开差距，不要三档挨着。挨着就等于没有层级。
发布会 summary slide 的语感，短。
| 位置 | 上限 |
|---|---|
| 最大卖点标题 | 12 字 |
| 大卡标题 | 8 字 |
| 大卡说明 | 24 字 |
| 小卡标签 | 6 字 |
| 数字锚点 | 数字加单位，不带句子 |
超了就是没想清楚。长段落一律拆或删，不要缩小字号硬塞。
font-variant-numeric: tabular-nums这一节优先于所有视觉要求。
阶段一：
已经把材料收成一版策划稿，你看看要不要调整分组和取舍：
<panel-brief.md 全文>
**我拿不准的：**
- <标注 1>
- <标注 2>
确认之后我生成 panel.html。
阶段二：
面板已生成：<文件路径>
- 版式：<hero 位置、最大卖点是哪条>
- 主题：默认 light，切换按钮在舞台外面，截图不会带进去
- 未确认项：<在面板上的哪几处，怎么标的>
- 需要你替换的：hero 占位图
| 版本 | 日期 | 变更 | 类型 |
|---|---|---|---|
| 0.1.2 | 2026-10-10 | 废弃，由 bento-infographic 取代：它按苹果总结片的实测比例排版、用 Chrome 渲染并自检，先出清单再出图的两步走和事实校验规则已搬过去。本文件保留到删除那一版，不再维护 | patch |
| 0.1.1 | 2026-09-26 | 模板与示例的小规格卡圆角 14px 改为 16px，与正文「卡片圆角 16–24px」一致；「不适用于」里要整套演示片时点名 keynote-deck-builder，落地页注明不在本库范围 | patch |
| 0.1.0 | 2026-08-12 | 初始草稿，最小可用版本 | minor |
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
当学生说"Common App 活动栏写不下"、"这段活动描述超字数了"、"帮我把这几条压到限制内"时使用。先按官方申请表核对当季字符限额，再逐条检查；一次把所有条目量完并直接给出压缩版，只在需要砍掉实质内容时才用选择题问该保哪部分。每改一版都用工具重新数一遍字符，绝不凭感觉说"这样应该够了"。只压缩，不代写空白。
The English summary is being prepared. Showing the original description.
当学生说"我参加过一些活动但没整理过"、"帮我把经历录进去"、"我的活动档案是空的"时使用。让学生一口气把记得的活动说出来，直接把这段话拆成结构化的长期事项（角色、组织、起止时间、做了什么、结果、级别），说不清的字段留空标"待补"而不是编，再用一张选择题卡把级别判定与是否重复这类关键项一次问完，然后提案入库。只记录学生真正说出口的内容，级别按事实判定，绝不往高了写。
The English summary is being prepared. Showing the original description.
当学生问"招生官会怎么看我的档案"、"我的背景还差什么"、"帮我评估一下现在的申请竞争力"时使用。以顶尖大学招生官的视角通读学生的档案、长期活动与已写下的反思，不问任何前置问题直接产出一份指名道姓的坦诚点评：这份材料的亮点、招生官真实的解读方式、明显的短板与空白、以及接下来最值得做的一到两件事。只读不写，不修改学生的任何数据，也不代写任何申请材料。
The English summary is being prepared. Showing the original description.
当使用者说"帮我填词"、"按这个字数模板写歌词"、"用多Agent对抗式写词"、"这首副歌帮我想几句"时使用，前提是字数骨架和这首歌写什么都已经有了；只有主题、还没定写什么时先用 lyric-concept-builder。拿一份字数骨架和意象系统，派三个 sonnet 子代理按不同路子并行独立起草（场景派 / 口语派 / 意象派），再派一个红队子代理逐句挑毛病，主 Agent 按句裁决拼稿，最后统一辙口与意象。收敛判据卡死：字数用 lyric-doctor 的脚本对模板数、每段同辙、hook 不含陈词、主歌二对主歌一有推进。不抄现有歌词，不替使用者决定这首歌要说什么。
The English summary is being prepared. Showing the original description.
当想知道一段 AI 回答"哪些能直接用、哪些必须先验证、哪些只能当建议"时使用。按声明类型分四级——低风险草稿材料、观点与策略建议、可查证的事实声明、会改变状态的可执行指令——每级配一句默认处置动作；再按影响半径排序，给出最小的下一步检查。可执行类一律标"不能直接执行；先做代码审阅/沙箱测试/回滚准备"，其中破坏性或提权的命令排在最前。教的是一套可复用的复查习惯，不是替使用者把所有内容都核实一遍：本 skill 只分级、排序、定处置，要逐条核实走 ai-output-fact-checker，整段代码要做入库体检走 ai-code-onboarding-checklist。
The English summary is being prepared. Showing the original description.
当拿到一段 AI 生成的代码，还没决定要不要信、要不要跑、要不要往上继续加东西时使用。先做一遍客观体检：行数与嵌套深度、有没有测试、有没有硬编码密钥或遗留 TODO、依赖是不是真实存在、有没有危险调用（eval/exec、shell=True、递归删除、反序列化、提权、外发网络，按正文给的 grep 模式逐类查）；再给风险评级和下一步动作。老实写明它查不了算法正确性——体检通过不等于代码是对的。回答里文字、事实和代码混在一起时先用 ai-answer-triage 分级；只审相对已有代码的一份改动用 ai-diff-review-protocol。
The English summary is being prepared. Showing the original description.