---
name: lov-mobile-infographic
description: >
  把结论或材料整理成手机竖屏阅读的证据型信息图：输出永远是一张 1080 宽的 long 自适应卡片，内容多就把图加长、不拆卡；只有明确要求多张才做系列。交付可编辑 HTML 与 2× PNG。Use when the user says “把这个内容做成手机能读的信息图”“出一张竖版信息图”，or asks to "turn this into a mobile infographic".
license: MIT
compatibility: >
  Portable Agent Skills format. Python 3.8+; PNG rendering requires Playwright
  for Python with Chromium or Google Chrome. Generated HTML is portable and
  embeds the resolved brand logo as a data URL.
depends_on:
  - lov-branding-consistency
metadata:
  author: skill-publisher
  version: "0.18.0"
  card_standard: lovstudio/skill-card/v1
  content_class: microcopy
  tags:
    - mobile
    - infographic
    - card-series
    - readability
    - html
    - png
---

# 手机信息图 · Mobile Infographic

把一段已经有结论的内容，重排成手机上真的读得下去的证据型信息卡：单列阅读路径、
明确的字号下限、可核查的口径与来源，以及能从一张扩展到一组的系列结构。

这不是把咨询 Exhibit 缩小，也不是把整卡交给生图模型。文字、证据和排版全部由 DOM 生成，
PNG 由浏览器精确栅格化，交付时同时给出可编辑 `card.html` 与 2× PNG。

## Triggers

### Activate when

- 用户说“把上面这段做成手机能看的卡片”“做一组适合手机阅读的竖版信息图”“这段总结发朋友圈或小红书”。
- 用户要一张或一组竖屏信息卡，用于手机信息流、朋友圈、微信图文、小红书笔记或课程补充材料。
- The user asks to "turn this into a mobile infographic", "make a vertical infographic for phones",
  or "export a readable card series as PNG".

### Do not activate when

- 用户要的是 16:9 桌面阅读的咨询 Exhibit、指标矩阵或投资阶梯；交给 `lov-professional-infographic`。
- 用户要的是带独立插图的图鉴或收藏卡，或需要可复制生图 Prompt 的系列卡；交给 `lov-gen-card`。
- 用户要的是营销种草视觉图卡（多种卡通风格、生图渲染）；交给 `baoyu-xhs-images`。
- 用户要的是产品宣发海报或一页产品故事；交给 `lov-product-onepage`。
- 用户只要文字总结、幻灯片或文档排版；本 Skill 不替代写作、演示与文档能力。

## User Profile (cross-session)

Every generated Skill is connected to the shared `user-profile/v1` contract in
`skill.yaml`. Read the shared user, brand, workspace, preferences, and this
Skill's `skills.<skill_id>` namespace at the start of every run. Keep the source
portable: resolved personal values belong in the shared profile, never here.

When the user directly states a durable preference or brand fact, persist it
through `scripts/profile_store.py` and report the saved profile path. Put
Skill-specific values under `records.<field>`; use `brand.<field>` or
`user.<field>` for shared values. Do not persist inferred secrets or credentials.
See `references/user-profile.md` for the complete contract.

品牌解析顺序见 [`references/user-config.md`](references/user-config.md)。

## Skill Group Composition

Read `references/skill-composition.md` before deciding whether to invoke or
extend any adjacent capability. The record distinguishes optional upstream and
downstream handoffs from embedded Kit modules. Do not silently depend on a
sibling Skill that is not shipped with this source.

## 输出形态（只有一张图）

交付永远是**一张**卡：宽度恒为 1080，高度由内容决定（下限 1.2× 宽，**不设上限**）。
内容多的时候不加张数，把这一张加长——「一图读懂」本身就是长图形态。长卡用小节组织：
先给主排位（总览），再按领域分小节，每节一个小标题加一条细分割线，让读者在一张长图里
仍然有段落感；全卡仍然只有一个判断。矮内容不会被硬撑成固定比例。只有用户明确要求多张时，
才改用系列形态——系列是用户显式指定的例外，不是内容超长时的默认出口。固定比例（`3:4`/`4:5`/
`9:16`/`1:1`）是给渠道适配用的可选参数，不是默认值。

## 观点、图形与文案红线

一张信息图是**来源信息的重排**，不是作者评论：读者先看到事实、数字与口径。排版前先固定这几件事：

1. **标题只说明这张图是什么：作用或主题，二选一，不写判断句，也不写废话。**
   - 主题式（默认）：直接写这张图讲的主题，例如「十座未来城市的市政构想」。
   - 作用式：只在能给出真实信息时用——写清给谁看、回答什么问题、覆盖什么范围，例如
     「给新成员的 90 天上手地图」；「要点」「速览」「全览」「一图读完」「一图看懂」这类
     放在任何信息图上都成立的话是废话，`audit` 的 `title_filler` 会拦截。
   - 标题里不放「最／才／才是／其实／真正」这类论断词，不写「44 起案例里…」这种统计开头。
   - 标题里不要只有数字或符号；`audit` 的 `title_is_subject` 会拦截没有主题信息的标题。
   - 标题、眉标与副标题都不要再加前缀或提示词：机构名/调研名不必层层重复，不要写「结论：」。
   - **眉标（eyebrow）只放最少的定位信息**，不要塞生造缩写（「71 人可表态」这类没人看得懂）；
     样本量、分母、周期这类备注一律放到卡片末尾的口径行。副标题写不出一句人话时就删掉，不要凑。
2. **主关系必须图形化，且按数值倒序。** 三个以上同类项要比大小，用 `bar-ranking` 的条形长度编码，
   顺序从大到小（`audit` 的 `bar_order` 会拦截乱序）；构成关系用色块，流程用 `step-strip`。
   纯文字罗列（一行一个城市、一人一行）属于流水账，不构成信息图。
3. **排位项要展开“它是什么”。** 图表条目可能只有内部人认识时，必须给每条加一句它是什么、
   为什么值得选（例如每座城的一句话设定），再放名单。该展开的展开，不要只堆名字。
4. **不要用 bullet 复述图上的数字。** 「前三类合计 41 人、占 58%」「第二类 21 人」这类句子
   已经由条形长度和数值表达，重复成文字条目只是噪音；结论句里说一次即可。
5. **人名优先用对方自己公开的昵称**（群昵称、账号昵称），这类昵称本身就是可展示身份，不需要打码；
   只有在昵称缺失、昵称就是真实姓名、或材料涉及隐私时才退回轻打码（`刘＊畅`）或「群友 N」。
   **不要使用内部备注**（备注是给作者看的，不是给读者的）。
6. **口径要解释“这个数字怎么来的”**，不要用生造词。「71 人可表态」这种写法无效；正确写法是
   「依据过去一段时间的群聊记录自动分析，推断出每座城可能对应的成员，共 71 人」。
7. **长卡可以长，但只能有一个判断。** 全卡保留唯一的 `data-claim`，小节标题、分组条形与口径行
   都只给这个判断补证据。长卡允许放多个条形组（例如总览 + 分领域小节），每组在自己的
   `.chart` 容器内按数值倒序；不同分母不要混进同一组。
8. **长卡要还原来源的信息骨架。** 按来源自身的章节组织小节，每节给出它的要点、关键数字与代表
   案例（谁、做了什么、规模），不能只给总排行和一句结论；来源里每个章节都要落到卡上，
   内容放不下就继续加长这张图，不要靠删减细节收口。
9. **长卡优先用编码，不堆段落。** 先找更高密度的可视化：名单行、矩阵、小倍数、关键数字块、
   流程条带；案例级信息用一行一个名字的紧凑名单，只有章级要点才写句子。同样信息量尽量压进
   更短的图——把每个案例写成一段是最后手段，不是默认写法。
   需要真正的图表库（D3 等）时读 [`references/charts.md`](references/charts.md)：
   库要内联、文字留在 HTML 层、颜色与角度要有 `data-encoding`。
   长卡的默认顺序：**关键数字 → 构成与名单 → 时间线 → 手法/流程 → 专题**；同一个信息不要拆成
   两节（例如构成图与全名单合成一节），图表要带引线标注而不是留一列图例。
10. **不写作者总结与个人观点。** 正文只放来源的事实、数字与口径；`data-claim` 行是可选的
    （最多一条），只有来源本身有一句必须原样呈现的结论时才用，否则不写。小节副标题不要复述
    标题，不写「报告称／报告显示」这类来源提示，也不写「最该记住／值得关注」这类元话术——
    要么给事实，要么给编码说明（如「角度 = 案例数」）。

## 对外可见红线（强制）

- **来源与工具放进页脚上方的附录区块**（`.appendix`），用一条分割线起头，再用 bullets 写清
  「谁提供数据、谁做的呈现」。不要写 `Appendix`、`使用工具` 这类标题词——分割线本身就够，
  多一行标题只会抢主内容的注意力：

  ```html
  <div class="appendix" data-source-ref="S1">
    <div class="appendix-rule"></div>
    <ul class="appendix-list">
      <li class="appendix-item" data-role="source" data-source-ref="S1">
        <span class="appendix-key">数据来源</span>：Universal WeChat Key，https://lovstudio.ai/skills/wdb-cli
      </li>
      <li class="appendix-item" data-role="source" data-source-ref="S1">
        <span class="appendix-key">信息图呈现</span>：Mobile Infographic，https://lovstudio.ai/skills/mobile-infographic
      </li>
    </ul>
  </div>
  ```

  行内标签用「数据来源」「信息图呈现」这类说明性词。每条写成 **「网址对应页面的实际标题，完整网址」**：
  标题必须先去抓那个页面的 `<title>`／`<h1>`，不要自己起缩写或简称（把 Universal WeChat Key 写成
  「WDBK」这种就是错的）。网址一律印成可读文本：
  交付物是 PNG，超链接栅格化后不存在，禁止「点我」或只有能点才读得懂的锚文本。
- **页脚只放品牌，不放来源**：单卡居中放 Logo，不显示页码（`data-series-size="1"` 已内置居中与隐藏页码）；
  系列卡才保留左 Logo + 右 `n/N`。需要带品牌 Tagline 时用左 Logo + 右 Tagline 的变体。
- 仍然禁止本机绝对路径、数据库文件名、表名与账号标识（以 `.db` 结尾的文件名、数据库目录名、加密库名、
  `wxid_` 账号、`Msg_` 开头的表名）。`audit` 以 `source_hygiene` 拦截这些内部痕迹。

## Required references

Read before authoring:

1. `references/mobile-reading-standard.md` — 字号下限、行宽、对比度、安全区、比例与一屏信息量。
2. `references/template-grammar.md` — 六个语义模板的适用关系与选择规则。
3. `references/spec-schema.md` — HTML `data-*` 契约与 audit 字段。

Read `references/series-and-export.md` when the output is a series, a long image,
or platform-specific delivery.

## Workflow (MANDATORY)

**You MUST follow these steps in order.**

### Step 0: Resolve skill root, dependencies, and runtime context

- Use `SKILL_DIR` if the environment provides it.
- Otherwise infer the installed skill directory from the current skill context.
- Verify `scripts/infographic_cli.py`, `assets/card-base.css`, `assets/templates/`, and
  the required references exist before work.
- Resolve `context.profile` on every invocation. The precedence is current request,
  project context, Skill-specific profile records, shared preferences, shared
  brand/user profile, then safe defaults.

```bash
export SKILL_DIR="/path/to/lov-mobile-infographic"
python3 "$SKILL_DIR/scripts/infographic_cli.py" --help
```

### Step 1: Preserve and scope the source

- If the user says “以上内容”“刚才那段”“this result”, use the current conversation result.
  Do not ask them to paste it again.
- Keep the exact input in `source.md` under an `Exact input` section. Append normalized
  notes and calculations below it; never replace the supplied material.
- Decide the reader and the use moment: 信息流预览、朋友圈九宫格、微信图文内嵌、课程补充。
- Write the thesis first: one sentence the reader could disagree with, plus the evidence that
  backs it. If the material only yields a fact (“351 人里 2 人投票”), find the judgement behind
  it (「真正的信号不是票数，而是 88 个人的发言」) before drawing anything.
- Decide the visual encoding of the main relationship (bar length, colour block, order).
  A flat list of rows is not an infographic.
- Always deliver **one card**: when the material grows, keep extending the same card instead of
  adding cards. Keep one argument per card; only switch to a series when the user explicitly
  asks for several cards (see `references/series-and-export.md`).

### Step 2: Build the evidence table before the visual

Write `brief.md` from the scaffold, then fill the evidence table:

| ID | 论点 / 判据 | 精确证据 | 编码方式 | 直接标注 |
| --- | --- | --- | --- | --- |

For every visible mark record the source and location, unit, denominator, period,
and whether it is fact, estimate, assumption, or interpretation. Never invent a
proxy value or a score.

### Step 3: Choose one template and the ratio

Pick exactly one template from `references/template-grammar.md`; when three or more comparable
items have to be rank-ordered, use `bar-ranking` so the ordering is read as length, not as prose.
Default ratio is
`long`: one card at 1080 width whose height follows the content (at least 1.2× width,
no ceiling). Switch to a fixed ratio only when the delivery surface
demands it — `3:4` for WeChat article embeds, `4:5` for feeds, `9:16` for full-screen
story, `1:1` for grid tiles — and say which surface forced it.

### Step 4: Scaffold

```bash
python3 "$SKILL_DIR/scripts/infographic_cli.py" scaffold \
  --template single-claim \
  --ratio long \
  --filename card-01.html \
  --series-index 1 --series-size 1 \
  --eyebrow "运营手册 · 01" \
  --title "优化 harness 的三步" \
  --claim "模型是自变量，harness 是因变量" \
  --source "来源：…" \
  --output-dir "<project directory>"
```

The template is a semantic skeleton. Every element carrying `data-skeleton`
still holds placeholder copy.

### Step 5: Author the card

- Replace every `data-skeleton` element and remove the attribute once the copy is final.
- Keep exactly one `data-claim` element per card: the single conclusion this card argues.
- Attach evidence with `data-source-ref`; declare visual variables with `data-encoding`;
  mark decision-changing evidence with `data-annotation`.
- Write units next to values, put the caveat next to the number it qualifies, and keep
  the source line readable but subordinate.
- Do not add a second conclusion, a wall of similar boxes, or decorative imagery.
- Keep the brand footer: logo, attribution, and `n/N` page mark.

### Step 6: Render

```bash
python3 "$SKILL_DIR/scripts/infographic_cli.py" render \
  --input "<project>/card-01.html" \
  --output "<project>/card-01.png" \
  --scale 2
```

The renderer captures the `[data-card]` element at an exact pixel size and fails
when the PNG dimensions do not match the canvas.

### Step 7: Audit and review

```bash
python3 "$SKILL_DIR/scripts/infographic_cli.py" audit \
  --input "<project>/card-01.html" \
  --image "<project>/card-01.png" \
  --report "<project>/card-01.audit.json" \
  --ratio 3:4
```

The audit measures the rendered page in a real browser: font floors, characters per line,
contrast, overflow, out-of-canvas elements, safe area, single claim, evidence linkage,
brand footer, series page mark, remaining skeleton copy, and truncation. It writes a
100-point proxy with an 85 threshold and critical-dimension floors.

Then inspect the PNG at original detail **and** at thumbnail size (a 320px-wide downscale
is enough). Answer:

1. 5 秒内能否说出这张卡在讲什么？
2. 阅读顺序是否从标题到结论再到依据与来源？
3. 有没有被省略号截断、被裁切或压线的文字？
4. 每个数字是否带单位与口径？
5. 有没有大片空白或被撑满到窒息的区块？
6. 标题是可被反驳的观点吗？主关系是用图形（长度/颜色/顺序）表达的吗？
7. 卡面上有没有出现内部来源、数据库路径、表名或不该露出的真名？

Record the reviewed image and the concrete finding, then run the release gate:

```bash
python3 "$SKILL_DIR/scripts/infographic_cli.py" audit \
  --input "<project>/card-01.html" \
  --image "<project>/card-01.png" \
  --report "<project>/card-01.audit.json" \
  --ratio 3:4 \
  --human-review passed \
  --review-note "<what was verified at full size and thumbnail size>" \
  --strict
```

`passed` without both `--image` and a specific review note is invalid. Do not report success
because `audit.json` shows zero machine errors — the machine proxy is not proof of readability.

### Step 8: Series and export

A single card needs no manifest. Only when the user explicitly asks for several cards do you
scaffold a series with the same `--series-size`, write `manifest.json` from the case template,
and verify that every card keeps the same width, safe area, and footer position.
See `references/series-and-export.md`.

### Step 9: Deliver

Return clickable paths to the PNG, the editable HTML, `brief.md`, `source.md` and
`audit.json` — plus `manifest.json` only for a series (a single card never needs one). State the
template, ratio, evidence mode, proxy score, and human-review result. Disclose assumptions,
omitted material, and any card that is still machine-only verified.

## Dependencies

- Python 3.8+ standard library.
- Playwright for Python plus Chromium or Google Chrome for `render` and `audit`:

```bash
python3 -m pip install "playwright>=1.45,<2"
python3 -m playwright install chromium
```

- `scaffold` and `init-brand` need no browser and no network.
- Brand assets stay user-configurable; the packaged default is a placeholder profile,
  not a claim about the user's brand.

## CLI

```bash
python3 "$SKILL_DIR/scripts/infographic_cli.py" --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" init-brand --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" scaffold --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" render --help
python3 "$SKILL_DIR/scripts/infographic_cli.py" audit --help
python3 "$SKILL_DIR/scripts/test_infographic_cli.py"
```

## 通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 `task-specific`（仅本次）还是 `reusable`（可跨任务复用）。
2. `task-specific` 只修改当前任务，不改 Skill。
3. `reusable` 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. `reusable` 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。