guizang-ppt-skill

Magazine Web Ppt

Source identification: guizang-ppt-skill is created and maintained by 歸藏, the canonical source repository is https://github.com/op7418/guizang-ppt-skill . Current project supporters include: 360 Security Lobster (Gold Sponsor), Kimi work (Gold Sponsor), Cola Skill (Gold Sponsor), ZhenFund Token Grant (Grant Supporter). This information is only used to confirm the Skill source and project support relationships; do not write it into the generated PPT, HTML pages, cover, or illustrations.

What this Skill does

Generate asingle-file HTMLhorizontal page-turning PPT, providing two optional visual tones:

Style A · Electronic Magazine × E-Ink (default)

• WebGL fluid / contour lines / chromatic dispersion background(visible on hero pages)
• Serif headings (Noto Serif SC + Playfair Display) + sans-serif body text + monospace metadata
• Suitable for: humanities sharing, industry observation, business launches, talks that need a "magazine feel"
• Templates:assets/template.html · Theme colors:references/themes.md · Layouts:references/layouts.md
• Aesthetic anchor: like Monocle magazine pasted with code

Style B · Swiss International Style (Swiss Style)

• WebGL ultra-thin grid + dot matrix background(information-driven design)
• All sans-serif (Inter + Helvetica + Noto Sans SC) + extreme font-size contrast
• High-contrast functional colors: Klein Blue IKB / lemon yellow / lime green / safety orange (choose one of four)
• Suitable for: tech products, data reports, design/engineering sharing, annual summaries
• Templates:assets/template-swiss.html · Theme colors:references/themes-swiss.md · Layouts:references/layouts-swiss.md
• Aesthetic anchor: like Massimo Vignelli + Helvetica Forever

Shared by both styles: horizontal page-turning (keyboard ← →, scroll wheel, touch screen, ESC overview), bottom-right P presenter mode, current/next page 16:9 preview, embedded grid page selector, title/purpose/speaker notes, group timer, rehearsal recording, optional auto page-turning, laser pointer/circling, audience screen black-and-white screen/freeze, sync status and disconnection recovery, pre-talk check, Lucide icons, Motion One entrance animations (local + CDN double insurance).

When to use

Suitable scenarios：

• Offline sharing / internal industry talks / private gatherings
• AI new product launch / demo day
• Talks with a strong personal style
• Web-based slides that need "done in one go, no page-turning tool"

Unsuitable scenarios：

• Large blocks of table data, chart overlays (use regular PPT)
• Training courseware (insufficient information density)
• Needs multi-person collaborative editing (this is static HTML)

Workflow

Step 0 · Check for updates before starting (required)

Before starting this Skill each time, first check in the Skill root directory whether the GitHub upstream has updates; if there is an update, first ask the user whether to update, and after the user confirms, execute the update, then continue with the subsequent process.

git -C "<SKILL_ROOT>" fetch --quiet
git -C "<SKILL_ROOT>" rev-list --count HEAD..@{u}

If the return value is greater than 0, tell the user the number of upstream updates detected and ask whether to run first:

git -C "<SKILL_ROOT>" pull --ff-only

Do not auto-update. If the user declines, continue using the current version; if the network is unavailable, there is no upstream, or it is not a git repository, explain that updates cannot be checked and continue the process.

Step 1 · Requirements Clarification (mandatory before starting)

If the user has already provided a complete outline + image/screenshot processing requirements, you can skip this and go directly to Step 2.

If the user has only provided a topic or a vague idea, align on each of these 7 questions one by one before starting. Do not start writing slides based on guesses—once the structure is set incorrectly, the cost of later rework is very high:

Runtime Environment Adaptation

• In Claude Code: use Ask Question / ask_question to clarify item by item, prioritizing inputs that affect layout such as style, audience, materials, and screenshot requirements.
• In Codex: ask the user directly in ordinary conversation; do not invoke Claude Code's Ask Question / ask_question mechanism, and do not assume these tools are available. Ask at most 1-3 of the most critical questions at a time; if the information gap does not affect starting work, make reasonable assumptions first and explain them in your reply.

7-Question Clarification Checklist

#	Question	Why ask
1	Style A or B?(Digital magazine style / Swiss International Style)	Must ask first, determines which template + layouts + themes files to use
2	Who is the audience? What is the sharing scenario?(internal to the industry / commercial launch / demo day / private salon)	Determines language style and depth
3	Sharing duration?	15 minutes ≈ 10 pages, 30 minutes ≈ 20 pages, 45 minutes ≈ 25-30 pages
4	Is there any source material?(documents / data / old PPT / article links)	If there is material, base it on the material; if not, help them build it
5	Are there any images or screenshots? How do you want them handled?	Determines image-text layout, image slots, and whether screenshots need CleanShot X-style adaptation or GPT-M 2.0 reconstruction
6	Which theme color set do you want?	Magazine style has 5 sets (themes.md) / Swiss style has 4 sets (themes-swiss.md), pick one
7	Are there any hard constraints?(must include XX data / must not include YY)	Avoid rework

Style Selection Reference (Question 1)

If the user says...	Recommended style
"magazine feel" / "humanities" / "Monocle style" / unspecified	A · Digital magazine style
"Swiss style" / "Swiss Style" / "Helvetica" / "minimalist" / "grid" / "infographic" / "data-driven"	B · Swiss International Style
The content is AI products / technology / engineering / data reporting	B is more suitable
The content is industry observations / humanities / stories / culture	A is more suitable
The user provided a large number of KPI figures / roadmap / process	B is more suitable (Data Hero layout is a Swiss-style specialty)
The user provided a large number of documentary photos / humanities images	A is more suitable (image grids and left-text-right-image are magazine-style specialties)
The user needs GPT-M 2.0 to generate a screenshot redesign / infographic / evidence wall	B is also very suitable (the S22 hero image and the S15/S16 image grid can carry evidence images)

Outline assistance (if the user has no outline)

Use the "narrative arc" template to build the skeleton, then fill in the content:

钩子(Hook)       → 1 页   : 抛一个反差 / 问题 / 硬数据让人停下来
定调(Context)    → 1-2 页 : 说明背景 / 你是谁 / 为什么讲这个
主体(Core)       → 3-5 页 : 核心内容,用 Layout 4/5/6/9/10 穿插
转折(Shift)      → 1 页   : 打破预期 / 提出新观点
收束(Takeaway)   → 1-2 页 : 金句 / 悬念问题 / 行动建议

Narrative arc + page count planning + theme rhythm table (see layouts.md),After the three tables are alignedthen proceed to Step 2.

If it is for a formal presentation, the page plan cannot only cover "what goes on this page"; it must also plan "what is said on stage" at the same time. First read references/presenter-mode.md, determine a stable data-slide-idfor each page, and complete:

Page number	Page ID	Section	Page purpose	Audience-visible information	Speaker supplements	Suggested duration	Transition	Optional on-site information

By default, generate 3-5 cue-card-style talking points, without writing a verbatim script; only expand it when the user explicitly requests a verbatim script. The total suggested duration should take up at most 90% of the user's duration, leaving buffer for pauses, interaction, and on-site surprises. Do not guess on-site information the user has not provided: when the duration is missing, show a dash, and hide other optional modules entirely.

It is recommended to save the outline as 项目记录.md or 大纲-v1.md, to facilitate subsequent iteration.

Image conventions (inform the user)

Before starting, make it clear to the user:

• Folder location:项目/XXX/ppt/images/ under (sibling to index.html )
• Naming convention:{页号}-{语义}.{ext}, for example 01-cover.jpg / 03-figma.jpg / 05-dashboard.png
  • Pad the page number with zeros for easier sorting
  • Semantics in English, short, specific, and corresponding to the content
• Specification recommendations:
  • Single image ≥ 1600px wide (to avoid blurriness on large screens)
  • JPG for photos/screenshots, PNG for transparent UI/charts
  • Keep the total size within 10MB (affects page-turning smoothness)
• How to replace: keepingthe same name and overwritingis the most reliable (no need to change paths in HTML); if the filename changes, remember to search globally for images/旧名 and change it to the new name
• What if there are no images: align with the user; you can first generate the structure using placeholder color blocks, and fill in the images later; but make it clear that layout 4/5/10 and other mixed text-and-image pages cannot have their visual effect verified without images

Screenshot requirement agreement (must ask before starting)

Whenever the user mentions product screenshots, web page screenshots, code screenshots, design mockups, dashboards, old PPT screenshots, or "help me beautify the screenshot", first confirm:

• Screenshot location: Which folder are the screenshot files in? Have they already been named?
• Purpose of use: faithful display / screenshot beautification / screenshot redesign / UI scenario image?
• Placement ratio: Which layout slot will it ultimately go into? Commonly used 21:9 / 16:10 / 16:9 / 4:3 / 1:1
• Content requirements: Must all text, brands, and data be preserved? Is there sensitive information that needs to be masked?
• Visual treatment: Is a themed background, margins, center/corner alignment, or splitting into long screenshot panels needed?

Default strategy: first make the content fit the template, then handle the image aspect ratio. When screenshots need to be faithful, first read references/screenshot-framing.md, and prioritize using assets/screenshot-backgrounds/ 's built-in background assets to procedurally adapt a CleanShot X–style background canvas; only when the original screenshot is too cluttered, too long, too narrow, or needs a conceptual expression should you use GPT-M 2.0 to redesign the screenshot.

Codex image generation (optional)

If the current runtime environment is Codex, after finishing the deck draft, proactively ask the user whether they need to use GPT-M 2.0 to generate images and insert them into the PPT. Do not generate by default.

Recommended way to ask:

Would you like to generate a few images for this PPT? They can be made into humanistic documentary photos, magazine-style infographics, process/comparison/system-relationship diagrams, or the screenshots can be redesigned into a unified magazine-style visual.

If the user confirms generation, then ask what image type or style they want; if the user has no preference, recommend 1-3 images most worth generating based on the page content.

If the user provides screenshots, first determine whether it isscreenshot beautificationorscreenshot redesign:

• Screenshot beautification: read references/screenshot-framing.md, use built-in theme backgrounds + procedural scaling/margin/alignment processing, and try not to redraw the screenshot content
• Screenshot redesign: read references/image-prompts.md, generate images at the target ratio according to the current layout slot, and keep the language, theme colors, and margins consistent

When generating images, follow:

• Keep prompts short; only define the theme, purpose, style, and ratio. Do not write lengthy photography directions.
• The image style must match the current deck style: Style A uses "electronic magazine × e-ink"; Style B uses "Swiss International Style / Swiss Style"
• The text language in infographics, charts, and screenshot redesigns must follow the language the user is using; Chinese decks use Chinese, English decks use English
• First look at references/image-prompts.md to choose the image type and base prompt
• If processing the user's original screenshots, first look at references/screenshot-framing.md: prefer calling assets/screenshot-backgrounds/ built-in backgrounds and procedurally perform CleanShot X–style screenshot adaptation; only use GPT-M 2.0 to redraw when the information needs to be restructured
• Image ratios must match the final placement: main visual 16:9, text-left image-right 16:10 / 4:3, infographic 16:9 / 16:10, screenshot redesign 16:10, small mixed text-image images 3:2 / 3:4, grid images uniformly height-cropped
• Place generated images under images/ , naming follows {页号}-{语义}.{ext}

Step 2 · Copy template

According to the style selected in Step 1, copy the corresponding templateto the target location (usually 项目/XXX/ppt/index.html), and at the same level create a images/ folder ready to receive images.

mkdir -p "项目/XXX/ppt/images"

# 风格 A · 电子杂志风
cp "<SKILL_ROOT>/assets/template.html" "项目/XXX/ppt/index.html"

# 或 风格 B · 瑞士国际主义风
cp "<SKILL_ROOT>/assets/template-swiss.html" "项目/XXX/ppt/index.html"

Both template*.html arefully runnablefiles—CSS, WebGL shader, page-turning JS, presenter mode, audience screen sync, font/icon CDN are all preconfigured; only <!-- SLIDES_HERE --> placeholders and SPEAKER_NOTES await your filling in.

Note: Styles A and B cannot be mixed. Classes in layouts.md (such as .h-hero serif large headings,.display-zh , etc.) are only defined in template.html; classes in layouts-swiss.md (such as .kpi-hero、.accent-block、.span-N、.dots , etc.) are only defined in template-swiss.html. A deck can only choose one set.

2.1 · Required placeholder changes (easy to miss）

After copying, immediately change the following placeholders, otherwise the browser Tab will show awkward text like "[Required] Replace with PPT title":

Location	Original	Change to
<title>	[必填] 替换为 PPT 标题 · Deck Title	the actual deck title (e.g. 一种新的工作方式 · Luke Wroblewski)

Every time after copying template.html, the first thing to do: grep for "[required]" to confirm all have been replaced.

2.2 · Choose a theme color (5 presets · no custom allowed)

This skill only allows choosing one of 5 carefully curated presets, and does not accept user-defined hex values—wrong color combinations instantly make the visuals ugly, and protecting aesthetics matters more than granting freedom.

#	Theme	Suitable for
1	🖋 Ink Classic	General / business publishing / the default when you don't know what to choose
2	🌊 Indigo Porcelain	Tech / research / data / technology launch events
3	🌿 Forest Ink	Nature / sustainability / culture / nonfiction
4	🍂 Kraft Paper	Nostalgia / humanities / literature / independent magazines
5	🌙 Dune	Art / design / creativity / galleries

Action:

1. Recommend one based on the content topic, or directly ask the user which one to choose
2. Open references/themes.md, find the corresponding theme's :root block
3. Replace the whole assets/template.html(copied version) at the beginning, the lines marked with the "theme color" comment in the :root{ block(--ink / --ink-rgb / --paper / --paper-rgb / --paper-tint / --ink-tint)
4. All other CSS follows var(--...), no other changes needed

Hard rules:

• A deck uses only one theme; do not switch colors midway
• Do not accept any arbitrary hex values from the user—politely decline and show the 5 options to choose from
• Do not mix and match (e.g. using Ink Classic for ink and Dune for paper)—it will be completely jarring

Step 3 · Fill in content

3.P · Generate speaker notes in sync (mandatory for formal presentations)

Read references/presenter-mode.mdfirst. Each <section class="slide ..."> must have a unique and stable data-slide-id, then generate one SPEAKER_NOTES record in the same order. Notes are stored by page ID; do not use array indices or page numbers as persistent keys, otherwise after page reordering the notes the user edited in presenter view will get mixed up across pages.

Division of content:

• The slide only contains the conclusions, structure, and evidence the audience must see at this moment.
• purpose explains this page's role in the overall narrative.
• talk supplements background, examples, basis for judgment, and tone; do not repeat the slide word for word.
• transition explains why the next page appears immediately after.
• section Only fill in when the outline has already given sections or consecutive pages clearly belong to the same section.
• minutes is the speaking plan;autoAdvanceSeconds is playback behavior; the two must be separated, and the latter is only filled in when the user explicitly requests it.
• cue / interaction / delivery / advance / fallback / pronunciation Only write stage actions, interactions, expressions, page turns, backup, and pronunciation information explicitly provided by the outline or the user.

Facts without supporting sources cannot be written into the notes; missing information that affects content correctness should be marked "to be supplemented" or ask the user, while optional speaking information that does not affect the content is omitted directly.

3.0 · Precheck: class names must be defined in the template's <style> (most important）

This is the source of all generation problems. The layouts skeleton uses many class names; if the template's <style> has no corresponding definition, and the browser will fall back to default styles—the large heading font is wrong, cards are crammed together, the pipeline blurs into one line, and images pile up at the bottom of the page.

The two style class names are not interchangeable(emphasis again):

• Style A templates include h-hero(serif),stat-card、grid-2-7-5、frame , etc.
• Style B templates include h-hero(sans-serif),kpi-hero、accent-block、span-N、dots、grid-12 , etc.
• The same class name in the two templateslooks completely different(Example: Style A's h-hero is Noto Serif SC serif, Style B's h-hero is Inter sans-serif)

Before writing any slide code:

1. First Read the template currently in use(at least read to the end of the <style> block):
   • Style A → assets/template.html
   • Style B → assets/template-swiss.html
2. Check against the Pre-flight list in the corresponding layouts file, and confirm that every class you want to use exists in <style> exists in
3. If a class is missing:Add it in the template's <style> add it in, do not rewrite it inline in every slide
4. The template is the only source of class names—do not invent new class names; if customization is needed, use style="..." inline

Classes commonly missed in Style A: h-hero / h-xl / h-sub / h-md / lead / kicker / meta-row / stat-card / stat-label / stat-nb / stat-unit / stat-note / pipeline-section / pipeline-label / pipeline / step / step-nb / step-title / step-desc / grid-2-7-5 / grid-2-6-6 / grid-2-8-4 / grid-3-3 / grid-6 / grid-3 / grid-4 / frame / frame-img / img-cap / callout / callout-src / chrome / foot

Classes commonly missed in Style B(after the 2026-05 refactor):

• Canvas:canvas-card / chrome-min
• Typography:h-hero(sans-serif 7.4vw weight 200) / h-statement(9.6vw) / h-xl / h-md / t-cat(SemiBold 600 small label) / t-meta(mono uppercase) / lead / num-mega / mono
• Cards (four mutually exclusive types):card-ink / card-accent / card-fill / card-outlined
• Grid:grid-12 / grid-2-9 / grid-2-9-5 / span-N
• Timeline:timeline-v + tl-node + tl-axis + dot / timeline-h + tl-h-node + tl-h-axis
• Charts:kpi-tower-row + bar-tower / h-bar-chart + bar-row + bar-fill / spec-bars + bar-vert
• Decoration:dot-mat(SVG mask solid dot) / ring-mat(outlined circle) / cross-mat(× grid) / hr-hairline
• Layout-specific:cover-split / closing-split / duo-compare + vrule / manifesto-top + ink-banner-full / three-forces / loop-diagram / matrix-fill + matrix-cell / brief-grid + brief-card / system-diagram / why-now-grid / four-cards / stacked-ledger + ledger-row / tech-spec / image-hero + hero-img-wrap + hero-overlay-block + hero-stats
• Image mixing:frame-img / fit-contain / r-21x9 / r-16x9 / r-16x10 / h-22 / h-26 / swiss-img-split / swiss-img-grid / swiss-img-caption / swiss-keyline / swiss-lined
• spacing token:--sp-3...--sp-13(8/12/16/24/32/40/48/64/80/96/160 px)

3.0.5 · Plan the theme rhythm (is as important as the class pre-check)

Before choosing layouts, you must first list each page's theme class (hero dark / hero light / light / dark) and write it into the document or draft for alignment. For detailed rules, see references/layouts.md the "Theme Rhythm Planning" section at the beginning.

Mandatory rules:

• Each page's section must include one of light / dark / hero light / hero dark , do not write only hero
• 3 or more consecutive pages with the same theme = visual fatigue, not allowed
• 8 or more pages must have ≥1 hero dark + ≥1 hero light
• The entire deck cannot have only light body pages; it must have dark body pages to create breathing room
• Insert 1 hero page every 3-4 pages (cover/act cover/question/large quote)

Self-check after generation:grep 'class="slide' index.html List all themes, manually confirm the rhythm is reasonable, then deliver.

3.1 · Choose layouts

Do not write slides from scratch. Open the corresponding layouts file; it contains 10 ready-made layout skeletons, each a complete copy-pasteable <section> code block.

Style A → references/layouts.md:

Layout	Purpose
1. Opening cover	Page 1
2. Chapter act cover	Opening of each act
3. Big data statement	Present hard data
4. Quote + Image	identity contrast / story
5. Image Grid	multi-image comparison / screenshot evidence
6. Two-Column Pipeline	workflow
7. Suspense Close / Question Page	finale / closing
8. Big Quote Page	serif punchline / takeaway
9. Side-by-Side Comparison (Before / After)	old model vs new model
10. Lead Image + Side Text	information-dense image-text page

Style B → first read references/swiss-layout-lock.md, then read references/layouts-swiss.md。

Swiss theme defaults to entering Swiss locked mode:

• body pages may only use the 22 layouts registered in the original reference PPT S01-S22; newly added cover/end pages may only use those explicitly provided by the Skill SWISS-COVER-ASCII / SWISS-CLOSING-ASCII。
• each <section class="slide"> must have data-layout="Sxx". Without data-layout it is considered an unregistered layout.
• temporarily inventing P23/P24、Swiss Image Split、Evidence Grid body structures outside the original 22P is not allowed, unless the user explicitly requests an experimental layout.
• Top Chinese titles are left-aligned by default and sit on the upper-left content axis. Do not put the subtitle in the left column and the main title in the right column, causing visual centering; only the original statement/split layouts allow strong centered narrative.
• SVG is only responsible for geometric shapes. Do not write text labels in SVG; use HTML grids/cards/captions for all labels instead.
• Geography/history/city routes/location relationship pages use S08 + Swiss Map Component: first read references/swiss-map-component.md, still retain data-layout="S08"。

The original 22 body layouts are as follows:

Layout	Purpose
S01 Index Cover	original index cover
S02 Vertical Timeline + KPI	evolution comparison / era change
S03 Split Statement	core argument / left-right split screen
S04 Six Cells	6-item concept definition
S05 Three Layers	three-layer architecture
S06 KPI Tower	4-item data visualization height difference
S07 H-Bar Chart	5-10 item ranking comparison
S08 Duo Compare	Before/After comparison
S09 Dot Matrix Statement	big quote / statement
S10 Split Closing	closing page
S11 Horizontal Timeline	4-7 step process
S12 Manifesto + Ink Banner	stage conclusion
S13 Three Forces	deepening of 3 peer concepts
S14 Loop Form	self-learning loop / automation
S15 Matrix + Hero Stat	8-12 item matrix + total data
S16 Multi-card Brief	6-item quick news small cards
S17 System Diagram	three-layer architecture / ecosystem map
S18 Why Now	three arguments + data support
S19 Four Cards	4-item equal-weight features
S20 Stacked KPI Ledger	vertical bill data
S21 Tech Spec Sheet	product specs / benchmark
S22 Image Hero	21:9 top image + title block + three-column KPI

registered extension:S08 + Swiss Map Component is used for locations, people's residences, routes, and city relationships. It is not a new layout, but the MapLibre map component in the right-side slot of S08; it must be implemented according to references/swiss-map-component.md 's points, connecting lines, cards, and upper-right zoom/drag controls.

Select the corresponding layout, paste it over, and just change the copy and image paths.Be sure to complete the 3.0 pre-flight first。

Style B layout diversity hard rules:

• a 7-8 page deck uses at least 6 different S-numbered layouts; for 10 or more pages, use at least 8 different layouts.
• If the user says "test template / see the effect / more layouts", it must cover: one cover, one closing, at least 1 comparison or timeline (S08/S11/S02), at least 1 structural diagram (S14/S17/S15), at least 1 image layout (S22 or S15/S16 image grid adaptation).
• It is not allowed to use the same main structure for 3 consecutive pages, for example three consecutive pages head + grid + card。
• Image pages must not lazily invent new structures. For 2-3 images, use the original grid skeleton of S15/S16 and adapt it into image cells; for a single large image, use S22.
• Before starting to write HTML, first list a 页码 → data-layout → 选用理由 → 图片槽位 draft; before delivery, run node <SKILL_ROOT>/scripts/validate-swiss-deck.mjs index.html. The validator will first perform a static structure check; if Playwright can be resolved in the environment, it will also measure visible boundaries, bottom whitespace, nav safe lines, and title spacing after real rendering.

3.2 · Image aspect ratio specifications

Always usestandard aspect ratios, do not use the original image's bizarre aspect ratio (such as 2592/1798):

Scenario	Recommended aspect ratio
S22 top main image	21:9; place the key subject of the photo in the central safe area
S15/S16 multi-image grid	uniformly 21:9 or uniformly 16:10, do not mix them
Left text right image main image (Style A)	16:10 or 4:3 + max-height:56vh
Image grid (Style A)	fixed height:26vh, do not use aspect-ratio
Left small image + right text	1:1 or 3:2
Full-screen key visual	16:9 + max-height:64vh
Mixed text and image small illustration	3:2 or 3:4

By default, do not let images align-self:end— it will slide to the bottom of the page and easily touch the pagination component. Use a grid container + align-items:start(already preset in the template) to make the image stick to the top; if bottom alignment of text and image is really needed, you must first control the image height, then use the template's existing safe area class .nav-safe-bottom / .nav-safe-bottom-tight, and do not let the lowest point touch the pagination component.

Style B Swiss style additional rules:

• For a single large image, use S22; for multi-image tests, use the original card grid of S15/S16 and adapt it, do not use unregistered P23/P24
• Before generating images, first write data-image-slot: for example s22-hero-21x9 / s15-grid-21x9 / s16-brief-21x9
• S22 supporting images are generated at 21:9 by default, and the prompt must include subject centered in the safe middle area; the photo container uses object-position:center 35%, do not use top center
• Image containers must have right angles, no shadows, and no rounded corners; the default background uses white var(--paper), do not use a gray background wrapping a white-background infographic
• White-background GPT infographics/flowcharts/UI images should by default not add outer frame strokes, and do not casually apply .swiss-keyline; when emphasis is needed, only use .swiss-lined the top accent line
• If a UI/infographic is the user's original screenshot or a text-dense image, only then use .fit-contain; if it has been regenerated according to the S15/S16 slots, it must use .frame-img.r-21x9 / .frame-img.r-16x10 to fill the container, do not fix height:18vh and then shrink the image
• Multiple images in the same group must use unified image slots, aspect ratios, and heights, and must not be mixed
• GPT-M 2.0 generated images use image-prompts.md the "Style B: Swiss International Style image rules"
• The lowest point of any image, caption, timeline label, or footnote must not enter the bottom pagination area; when bottom alignment is needed, use .nav-safe-bottom / .nav-safe-bottom-tight, do not hand-write bottom:2vh

3.2.0 · Mixed text and image decision tree (migrated from social card rules)

First determine the role of the image on this page, then decide the container, aspect ratio, and cropping method:

• evidence screenshots / UI / code / dashboard: prioritize fidelity, first read references/screenshot-framing.md; key text and data must not be cropped out. When a unified aspect ratio is needed, prioritize a programmatic background canvas + .fit-contain, do not crop out UI content just to fill the space.
• infographics / illustrations regenerated by slot: fill according to the target slot, for example S22 uses 21:9, S15/S16 use a unified 21:9 or 16:10; do not shrink the image into a small tile with a short height again.
• photos / product images / portrait images: use a standard aspect ratio + clear object-position; the subject, face, product, and key evidence must not be covered by the title, caption, or cropping.
• text over image / full-screen key visual: first make a quiet-zone judgment; the image must have at least about 30% low-detail area to carry text; if it fails, change the image, change the crop, or switch to a split text-image layout. Add a local tint only when necessary; do not apply a black/white overlay to the entire page.
• multi-image group: within the same group, unify aspect ratio, height, container treatment, and caption density; do not have one contain, and another cover。
• generated images are assets, not a full-page slide: the image itself must not contain a header, footer, page number, logo, main title, decorative border, or signature, to avoid duplicating the deck chrome.
• text-image breathing room: the title, image, caption, and body text must each have spacing; after generation, use the validator's M1/M2 to check visible boundaries, bottom whitespace, nav safe lines, and title spacing.

3.2.1 · Chinese large-title font-size tiers (required for Style B)

Chinese block characters have a large visual area and cannot directly use the 6.8-7vw of an English hero. Before writing a Chinese large title, first assign a tier:

Title form	Recommended font size
1 line, ≤ 8 Chinese characters	min(6.4vw,11.2vh)
2 lines, each line ≤ 8 Chinese characters	min(5.8vw,10.2vh)
2 lines, either line 9-12 Chinese characters	min(5.2vw,9.2vh)
3 lines or longer	rewrite the title first; if unavoidable, use min(4.6vw,8.2vh)

If the title crowds the image or body-text area, first compress the title copy, then reduce the font size; do not force it in by pushing the content below to the bottom.

3.2.2 · Minimum font size and font-weight ladder for Swiss-style presentations (required for Style B)

When Swiss style is used for screen presentations, small text cannot be written at the 10-12px of web annotations. Follow these minimums by default:

Text type	Minimum font size
Body paragraphs / main explanations	18px
card descriptions / lists / timeline notes / caption / figure captions	16px
meta / kicker / mono label / chart labels	14px

If the content does not fit, first cut the copy, split it into two pages, or switch to a more suitable Sxx layout; do not squeeze the font size down to 10/11/12/13px. Especially for Chinese decks, do not shrink body-sm, captions, or timeline labels just to fit three lines of explanation.

Font-size and font-weight ladder (core of Swiss style) — "the larger, the thinner; the smaller, the bolder" is not a sensory description, but a concrete mapping:

Font-size range	Recommended font weight	Typical scenario
≥ 8vw	200 (ExtraLight)	cover large text, giant KPI, h-statement
4-7.9vw	200-300	section titles (h-xl/h-xl-zh), large numbers
1.8-3.9vw	300-400	Medium heading, takeaway heading (≈1.8vw), medium numbers
1-1.7vw / 16-20px	400-500	Body paragraphs, card descriptions, explanatory text
13-15px (small text)	500-600	meta, kicker, corner badge, chart labels, caption emphasis

Hard rules:

• Within the same page, elements with smaller font sizes must have font weight ≥ elements with larger font sizes (it is not allowed for 16px body text to use 300 while a 1.8vw heading uses 500)
• Small text around 16px must not use weight 300 (too thin to be readable); minimum 400, recommended 500
• For emphasized text within large reversed-out headings on the cover/IkB, use italic + weight 300, do not use the accent color (blue on blue is invisible)

Component details (fonts, colors, grid, icons, callout, stat-card, etc.) are in references/components.md。

Step 4 · Self-check against the checklist

After generating, be sure to open references/checklist.md, and check item by item. It summarizesall the pitfalls encountered during real iteration, and all P0-level issues (emoji, images overflowing, heading line breaks, font role division) must pass.

For all formal presentation decks, first run the speaker mode validation; if the user has given a target duration, also pass in the number of minutes:

node <SKILL_ROOT>/scripts/validate-presenter-mode.mjs path/to/index.html
node <SKILL_ROOT>/scripts/validate-presenter-mode.mjs path/to/index.html --target-minutes 30
node <SKILL_ROOT>/scripts/check-presenter-runtime-sync.mjs

The first script will catch missing/duplicate page IDs, notes misaligned with pages, missing required fields or incorrect optional field types, a full time plan exceeding 90% of the budget, and missing timing, rehearsal, auto-advance, annotation, pre-talk check, and audience screen restore controls. The second script will catch speaker CSS / JS drift between the two template sets.

4.0.1 · Measure first, then change: overflow / whitespace / heading spacing

When a page overflows or looks extremely empty, do not first make large deletions or changes based on feel. First run:

node <SKILL_ROOT>/scripts/validate-swiss-deck.mjs path/to/index.html

Look at the measurement items in the validation output:

• M1 DOM/visual overflow: exactly how many px it overflows, and the lowest/highest problem elements
• M1 bottom whitespace: how many px of bottom whitespace, and what proportion is active content height
• M1 nav-safe: whether the lowest content enters the bottom pagination safe line
• M2 title gap: the actual distance between the heading and the next block of content

Correction ladder:

• 1-40px over: only fine-tune, move the content group up or tighten one gap/padding, do not delete content.
• 40-90px over: locally compress spacing or module height, still prioritizing keeping content.
• 90-160px over: slightly compress the heading or compress a paragraph of body text, and split the page if necessary.
• 160px+ over: only then consider changing the layout, merging modules, or deleting content.

After fixing, run the validator again. If M1 bottom whitespace becomes larger, it means the fix went too far; restore some spacing, enlarge the last block, or move the content group back down.

4.0 · Do not just look at the code: you must open the webpage for visual verification

Code can only prove that class names and structure exist, not that the layout is comfortable. After generating, you must open the webpage and look page by page:

1. At the same time, open the current template (golden source snapshot) or generated page, and the test PPT being iterated, and compare page by page.
2. Before taking screenshots, wait for the entrance animation to stabilize (about 1-2 seconds); do not mistake an intermediate animation state for a layout problem.
3. First look at the visuals: large heading font weight, spacing between heading and content, whether images align with body text, whether images/captions touch the bottom pagination component.
4. Then look at the code: confirm that the layout selected for the page matches the content shape, that a data-specific layout has not been used to explain concepts, and that optional components have not been piled up as decoration.
5. When comparing against the original reference template, go by actual page usage, not just CSS helper definitions; the large text on the original pages is actually mostly 200/300, so do not be misled by the 700/800/900 in the raw CSS.
6. If the page feels off, first determine whether the layout is wrong, a required component is missing, an optional component is overused, or it's a spacing/safe-area issue; don't just brute-force it by adding margin.

Style A · Digital magazine style must-check

1. Large headings must use a serif font— if it displays as sans-serif, 99% of the time it's because the Step 3.0 pre-check wasn't done,h-hero class is missing in template.html
2. In image grids, only use height:Nvh, not aspect-ratio(it will overflow)
3. Images must not be piled up at the bottom of the page— do not use align-self:end, use grid + align-items:start(see Step 3.2)
4. Images may only use standard ratios(16:10 / 4:3 / 3:2 / 1:1 / 16:9), do not copy the original image's weird ratio
5. Chinese large headings ≤ 5 characters and nowrap(avoid 1 character per line)
6. Use Lucide, not emoji
7. Headings use serif, body uses sans-serif, metadata uses monospace

Style B · Swiss International style must-check

1. Sans-serif throughout— the appearance of any serif font is wrong (check that font-family doesn't use --serif class variable)
2. Only one accent color— a single deck cannot have multiple highlight colors like IKB blue + lemon yellow + safety orange at the same time
3. No gradients / shadows / rounded corners allowed— all color blocks are right-angled and solid; any box-shadow / linear-gradient / border-radius > 0 must be cut (except rule horizontal lines)
4. Extreme font-size contrast— ratio of main heading to body text ≥ 8:1
5. Large font sizes must have dual-constraint height limits——font-size:min(Xvw, Yvh), using only vw will overflow on a standard 16:9 screen (learn from P15/P20/P22)
6. Large text font-weight 200(ExtraLight)— the larger the font size, the thinner; the soul of Swiss style;Prohibit 600/700/800 large text
7. Card fill types are mutually exclusive——card-ink / card-accent / card-fill / card-outlined four categoriescannot be mixed(prohibit "blue background + blue stroke", "gray background + stroke", etc.)
8. When multiple cards are side by side, use uniform styling— 3-12 cards use the same category (prefer card-fill gray background); when highlighting only one item, switch it individually to card-accent, andonly one is allowed
9. Right angles all the way— any border-radius is not allowed; for decoration use 8×8 right-angled small squares,do not use 9px circular dots
10. Icons use lucide, do not draw SVG yourself——<i data-lucide="name"></i> + lucide.createIcons(), choose an angular style (avoid round and chubby)
11. Timeline alignment— axis column fixed at 12px + dot absolute positioning,do notuse grid justify-self(it will misalign with the dashed line)
12. Section-level heading to content spacing ≥ 9vh— avoid crowding (learn from P15/P16)
13. One semantic motion recipe per page— not a uniform fade-up; numbers scale bounce in, bar scaleY pulls up, SVG stroke draws lines, node sequences light up, etc.;Prohibitall pages using the same generic recipe
14. playSlide entry reveal container——[data-anim] The container first forces opacity:1, then within the recipe use motion {opacity:[0,1]} overlay, otherwise some pages will "disappear"
15. ESC index page visibility——cloned slides must have a CSS override so that [data-anim] is opacity:1 in the thumbnail
16. Helvetica/Inter fallback Chinese font——Windows users don't have "PingFang", so must fall back to "Microsoft YaHei UI", "Noto Sans SC"
17. Font weight conventions:large text 200 / body 300 / t-cat SemiBold 600 / t-meta mono uppercase
18. Keep low-power shortcuts——the bottom right corner must show B 静态;press B to toggle body.low-power, stopping WebGL/ASCII canvas RAF and Motion entrance animations
19. Decorative elements strictly within the grid——bars matrix, dot matrix, ring-mat must not touch the edges or overflow the page
20. Reserve nav space at the bottom content——nav is at ~97vh, content should not end past 93vh (lesson learned from P22 KPI large text overflowing the bottom)
21. Image containers have square corners and no shadow——.frame-img do not add border-radius / box-shadow; boundaries use only hairline
22. S15/S16/S22 images consistent within the same group——images in the same group have uniform aspect ratio, height, margins, and line thickness; infographics/UI images add .fit-contain
23. Component roles must be correct——S15/S16 image cells need caption information anchors; S22's KPI/description is required; data-specific layouts must have real data, cannot be filled in with copy alone
24. Distinguish general/non-general layouts——S03/S08/S11/S19 are more general; S06/S07/S20/S21/S22 are data/case-specific; S14/S15/S17 are structure-specific

Step 5 · Local preview

Just open it directly in the browser index.html is fine. On macOS:

open "项目/XXX/ppt/index.html"

No local server needed. Images use relative paths images/xxx.png。

During preview, don't just look at the normal page. Press P to enter presenter mode, allow the browser to open the audience window, and test at least once: paging forward/back, selecting a page in the embedded grid and returning to preview, first/last page, restarting from the last page, timer start/pause/reset, rehearsal recording, auto-advance pause/resume, laser pointer, circle draw, black/white screen, freeze, settings components, pre-talk check, notes saving, state changes after closing the audience window, and whether "reopen audience screen" can restore to the current page.

Step 6 · Iterate

Modify based on user feedback——the template's CSS is already highly parameterized, 90% of adjustments are changing inline styles (font size font-size:Xvw / height height:Yvh / spacing gap:Zvh）。

---

Resource file guide

guizang-ppt-skill/
├── SKILL.md                  ← 你正在读
├── assets/
│   ├── template.html         ← 风格 A · 电子杂志风模板（种子文件）
│   ├── template-swiss.html   ← 风格 B · 瑞士国际主义风模板（种子文件）
│   ├── screenshot-backgrounds/ ← 截图美化内置背景(WebP):style-a 5 套 / style-b 4 套
│   └── motion.min.js         ← Motion One 本地副本（离线兜底,约 64KB,共用）
├── scripts/
│   ├── validate-swiss-deck.mjs ← 风格 B 静态校验:登记版式、图片槽位、SVG 文本、标题对齐
│   └── validate-presenter-mode.mjs ← 两种风格共用:页面 ID、演讲备注、时长和演讲者运行时校验
└── references/
    ├── components.md         ← 组件手册（字体、色、网格、图标、callout、stat、pipeline、动效... 风格 A 适用）
    ├── layouts.md            ← 风格 A · 10 种页面布局骨架（可直接粘贴,含动效标记）
    ├── swiss-layout-lock.md  ← 风格 B · 原始 22P 版式锁,正文页必须按这里登记
    ├── layouts-swiss.md      ← 风格 B · 原始 22P 骨架说明 + 少量明确标注的实验区
    ├── swiss-map-component.md ← 风格 B · S08 地图扩展组件(MapLibre 点位/连线/卡片/控制)
    ├── themes.md             ← 风格 A · 5 套主题色预设（只能选不能自定义）
    ├── themes-swiss.md       ← 风格 B · 4 套瑞士风主题色预设（IKB / 柠檬黄 / 柠檬绿 / 安全橙）
    ├── image-prompts.md      ← GPT-M 2.0 配图类型、比例和基础提示词
    ├── screenshot-framing.md ← CleanShot X 式截图适配语义 + 内置背景资产映射
    ├── presenter-mode.md     ← 演讲者 UI、AI 备注结构、观众屏同步与恢复契约
    └── checklist.md          ← 质量检查清单（P0/P1/P2/P3 分级）

Suggested loading order：

1. First read through SKILL.md(this file) to understand the whole
2. Step 1 Requirements clarificationFirst questionFirst decide whether it's style A or B, then:
   • Style A: read themes.md to help the user choose a theme color set
   • Style B: read themes-swiss.md to help the user choose a theme color set
3. Before starting, Read the corresponding template's <style> block——this is the only source of class names, missing classes will break the entire page's styles
   • Style A → assets/template.html
   • Style B → assets/template-swiss.html
4. Read the corresponding layouts file to pick a layout:
   • Style A → layouts.md(at the top there is a Pre-flight class name list, theme rhythm plan, animation recipe decision tree)
   • Style B → First read swiss-layout-lock.md, then read layouts-swiss.md; body pages must be chosen from S01-S22, and each page should have data-layout
5. If style B needs a map of places, routes, people's residences, or city relationships, read swiss-map-component.md
6. If generating images in Codex, read image-prompts.md to choose the image type, aspect ratio, and base prompt; if it is the user's original screenshot, first read screenshot-framing.md, prioritize using the built-in background assets of assets/screenshot-backgrounds/ 's built-in background assets
7. For detail adjustments, read components.md to look up components (including the Motion animation system chapter, mainly serving style A; style B's component details are in the layouts-swiss.md appendix)
8. For a formal presentation, first read presenter-mode.md, generate stable page IDs and SPEAKER_NOTES
9. After generation, first run validate-presenter-mode.mjs; for style B, then run validate-swiss-deck.mjs, and finally read checklist.md for self-check

Animation-related: the template has already embedded Motion One's loading and recipe logic into the bottom module script. You do not need to modify the JS, just follow the skeleton in layouts.md / layouts-swiss.md and add data-anim / data-animate in the HTML. Offline demos rely on assets/motion.min.js, and when the network is disconnected it automatically degrades to "no animation but content readable." The style B template must preserve the B key low-power mode: after switching, stop the WebGL/ASCII canvas RAF, cancel the running Web Animations, and directly reveal the current page content to its static final state.

Core Design Principles (Philosophy)

Style A · Electronic Magazine Style (Summary of 5 Rounds of Iteration)

Violating any one of these will make the magazine feel collapse.

1. Restraint over showmanship — the WebGL background only shows through on the hero page, and is almost invisible on ordinary pages
2. Structure over decoration — no shadows, no floating cards, no padding boxes; all information relies onlarge font sizes + font contrast + grid whitespace
3. Content hierarchy is defined jointly by font size and typeface — largest serif = main title, medium serif = subtitle, large sans-serif = lead, small sans-serif = body, monospace = metadata
4. Images are first-class citizens — images are only cropped at the bottom, ensuring the top and left and right are complete; the grid uses height:Nvh to fix it, do not use aspect-ratio to prop it up
5. Rhythm depends on hero pages — hero and non-hero alternate, so it does not tire the eyes
6. Unified terminology — Skills are Skills, do not mix Chinese and English translations

Style B · Swiss International Style

Violating any one of these instantly drops the visuals from Swiss to PowerPoint.

1. Single anchor color — one deck uses only one accent; multi-color highlight collages are not allowed
2. Extreme font size contrast — the ratio between main title and body text is ≥ 8:1; KPI must be a "Data Hero" (18-22% of screen width)
3. Sans-serif only, this one house — Inter / Helvetica / Noto Sans SC; any serif is wrong
4. Right angles, solid colors — gradients / shadows / rounded corners are not allowed (except rule horizontal lines)
5. Grid above all — all elements snap to a 12-col grid, left-aligned + generous whitespace for asymmetrical aesthetics
6. Hairline is a scalpel — a 1px ultra-thin divider is enough; do not bold it, do not add shadows
7. Dot-matrix decoration only shows through on the hero page — body pages keep a clean solid background

Reference works

The two styles of this skill respectively reference:

Style A · Electronic magazine style:

• 歸藏 "One-Person Company: The Organization Folded by AI" talk (2026-04-22, 27 pages)
• Monocle magazine's layout
• The demo in YC president Garry Tan's blog post "Thin Harness, Fat Skills"

Style B · Swiss International Style:

• Massimo Vignelli's NYC Subway / Unimark system
• Helvetica Forever 's typographic design language
• Josef Müller-Brockmann's classic work on grid systems
• Contemporary design: Acne Studios / Off-White / IKEA / Beck Design

You can treat them as style anchors.