Infographic Design資訊圖表設計

Design-system-grade explanatory graphics — timelines, comparisons, process diagrams — as clean, self-contained SVG or a single HTML file. Language-agnostic; built to be saved and reshared設計系統級的說明圖表(時間軸、比較、流程圖),輸出成乾淨、可獨立開啟的 SVG 或單一 HTML 檔案。跨語言通用,為收藏轉發而生

繁中ENModel-invoked模型叫用
Read SKILL.md on GitHub在 GitHub 看 SKILL.md

Design-system-grade explanatory graphics — timelines, comparisons, process diagrams — as clean, self-contained SVG or a single HTML file. Language-agnostic, and built to be saved and reshared rather than embedded once and forgotten.

Install

npx skills add https://github.com/leoluyi/skills -g -a infographic-design -y

Update later with:

npx skills update infographic-design

Source

What it does

Given a subject and an audience, it plans a graphic before drawing one: picks a message, a palette, a layout archetype (process/flow, comparison, hierarchy, timeline, part-whole, geo, hero-stat), and a signature element the graphic will be remembered by. It then builds that plan as either an SVG file (the default, and the source of truth for PNG/PDF export) or a single self-contained HTML file when motion or interactivity earns its place — directional flow gets animated, structural lines stay still, and prefers-reduced-motion is respected. It is language-agnostic — the subject can be described and labeled in any language, and the same process applies whether the output text ends up in English, Chinese, or a mix.

It covers three recurring forms directly:

  • A timeline — dated or sequenced milestones laid out so the reader can trace progression at a glance.
  • A comparison — two or more things set against shared criteria, with the distinguishing facts pulled to the surface rather than buried in prose.
  • A process / "how it works" diagram — a mechanism walked through step by step, with a worked example threading every step rather than abstract boxes and arrows.

It also handles ByteByteGo-style technical explainers (numbered walkthrough welded to the diagram) and single-file animated HTML recaps for a learning session that just ended — that route needs no further prompting once a teaching dialogue wraps up.

Every build follows the same internal discipline regardless of form: a three-level text hierarchy (headline, section, support), an 8-point layout grid with generous whitespace, honest quantity rendering (zero-baseline bars, no 3-D, no dual axes), and a palette bound to fixed neutral/theme/accent roles. None of that is exposed as configuration — it is simply how the skill builds.

When to use

Reach for it when you need an infographic, one-pager, timeline, comparison, or how-it-works diagram — or a visual recap of something just taught, which needs no further prompting to trigger. It also applies when another skill needs a figure designed for a document it is producing, and to reviewing an existing graphic for what could be improved.

An explicit ask for an infographic, 資訊圖表, 懶人包, or one-pager always qualifies, even when the underlying data is precise — precision and infographic form are not in tension. 懶人包 names the form rather than the content, though: a lookup table wearing that label is still a cheatsheet. Numbers that serve as evidence inside an explanation (a funnel's drop-off, a cache hit-rate) stay in scope too.

When not to

Skip it for a single standalone chart embedded in analysis output, for dashboards or BI tooling, for slide decks (use a pptx workflow instead), and for explaining a single term in plain language (use plain-speak).

It also steps aside for data-dense graphics where the numbers themselves are the subject or where precise scales matter — annual-results decks, survey findings, statistical graphics. The distinction is what the user names: the exclusion applies only when they ask for a chart, plot, or dashboard. Asking for an infographic that happens to contain precise numbers is still an infographic request.

Two more it declines. A cheatsheet — a dense quick-reference sheet of commands, syntax, parameters, or rules that a reader scans to look something up — is the opposite artifact from an infographic: lookup wants exhaustive rows, this wants one message that lands in a single read. And authoring a knowledge or technical document is knowledge-doc-writing's job, not something to route through this skill. The reverse direction stays open: that skill may call here to design a figure inside its document.

How it works

The design work — message, palette, layout, hierarchy, honest quantities, accessibility — is a self-critique pass: before delivery, the skill checks its own draft against the brief and, where one exists, against a real-world exemplar of the genre (a published diagram in the same style, held up side by side). That pass is judgment, and it stays judgment; it is not something a script can verify.

Underneath it sits a format-local construction preflight, run as python scripts/check.py out.svg --bg "<canvas>" --pad <card-padding>, which wraps two source-level checks:

  • check_contrast.py — verifies WCAG contrast ratios (4.5:1 for text, 3:1 for large text or graphic elements) so no color pairing is silently unreadable.
  • check_text_fit.py — catches the most common failure mode in generated SVG: text that overflows its box or gets clipped by its container.

Resolve preflight failures before rendering. The final reader-harming verdict comes from visual-output-qa, which inspects the delivered artifact rather than trusting source estimates. If preflight flags something, the fix order is: cut words first, then shrink type, and only as a last resort enlarge boxes by growing the canvas while holding the grid's gaps.

Everything else the gate reports — font-naming conventions, emoji use, CSS variable/renderer compatibility, restyle structure — is advisory: a judgment call left to whoever is building the graphic, never a blocking condition. That split mirrors a broader principle this project follows: a check only earns the right to block delivery when it catches an objective, reader-harming defect, not a style preference.

Related skills

  • plain-speak — use it instead when the job is explaining one term or concept in words, with no diagram needed.
  • A data-visualization workflow (not a skill in this repo) — reach for one instead when the numbers are themselves the subject: charts, dashboards, and BI-style displays where a precise scale matters more than a mechanism's story.

設計系統級的說明圖表——時間軸、比較、流程圖——輸出成乾淨、可獨立開啟的 SVG 或單一 HTML 檔案。跨語言通用,設計目的是被收藏轉發,而不是嵌一次就被遺忘。

安裝

npx skills add https://github.com/leoluyi/skills -g -a infographic-design -y

之後更新:

npx skills update infographic-design

原始碼

它做什麼

給定一個主題與讀者,它會先擬計畫再動筆:決定一句訊息、一套配色、一種版面原型(流程、比較、階層、時間軸、部分整體、地理、單一數字),以及這張圖會被記住的「簽名元素」。接著把計畫實作成 SVG 檔(預設輸出,也是匯出 PNG/PDF 的來源),或在動態效果/互動真正有價值時輸出成單一自足的 HTML 檔——方向性的流動用動畫呈現、結構性的線條保持靜止,並遵守 prefers-reduced-motion。它跨語言通用——主題描述與圖上文字可以是任何語言,不論最終輸出是英文、中文還是中英混排,流程都一樣。

它直接涵蓋三種常見形式:

  • 時間軸——有日期或順序的里程碑,排列方式讓讀者能一眼追出進展。
  • 比較——兩項以上事物依共同標準對照,把差異事實拉到表面,而不是埋在文字段落裡。
  • 流程/「運作原理」圖——一步步走過某個機制,並用一個實例貫穿每一步,而不是抽象的方塊配箭頭。

它也支援 ByteByteGo 式的技術圖解(編號走查與圖解焊在一起),以及教學對話剛結束時的單檔動畫版學習總結——這條路線在教學結束時會自動觸發,不需要額外提示。

不論哪種形式,每次產出都遵循同一套內部紀律:三層文字階層(標題、段落、輔助說明)、8 點格線版面配合大量留白、誠實的數量呈現(零基準長條圖、不用 3D、不用雙軸),以及綁定固定中性色/主題色/強調色角色的配色。這些都不是外露的設定選項——這就是這個技能建圖的方式。

何時使用

需要資訊圖表、one-pager、時間軸、比較圖或流程圖解時使用它;把剛教完的內容總結成一張圖時也適用,這條路線不需要額外提示就會觸發。另一個情境是別的技能需要為自己產出的文件設計一張圖;review 既有圖表哪裡可以改也算在內。

只要明確要求資訊圖表、懶人包或 one-pager,即使底層資料精確也一律適用——資料精確與資訊圖表形式並不衝突。不過「懶人包」指的是形式而不是內容:掛著這個名字的查詢用表格仍然是速查表。作為解釋內證據使用的數字(漏斗流失率、快取命中率)同樣在範圍內。

何時不要

單一嵌在分析輸出裡的獨立圖表、儀表板或 BI 工具、投影片(改用 pptx 流程),或只想用白話解釋單一名詞時(改用 plain-speak),都不要用它。

它也會讓位給數字本身就是主體、或精確刻度很重要的資料密集圖表——年度成果簡報、調查結果、統計圖表。判斷依據是使用者指名的東西:只有當對方指名要 chart、plot 或 dashboard 時,這條排除規則才適用。要求資訊圖表卻剛好包含精確數字,仍然算資訊圖表的請求。

還有兩件事它不做。速查表——指令、語法、參數或規則的密集清單,讀者是拿來查而不是拿來讀——與資訊圖表是相反的產物:查詢要窮盡列舉,這裡要的是一次讀懂的單一訊息。另外,撰寫知識文件或技術文件本體是 knowledge-doc-writing 的工作,不要繞道這個技能。反方向仍然成立:那個技能可以呼叫這裡,為它的文件設計一張圖。

運作方式

設計層面的工作——訊息、配色、版面、文字階層、誠實的數量呈現、無障礙——是一次自我批判:交付前,這個技能會拿自己的草稿對照原始需求,若有對應範例,也會拿這個類型裡真實存在的作品(同風格已發表的圖表)並列比較。這一段是判斷,並且始終是判斷;不是腳本能驗證的東西。

在這之下有一道格式建構前置檢查,執行方式是 python scripts/check.py out.svg --bg "<畫布色>" --pad <卡片留白>,它包了兩項來源層檢查:

  • check_contrast.py——驗證 WCAG 對比度(文字 4.5:1,大字或圖形元素 3:1),確保不會有配色組合悄悄變得無法閱讀。
  • check_text_fit.py——抓出產生 SVG 時最常見的失敗模式:文字超出邊界或被容器裁切。

前置檢查失敗要先處理,再進入渲染。最終會不會傷害讀者,由 visual-output-qa 檢查實際成品後判定,不直接相信來源估算。若前置檢查回報問題,修正順序是:先刪字、再縮小字級,最後才考慮放大方塊(靠放大畫布並維持格線間距)。

關卡回報的其他項目——字型命名慣例、emoji 使用、CSS 變數/渲染器相容性、重上色結構——屬於建議性質,留給實作者自行判斷,不會擋下交付。這個劃分呼應這個專案更廣的原則:只有抓到客觀、會傷害讀者的缺陷的檢查才有資格擋下交付,風格偏好不行。

相關技能

  • plain-speak——只需要用文字解釋一個名詞或概念、不需要畫圖時,改用它。
  • 資料視覺化流程(本 repo 沒有對應 skill)——數字本身就是主體時改找這類工具:圖表、儀表板、BI 式呈現,精確刻度比機制的敘事更重要。