SuperAPI AI Directory
Partner中文AI newsFavorites
Skillssn-ppt-dazzle

sn-ppt-dazzle

Design & creation

View repository

Updated 10-15 16:51

About this skill

sn-ppt-dazzle: single-HTML dazzling presentation deck

What you need to deliver is not a "slide deck", but adynamic visual performancestaged in the browser: a continuously running dynamic background, entrance choreography for each page, transition effects between pages, keyboard interactivity—while also having rigorous typography, authentic content, and zero console errors.

0. Entry / Story input contract (highest priority)

This Skill is not a user request entry point, and does not directly accept a bare query or attachments to create a new task. It only accepts sn-ppt-entry the absolute DECK_DIRpassed in, and it must already exist:

  • <DECK_DIR>/task_pack.json；
  • <DECK_DIR>/info_pack.json；
  • <DECK_DIR>/outline.md；
  • task_pack.choices.output == "dynamic_html", or the old task's ppt_mode == "dazzle"。

When any condition is not met, stop and return sn-ppt-entry to fill it in; do not create a new deck directory on your own, and do not bypass sn-ppt-storyfrom the query. Both at start and on resume, re-readread_filethe current outline.mdon disk; do not usesn-ppt-story the write_file return content or the outline in the conversation context;outline.mdis Dazzle's only content input and is fixed:

  • the final page count, page order, and titles;
  • each page's core conclusion, content basis, on-screen content boundaries, and preceding/following relationships;
  • content the user explicitly keeps, deletes, or modifies.

Dazzle still decides the style family, dynamic background, layout, assets, animation, and implementation details according to the six stages later in this document, but must not merge, split, add, remove, or reorder outline pages, must not change the meaning of titles and core conclusions, must not restore content the user deleted, and must not conduct its own Research or fabricate facts. When facts are insufficient, stop the relevant pages and return to Entry / Story.

DECK_DIR can only take task_pack.deck_dir 's absolute path, and all task artifacts are written to that directory. The current Skill directory is read-only and recorded as SKILL_ROOT; references and rendering scripts are only read from SKILL_ROOT .

1. Artifacts and boundaries

  • Final artifact:<DECK_DIR>/deck.html(if generated images are used, additionally <DECK_DIR>/assets/; images are still referenced in the HTML using the relative path assets/img_NN.png ; when no generated images are used, deck.html is the only presentation deliverable).
  • Canvas 1280×720（16:9）, fixed design canvas + JS proportional scaling to fit the screen (see §4 contract).
  • CSS / JS are all inlined in <style> / <script>. Allowed CDN:Three.js r128、GSAP、ECharts、D3、Google Fonts。External image URLs are prohibited(images can only come from local files under assets/).
  • DECK_DIR Files withinplan.md(your planning),deck.html、assets/(optional),shots/(rendered screenshot output).

Only sync at existing stage boundaries task_pack.json, without changing the execution content of subsequent stages:

  • Enter stage 1:current_stage="output.dynamic_html.plan"、status="generating"；plan.md After completion, write the absolute path to state.artifacts.plan。
  • Enter stage 3:current_stage="output.dynamic_html.build"; in stage 4, each time a page is completed and visually confirmed, append the page number to state.artifacts.dynamic_pages_completed。
  • Stage 6 complete: write deck.html、shots/、shots/render.json and the available shots/contact_sheet.png 's absolute paths respectively to state.artifacts.deck_html、shots、 render_manifest、contact_sheet; add dynamic_html to completed_stages. When all pages pass, write current_stage="complete"、status="completed"; when there are still faithfully reported defects, write status="partial" and last_error, keeping all usable artifacts.

2. Workflow (six stages)

You must render before you look: reading code alone does not count as self-inspection. Rendering is always done uniformly by running the skill's built-in script with bash:

python "$SKILL_ROOT/scripts/render_deck.py" "$DECK_DIR/deck.html" "$DECK_DIR/shots/" --page N  # 渲染第 N 页
python "$SKILL_ROOT/scripts/render_deck.py" "$DECK_DIR/deck.html" "$DECK_DIR/shots/" --all     # 全部页 + contact_sheet.png

On success, stdout has one PNG path per line (warnings are printed before the path with the [console]/[static]/[blank]/[nav] prefix); rendering metadata is written to $DECK_DIR/shots/render.json(console_errors / static_pages / blank_pages / page count / navigation method). After taking screenshots, use vision_analyze to view them.

Stage 0 — Read outline.md and set the tone

The first step must be to fully readread_filethe current outline.md; you must not generate plan.md or deck.html first. task_pack.request.query Only supplements the scenario and the user's explicit style preferences; it cannot override the content decisions of the outline:

  • Page count, page order, titles, and each page's core conclusion: taken strictly from consecutive ## 第 N 页; you must no longer decide on your own based on 8–12 pages.
  • Language, audience, and scenario: prefer the outline; when the outline is not explicit, read task_pack.params andtask_pack.request.query; you must not change the outline content.
  • First determine the level of formality of the usage scenario(§3 Scenario Adaptation), and based on that define the candidate style domain and the animation density tier.
  • The style must be named explicitly: read $SKILL_ROOT/references/style-families.md, and select a family that fits both the theme and the scenario (if the outline or task_pack.request.query carries a style inclination, then within that direction settle on a specific family).
  • Read $SKILL_ROOT/references/fancy-cookbook.md, and pick 2–3 technique recipes for this deck (choose one for the global background, one for entrance choreography, and transition/easter eggs as needed).
  • Define a "signature visual": every deck should have one signature technique worthy of its subject matter.Choose the technique that best fits this subject — CSS/SVG/Canvas-2D/shader/code 3D are on equal footing; if it is creative and bound to the subject, it is full marks for fancy(pure CSS geometry and Canvas-2D concept visualization can also be stunning).fancy ≠ 3D, and the judgment is based on "has ideas vs mediocre routine", not on whether 3D was used.Distinguish the two uses of 3D/shader：① Dynamic background layer(shader flow field / node sphere / Fresnel glow sphere / particle flow / 3D atmosphere layer) — by default the background should just be "alive" (continuous subtle motion); this kind of background layercan be used for any subject, and is especially a plus for tech-abstract data-network types, and does not count as "forcing in 3D", so it is encouraged; ② Immersive roaming scene(building the whole deck in a navigable 3D world + page-turn camera movement) — this is only given to subjects with a spatial subject (architecture, celestial bodies, terrain and landforms, etc.; molecular crystals and three-dimensional physical products also count).Do not make the background a static dead plane just to "avoid 3D". Both collapses must be prevented: do not default to "canvas particle background + editorial layout" regardless of subject, and do not default to "immersive roaming + page-turn camera flip" either — both are routines.

Stage 1 — Write plan.md

The second step must be to write plan.md; you must not generate deck.html first. Write the complete plan in one write_file, including:

  1. Scenario judgment: what scenario this deck is for, the formality tier (formal/free/subject matter), the animation density tier, and why this family was chosen — write the adaptation rationale clearly.
  2. Design system: family name; exact palette (--bg / --ink / --accent / --accent-2 hex); display + body fonts (including Chinese font fallback); global background layer approach (CSS/Canvas-2D procedural texture / particle flow field / shader noise / code-built 3D scene / multiple scenes per page, choose one based on the signature visual—don't reflexively default to one particular option); general transition approach.

2b. Signature visual (one required line): this deck's signature technique + why it fits the subject/scene; if 3D/immersive/shader is chosen, specify what it's built with.Once decided, it must actually be built(see §5 Signature Delivery). 3. Page order table：and outline.md pages correspond one-to-one page by page, one line per page NN | 页型 | 一句话内容 | 本页 fancy 手法 | 版面骨架; NN, order, and one-sentence conclusion must follow the outline. Page types are chosen from: cover / agenda / viewpoint / data / comparison / process / case / architecture / timeline / summary; adjacent pages must not repeat the same page type; fancy techniques must not be duplicated across more than 2 pages.In the "Layout Skeleton" column, first think clearly about how this page is divided, where the main visual goes, and who gets the remaining space(e.g. "left narrative right large image / centered single hero / four equal cards in a row / full-screen scene / title on top with two-column comparison below")—the number of zones is unlimited, but the whitespace must be an intentional composition, not the leftover scraps after layout (see §7 Layout and Whitespace); for parallel items, plan ahead how to align them at equal height. Think the layout through in the plan, and the first draft will need less rework. 4. Asset list(if needed): judge page by page whether there is a "photography hard requirement" (§6); for those that need it, write out the image generation prompt draft and its purpose.Decide on the whole group for parallel objects in the same group (N cards / a row of similar items): list all N members, and choose "all real images" or "all code-drawn" for the whole group—if choosing real images, list one line for each of the N; never write 4 cards in the page order table but list only 2 images in the list (see §6).

Planning self-check: do the page count, page order, titles, core conclusions, and evidence correspond page by page to the current outline? Is the palette exact hex? Has it slipped back to warm beige/cream background? Do the page types vary? Does the content use only real subjects and real data already supported by the outline, with no placeholder words or newly added facts?

Stage 2 — Generate assets (only when real images are truly needed)

Generate images according to the discipline in §6: generate → vision_analyze check (is the content correct / does the color tone match / are there text watermarks) → if unqualified, revise the prompt and regenerate,never force it into use; record the exact paths in plan.md. Decks without a photography hard requirement skip this stage (most decks should skip it).

Stage 3 — Write the global skeleton shell (write only the skeleton, not page content)

Write in one write_filefully runnable but with empty pagesthe $DECK_DIR/deck.html skeleton (for the structural contract see §4):

  • head（Google Fonts / CDN）→ :root design tokens → all base CSS (.deck/.slide/.active/navigation UI/general keyframes library/general transitions) → #bg-layer global dynamic background (fully implemented and running, not a placeholder) → N empty <section class="slide">(containing only <!-- SLIDE NN: 页型 + 一句话 --> comments,write no real content; the cover page may first contain minimal title text to ensure smoke has content to view, while all other pages remain empty) → navigation controller JS → page number + progress bar.

Hard discipline: in this skeleton write_file, all sections except the cover must be empty (comments only). Do not fill in multi-page content all at once during the skeleton stage—that would land an entire batch of pages at the same time without per-page verification, letting errors accumulate across pages and making them harder to clean up later, and it also throws away all the value of "render is verification" page by page.

Then smoke verification:render --page 1 + look at the image—the cover is visible, page numbers/progress bar are present, the background layer is animating (watch stdout's [static] and [console]), zero errors. If the skeleton does not pass, fix the skeleton first, then move on to page-by-page filling.

Stage 4 — Page-by-page filling (one page per loop, do not skip steps)

In page orderone page at a time, complete a full "fill → render → look at the image" mini-loop for each page before moving to the next page:

  1. edit Replacethat one page'sempty section with complete content (page-local styles can go inside the section <style> or be written into the global style with the #sNN prefix; page-local JS must always be registered to window.slideInits[N], see §4).One edit fills only one page, do not pour multi-page content into a single edit.
  2. render --page N → vision_analyze Take a screenshot of that page and self-check against the §5 checklist.Render first, then look is a hard requirement—continuing to fill the next page without rendering is not allowed.
  3. If there is a hard defect → minimal fix → re-render and re-check,at most 3 rounds per page. Pages that pass are not looked at again; move on to the next page.

Why insist on page by page: each page is individually looked at and confirmed free of overflow/occlusion/errors at the moment it lands, so problems are found and fixed when they are cheapest; this is also the core rhythm this skill should teach the model—incremental building + immediate verification, rather than writing it all at once and betting it is correct.

Stage 5 — Global review

render --all → first look at contact_sheet.png one image to scan the whole thing: whether the style has drifted, whether adjacent pages are too similar, page number continuity, whether the full background set is consistent; then check render.json:console_errors must be empty; check static_pages page by page to see whether each is "static for a reason" (§5). If a problem is found: for a single-page problem, edit that section and look only at that page's large image;only cross-page/systemic problems should change :root tokens or the shared skeleton—but tokens / shared CSS affect all pages (including earlier pages that already passed during the page-by-page stage and are no longer looked at), so after changing them you must render --all re-scan all pages to confirm you have not knocked other pages off course; never look only at the original problem page. Global layout token adjustments are best done at this step (this is already render --all). If there is capacity left, at this point you can add page-level dedicated transitions/easter eggs to key pages as enhancements.

Stage 6 — Wrap-up

Before wrapping up, the Stage ⑤ global review must already have been done (render --all + look at contact_sheet), andafter the last edit it must have been rendered and verified again—wrapping up without verification is not allowed. Then give a short text summary: page count, style family, the 1–2 fanciest points you are most proud of,truthfully report remaining issues(which page still has what that was not fixed).Falsely reporting "all passed" when there are actually hard defects = the entire output is invalid. Clichéd closing pages like "Thanks for listening/Thanks for watching" are forbidden.

3. Scenario adaptation: the boundaries of fancy

fancy is about maxing out execution quality and visual impact, not about going out of bounds stylistically. Giving a graduation defense cyberpunk neon, and giving a product launch a gray-and-white template, is the same kind of failure. Stage 0 first clearly judges the scene's level of solemnity:

Tier Typical scenarios Candidate style domain Animation density
Solemn tier Academic defenses, government/enterprise reports, medical/financial/legal reports Steady systems such as dark business, editorial magazine, data dashboard (No Swiss minimalism/International Typographic Style） Presentation-grade: restrained, deep background micro-animations + refined entrance choreography + data animations (count-up / draw-in); once the page settles, a static frame is the norm; no neon glitch, particle bombardment, or strongly distracting effects
Free tier Product launches, creative pitches, tech talks, personal work dazzle cluster unleashed: cyber, immersive 3D, maximalism, Memphis…… Show-grade: cross-page transition effects, particles / 3D / shader, dramatic choreography done without holding back
Subject tier Cultural tourism, children's education, culture and arts, food Follow the subject's temperament (culture→Eastern aesthetics, children→bright illustrations……) Between the two tiers, with motion forms fitting the subject's metaphor
  • Solemn tier's leverage points: typographic tension, data visualization maxed out (real data + animated entrances), deep background layering (slow gradient flows, low-key geometric micro-motion, restrained shader noise), clean and crisp transitions.Restraint ≠ low ambition——it still needs signature memorable points, achieved with refinement rather than noise; never use neon/glitch/cyber/3D spectacle.
  • The subject tier chooses technology according to the subject：Subjects with a spatial subject(architecture, celestial bodies, terrain and landforms, etc.) can have the space built in code as a 3D roaming scene"performed out" (such as Forbidden City roaming-grade);other subjectsshould not force-fit a 3D roaming scene——butlively 3D/shader background layers (shader flow fields / node spheres / particle streams, etc.) should be used when needed, and the foreground should choose the most fitting CSS/SVG/Canvas-2D expression for the subject; the background should not be made into a static dead plane.
  • plan.md must state the tier and the reason; prioritize the scene in outline, and only when it is not explicit use task_pack.request.query the scene words in ("defense" "roadshow" "group meeting") to judge.

4. deck architecture contract (the skeleton must satisfy)

<body>
  <div id="bg-layer"></div>            ← 全局动态背景层（canvas/Three.js/CSS 动画）
  <div class="stage">                  ← 居中容器，position:fixed; inset:0; flex 居中
    <div class="deck" id="deck">       ← 固定 1280×720 设计画布，overflow:hidden
      <section class="slide active" data-slide="1">…</section>
      <section class="slide" data-slide="2">…</section>
      …
      <div class="hud">页码 + 进度条</div>
    </div>
  </div>
</body>
  1. design tokens: all colors / fonts / spacing / font-size scale are defined in :root , and the whole document only references them via var() , with no scattered bare hex / bare values.
  • Colors and fonts:--bg/--ink/--accent/--accent-2/--font-display/--font-body。
  • layout tokens (defined during the skeleton phase and shared across the whole page → change one place and the whole page takes effect; this is the foundation of "fix the root cause, not whack-a-mole page by page"): safe margins --safe-x/--safe-y(e.g., 64/56px, content does not cross these margins, HUD/page numbers may hug the edge); systematic spacing steps --gap-s/-m/-l(e.g., 12/24/48, whitespace between elements is taken only from this set, don't casually write scattered values, only then does whitespace have rhythm); minimum readable font size --fs-min(about 20–22px, body text/annotations are never shrunk below it to cram in content——better to split pages/cut content). For huge text use clamp(min, Nvw, max) Balance drama with upper bounds and prevent out-of-bounds.These layout tokens must be finalized and kept stable during the skeleton phase, and all page-by-page filling works within their constraints; if tokens must be changed midway, it will affect all pages (including pages already completed), and a full re-validation must be done according to the §5 repair discipline.
  1. Fixed canvas + proportional scaling(fundamentally solves overflow/cropping/aspect distortion):.deck{position:relative;width:1280px;height:720px;overflow:hidden}, all content is laid out at 1280×720 using px layout and fixed font sizes; JS fitDeck() scales the deck by Math.min(innerWidth/1280, innerHeight/720) and listens for resize.Never mix units(most importantly, do not size the deck in vh and set font sizes in vw—on letterboxed screens the fonts will blow out the canvas).
  2. Show only one page at a time：.slide{position:absolute;inset:0;opacity:0;visibility:hidden;pointer-events:none}，.slide.active with all three enabled.Non-current pages must be completely invisible(switching only opacity without switching visibility will make them bleed through each other); at any moment there is exactly one active page; when adding custom styles to a single pagenever change position(breaking out of the stacking will collapse that page to 0 height and cause a black canvas).
  3. Navigation controller(written completely during the skeleton phase):
  • keyboard ArrowRight/Left, Space, PageDown/Up to turn pages;window.addEventListener('load', () => window.focus()) steal focus (the prerequisite for keyboard usability inside an iframe).
  • When turning pages, switch .active to the target page (the rendering script identifies the current page by the .active class; this is a hard contract), update the page number and progress bar, call window.slideInits[N]on the target page (see item 6), and dispatch the slidechange event.
  • Must support direct navigation via URL parameter：new URLSearchParams(location.search).get('slide') → on initialization, jump directly to page N (1-based). The rendering script relies on this for O(1) single-page rendering; if missing, it will significantly slow down self-checks and emit a warning to stderr.
  1. Global background layer：#bg-layer{position:fixed;inset:0;z-index:0;pointer-events:none}, deck container z-index:1. Background animationfully implemented during the skeleton phase; during review, only parameter tuning is allowed (color/density/speed), do not rewrite. Attach event listeners to window(the background layer is not interactive), and use window.innerWidth/Height + resize listener for sizing.

5b. Background-foreground readability (mandatory for full-screen 3D / heavily animated backgrounds)：Do not rely on globally darkening the background to save the body text—it will also kill the 3D on the cover/section pages. Instead use:

  • Tier by page type: cover/section pages let the background run free; content/data pages make the background yield locally—reduce that page's particles/highlights (fine dust opacity→~.25, weakened glow), and do not place the 3D subject in the same quadrant as the foreground diagram.
  • Foreground diagrams carry their own backing panel(pages containing SVG diagrams / canvas / dense small text / data tables): preferredsoft-edged radial scrim——radial-gradient(70% 70% at 50% 50%, rgba(<bg>,.85), rgba(<bg>,.55) 60%, transparent)(use the same color as --bg ), holding up the center with fading edges, still letting the 3D show through from all around, without cutting a hard frame; for dense pages usecards + backdrop-filter:blur(6px)。Never attach bare <svg><g stroke> directly to .slide(the background will bleed through the gaps in the strokes and swallow the body text; see fancy-cookbook “background-foreground separation scrim” for details).
  • Stroke-opacity stroke-opacity ≥ .5, line width ≥ 1.2px; use light-colored text/thin lines only where a scrim already exists.
  1. Per-slide JS lazy registration: all in-page scripts must be written as window.slideInits = window.slideInits || {}; slideInits[N] = () => {…}, called by the navigation controller when that page is activated (with idempotency protection for those already initialized).Top-level immediately-executed code must not touch the DOM of other pages (or empty sections not yet populated)— this is the key to rendering without errors during the empty-skeleton phase and to populating page by page without stepping on each other.
  • At the top of the skeleton's <head> top (before any in-page <script> , a line must be pre-placed: window.slideInits = window.slideInits || {};— this guarantees it already exists when any in-page script executes, eradicating the timing pitfall of "in-page script executing before the main controller → Cannot set properties of undefined"; and goto()/?slide=N direct jumps must be called only after all slideInits[N] registrations.
  1. Entrance Animation Contract(the official solution to ending the contradiction between animations and screenshot self-checks): the total entrance choreography duration per page is ≤2s, and all entrance animations must animation-fill-mode: forwards(or both),final state = complete content(the rendering script takes a screenshot at ~2.6s, and what it captures is the final state). Continuous animations (background particles, breathing glow effects, HUD scrolling) are not subject to the 2s limit. Stopping at boot/loading/unfinished typewriter states is prohibited.
  2. General Transitionsbelong to the navigation controller and are written during the skeleton phase: class-driven (.slide.leaving / .slide.active + transition/keyframes), with a dramatic choreography provided by default (a combination of displacement + opacity + blur/clip, with cubic-bezier easing). Page-specific transitions (particle reconstruction, shader wipes, etc.) are optional enhancements for the review phase.
  3. Performance Budget: animations only move transform / opacity / filter (not layout properties); the total number of canvas particles and Three.js draw calls must be restrained (see the particle parameter table in §8); continuous animations use requestAnimationFrame and need not be paused when the page is not visible (rendering checks depend on dynamic visibility).

5. Rendering Self-Check Checklist

For each page render --page N + vision_analyze check against:

Mandatory — every page must meet this standard; the bar is "worthy of the fancy first objective," not "stop once it barely passes." Items 1–12 below are the "unreadable / incomprehensible" hard problems, to be zeroed out first:

  1. Overflow / Clipping — content crosses the 1280×720 canvas or container edge; giant text is cut in half; text bursts out of fixed small boxes.overflow:hidden willsilently clip without revealing white edges— don't assume that because there's no bleed everything is fine; proactively check whether the footer/page number/first and last lines of body text/chart axis labels have been cut off.
  2. Occlusion / Overlap — decorative elements / large numbers / floating layers cover the body text;SVG/Canvas internal decorative lines, glows, and connecting lines are drawn on top of the text(a draw-order problem: text must be drawn last, or given a stroke/backing plate to support it, see §7 item 6); negative letter-spacing causes glyphs to stick together (especially for large Chinese headings).
  3. Placeholder Residue / Empty Shells — empty chart containers, KPIs all 0, headers with no data rows, axes with no curves.
  4. Broken Images / Broken Charts — img / canvas / Three.js / ECharts not actually rendered (black blocks, blank areas).
  5. Chinese Tofu Blocks — fonts not loaded (Chinese must be imported via Google Fonts and included in every font-family chain that displays Chinese).
  6. Insufficient Contrast — text is illegible on its backgroundor on the illustration / lines / gradient it overlaps; dark styles must likewise ensure readability.
  7. Palette out of bounds—colors from outside the palette intrude (ECharts default colors, generated images' colors drift without harmonization).
  8. console error ≠ 0—check stdout's [console] lines and render.json; JS errors often mean all subsequent animations/page turns are broken.
  9. Entrance animation hasn't reached its final state—text in the screenshot is semi-transparent / mid-displacement (indicating animation >2s or missing fill-mode: forwards).
  10. Grid pattern background—appearance of graph paper / blueprint grid / perspective grid floor (horizon grid) / regular dot matrix / Three.js GridHelper as the background,all count as hard defects and must be removed(see §7 item 10).
  11. Foreground laid bare over dynamic background—content pages containing SVG diagrams / densely annotated small text / data tables, where the foreground lacks a scrim soft backing plate or backdrop-filter card and floats directly on a 3D / particle background, making the body text or diagrams illegible,counts as a hard defect. For the fix see §4 item 5b: give the foreground a soft-edged radial scrim or card backing plate + reduce that page's background density,do not globally darken the background。
  12. Mixing image sources within the same group—within a group of parallel similar objects (a group of foods / local products / exhibits / people…), some use real generated images and some use SVG code drawings, breaking the image-text style consistency,counts as a hard defect(see §6: unify the whole group; fill in missing images with generation or convert the whole group to code).

Signature deliverable (hard discipline): the signature visual defined in plan.md item 2b must be in the decktruly implemented。it is strictly forbidden to downgrade it as filler—if you specified "code 3D scene / immersive_3d / immersive", the deck must genuinely have a Three.js 3D scene (geometry + lighting + camera motion); faking "immersion" with 2D canvas particles is unacceptable; either build it up into real 3D, or honestly change the plan to the mode you actually made (do not misreport).When using 3D as the signature, self-check must examine "can the 3D subject itself be recognized as what it is"(not just looking at the 2D overlay)—a dark background + fog easily blurs the 3D subject into a black blob with all content carried by the 2D layer, which means the signature exists in name only; if blurred, add rim light / brighten / reduce fog / change camera angle.

[static] is a signal, not a hard defect: stdout showing [static] page N means that page has no visible motion within the sampling window. Ask yourself: is thisa conscious design choice(a data-dense page in the solemn tier, a quiet page in the rhythm), or laziness? If it is quiet for a reason → ignore and continue; if you cannot state a reason → add appropriate motion per the page's density tier (subtle background motion / data animation),not mindlessly piling on particles。

Layout hygiene (equally mandatory, don't skip it as a "soft issue"): whitespace, alignment, hierarchy, letter-spacing must be fixed to the same standard as the out-of-bounds/occlusion above—

  • Unbalanced whitespace: margins leaking into unexpected dead whitespace on one side / one corner (whitespace with no explainable reason is a bug); content pinned to the top with the bottom collapsing empty; parallel columns / cards of unequal height creating jagged whitespace. Fix per §7 "Layout and Whitespace": either distribute margins evenly or intentionally cluster them; align parallel items to a common baseline / equal height.
  • Misalignment: elements on the same page are not aligned to a common grid / baseline; mixing centered and left alignment.
  • Confused hierarchy: Visual weight lacks hierarchy; what should stand out doesn't stand out.
  • Letter spacing: Chinese large titles have negative letter spacing causing characters to stick together, or all-caps small labels should be loosened but aren't.

Only purely subjective marginal optimizations (a bit more breathing room somewhere would be more comfortable, a certain easing a bit smoother) count as "polish if there's budget left". Treating layout hygiene as a soft, skippable issue is precisely the main reason a deck looks "AI-sloppy"—it matters just as much as legibility.

Deck-level self-review (during global review)：

  • Signature visual ambition: Does the signature visual match the subject matter, or is it bland and clichéd?Both clichés count as failing: Mindless "particle background + editorial typography", or forcing "immersive roaming + camera flips" regardless of subject matter. Creative use of 2D/CSS = full marks; the key is choosing technology that fits the subject.Also check whether the background is "alive"—degenerating into a purely static gradient loses points (unless the foreground carries continuous motion, like an extremely dense collage); a dynamic 3D/shader background layer suits any subject matter, so don't be afraid to use it just because it's "non-spatial".
  • The whole deck should have at least 2–3 high-impact memorable pages(a dramatic cover, a stunning data page, an unexpected transition...); quiet pages are allowed to create rhythm—every page a climax = no climax; style / color scheme / typography must be consistent throughout with no drift.

Fix discipline: Each page gets at most 3 rounds of edit→render→view; each round only makes the minimal change that eliminates the problem;it is forbidden to trade "deleting animations / backgrounds / effects" for passing the check—fixing is fixing bugs, not downgrading; if an effect truly must be removed, the reason must be explained in the final summary; if remnants remain after 3 rounds, keep the best version and record it faithfully.When the same flaw recurs across multiple pages (systematically off in whitespace / alignment / letter spacing / spacing), change :root the token or shared skeleton—the root cause—rather than whack-a-mole editing page by page—this fixes accurately and saves rework and context.But always remember the blast radius of shared tokens / CSS is global, affecting all pages (including earlier pages that already passed and won't be revisited): during Phase 4 page-by-page filling, prefer using #sNN in-page overrides to dolocalfixes; don't touch shared tokens because of a single page; if it is truly systemic and tokens must be changed,after the change you must render --all re-verify whether previously passed pages have been thrown off(don't just look at the current page and sign off)—such global changes are best saved for the Phase 5 global review together (which already does render --all). The safest approach is to finalize the layout tokens during the Phase 3 skeleton stage, so page-by-page filling works within fixed constraints and there's no need to change them midway at all.

6. Images and image generation (when image_generate is available)

Default to code-drawn. Charts / data visualizations / abstract concepts / geometric decorations / icons / UI elementsmust not use generated images—these are drawn with SVG / Canvas / CSS, which is this skill's signature strength. Generated images are forscenarios that need real photos: real objects, natural scenery, food, etc.Master artworks and real people's portraits especially must use generated images; it is strictly forbidden to imitate them with SVG/CSS code——Code hard-drawing a photorealistic human face / a famous painting is bound to be distorted and fall apart. Whether to use them, and how many to use, should be judged on your own by the content's hard requirement for photorealism (do not deliberately pad the count, and do not avoid them just to save effort); images that are truly needed should be generated all at once in Stage 2.

  • prompt template(each one must carry the palette and texture words to lock the color scheme): "<主体描述>, <构图/视角>, <palette 色名词> palette, low saturation, editorial photography, <光线/情绪词>, no text, no watermark" Here the palette color terms come from the plan.md color scheme (e.g. "deep navy and muted gold"); all images in the same deck reuse the same set of color phrases. Choose the aspect ratio by use (full-page background 16:9, half-width accompanying image 4:3 / 3:4).
  • Must-check after generation：vision_analyze Check whether the content is right, whether the tone matches the palette, and whether there is any text/watermark/extra people; if the color is off, revise the prompt and regenerate, and only if it cannot be salvaged use a CSS color overlay (duotone / semi-transparent primary-color layer).
  • Secondary harmonization when embedding：filter: saturate(.85) contrast(1.05) Fine-tune + use the --bg rgba to make a gradient mask (darker on the text side, lighter on the image side) + vignette, drawing the image into the deck's color gamut; the text area must be guaranteed readable.
  • Encourage fancy usages: generated images are not just <img> tiled—clip-path irregular cropping, mask-image for a reveal entrance (obey ≤2s + forwards), mix-blend-mode to blend with background layers, using them as Three.js textures. Let real images also become part of the visual effects.
  • Image sources for parallel objects in the same group must be consistent across the whole group (hard rule): in the same page, for peer equivalent items in a grid / card wall / row of the same kind (a group of foods / products / exhibits / people / logos / products…),either all real images or all code-drawn, mixing within the same group is forbidden. If you decide to generate images, generate for every member of that group; if you cannot do all members, fall back for the whole group to code—no "where there is an image use <img>, where an image is missing use <svg> to fill in" (a split between image and text within a group hurts more than code for the whole group). Before rendering that group, first confirm that the member images are all in place; for whoever is missing, generate it or switch the whole group to code.Self-check: each group has N members, either all N real images arrive or all 0 are code; the page-sequence table's "N cards" = the number of image rows for that group in the asset list.

(If image_generate is not in the tool list, skip this section; all visuals are code-drawn.)

7. Aesthetic bottom line (anti-AI slop) and the philosophy of brilliance

Every deck must have character and a stance, and must never be formulaic AI design:

  1. Fonts: default Inter / Roboto / Arial / Open Sans / Lato / Space Grotesk / system fonts are forbidden; pair display + body, matching the theme; do not always go for retro serifs, and do not repeatedly use Fraunces / Cormorant / Playfair. The end of font-family must carry a generic fallback (sans-serif / serif / monospace); for numbers / data readouts use a monospaced font that definitely contains digit glyphs (JetBrains Mono / IBM Plex Mono, etc.).Chinese large headlines must use a font containing complete Chinese glyphs (Noto Sans SC 800/900, etc.); for impact, stack multiple layers of text-shadow / -webkit-text-stroke stroke—English display fonts (Bowlby / Bangers) and most ZCOOL decorative fonts have incomplete Chinese character sets, and putting them on will make large headlines have missing/broken characters.

1b. Render safety (characters/icons): ① For mathematical formulas, script 𝒩 and combining Unicode (ε̂/ε̃) are forbidden; headless rendering turns them into tofu blocks—switch to <sub>/<sup> or plain ASCII; ② Use SVG for core icons / category symbols,No emoji(emoji fonts are often missing → the whole area goes blank). 2. Color scheme: clear primary color + sharp accents, exact hex, non-even distribution; no purple-pink gradient on white background / generic blue-green gradients / boring grayscale. 3. Anti-beige: unless the outline or task_pack.request.query explicitly requires it, warm beige / cream / rice paper / ivory (#FBF7F0 #F5F1EA #ECE3D0 and similar warm whites with R>G>B) are forbidden as the main background, and aged paper / tea-stain noise / vintage manuscript tones are forbidden. Clean pure dark / cool white / saturated brand colors are all completely OK. 4. Chinese font coverage: if Chinese is included, Chinese fonts must be imported via Google Fonts (Noto Sans SC / Noto Serif SC / ZCOOL XiaoWei / Smiley Sans / LXGW WenKai, etc., chosen by style) and placed in the font-family chain of all elements that display Chinese; relying only on PingFang SC / Microsoft YaHei is forbidden. The language of the whole page should be naturally unified; do not use two parallel sets of text in Chinese and English. 5. Form fits purpose: a deck is slides, not a web app—browser-style top bars / side navigation / a persistent console shell running through the whole deck (app status widgets like LIVE FEED / SESSION / VERSION / pulsing indicator lights) are forbidden; metadata goes only in the footer or on the cover. 6. Content actually drawn out: charts should directly draw graphic elements using the real values already present in the outline's "Content and Basis"; the first screen should present real content; hero / cover must strictly avoid "a huge solid color block with only one or two words"—there must be a clear main title + explanatory copy + visual focal point. The content must have a real subject and real data already supported by the outline; fabricating numbers to fill the page is strictly forbidden; when evidence is insufficient, return Entry / Story and do not use placeholder words to pass off completion.

  • Decoration never covers body text: at the HTML layer use a z-index ladder (background 0 / content 1–10 / overlay 20 / HUD 50), with decorative absolute elements pointer-events:none and a z-index lower than the text in the same area.Inside SVG / Canvas there is no z-index, only drawing order—text must be drawn last (above decorative lines, glows, connectors, and nodes); if text unavoidably sits on top of graphics / illustrations, give it paint-order:stroke + a light stroke in the same color as the background, or place a semi-transparent rounded backing panel / radial halo beneath it to support it, ensuring it is readable from any angle (this is exactly the cure for "small text in illustrations being eaten by lines").
  1. Layout and whitespace (whitespace is part of the composition, not the leftover scraps after arranging everything)—not tied to a fixed template; arrange according to these criteria, applicable to any number of zones / any layout:
  • First define the safe area, then compose freely within it: content must not cross --safe-x/-y(§4); this is the only hard border; how many zones to divide the frame into depends on the subject (1 zone hero / 2 columns / 3–4 cards / collage / full-screen scene are all fine), do not force a fixed "how many zones" template.
  • Every bit of remaining space must have an owner: blank space should either be systematically distributed between elements (spacing taken only from the --gap-* scale, with unified rhythm), or intentionally gathered in one place for breathing / emphasis;it is forbidden for leftover space to leak into accidental dead white on one side or one corner. Self-check perspective: treat the blank space as an invisible block—it should have a sense of position and a reason; if you cannot state the reason, it is a bug.
  • Parallel items aligned to a common baseline / equal height: a row of cards / two columns of content use align-items:stretch or equal-height layout, eliminating the jagged dead whitespace created by "one column shorter than the other"; don't use flex-start to let it be misaligned.
  • Content volume drives density: can't fill → enlarge the main subject / add breathing room / merge pages,not pinned to the top collapsing into bottom whitespace(forbid a single margin-top:auto pinned to the bottom; for a full-screen flex column use justify-content to distribute the vertical remainder evenly); overflows → split the page or reduce to --fs-min, not force it until it overflows.
  • Non-overflowing hard bottom: fixed container overflow:hidden + 子 min-width:0, or fit-content / allow wrapping, reserve ≥15% margin; for oversized display headings set max-width to allow wrapping, forbid white-space:nowrap to force it;line-height<1 for huge text, calculate height by the ink box and keep ≥24px from neighboring blocks.
  1. Overlays and cursor: for canvas trail fade-out use clearRect or destination-out, strictly forbid low-alpha fillRect spread across the whole screen (accumulating into an opaque mask covering the body text); custom cursor z-index no higher than the body text and pointer-events:none。
  2. Unforgettable point: the whole deck should have at least 2–3 memorable details—a dramatic opening, a unique data animation, an unexpected transition, or an easter egg.
  3. No grid-pattern backgrounds: graph paper / blueprint grid / perspective grid floor (horizon grid) / regular dot matrix, as well as Three.js GridHelper——must never be used as backgrounds, this is a severely overused AI cliché, not even a single low-opacity layer. If you need depth/texture, use: gradient glow, shader noise, particle flow field, radial vignette. (only forbids "visual grids tiled as backgrounds"; CSS Grid layout, i.e. display:grid 's page arrangement, is unaffected.)
  4. Don't pad things out with clichés: don't default to "canvas particle background + editorial typography" regardless of subject, and don't default to "immersive roaming + camera flips" regardless of subject—both are clichés. Choose the technique that best fits the subject (see §0 signature visuals); 2D/CSS can also score full marks with creativity; but dynamic background layers (3D/shader/particle flow) are broadly applicable, so don't make the background a static dead plane.

Gorgeous philosophy—be as gorgeous as possible, but gorgeously appropriate: within the density allowed by the scene tier, maximize visual expressiveness—continuously subtly moving backgrounds, parallax / magnetic / turbulence mouse responses, morphing / glow hovers, backdrop-filter / mix-blend-mode / mask-image / clip-path, preserve-3d spatial depth, particles and procedural textures, staggered reveal, large-type typographic tension (letter-spacing must not make glyphs stick together).When heavy techniques are called for, use them—don't avoid them because they're hard to debug：3D/shader dynamic background layers (broadly applicable, especially tech/abstract/data/network), code-built 3D roaming scenes (spatial subject matter), multi-scene immersion, maximalist collage are all bonus points; but heavy techniques mustserve the subject, not be flashy for flashiness's sake—expressing the subject thoroughly with 2D/CSS is equally top-tier fancy. Backgrounds should by default be continuously subtly moving; a purely static gradient is a point loss. Gorgeous ≠ cluttered: no matter how dense, the hierarchy must be clear, the color scheme must have a stance, and it must fit the scene tier.

8. Engineering pitfalls (common bugs, review before writing code)

  1. JS function reference order: a top-level immediately-executed main control function should not directly call a global function that hasn't been registered yet; for those that may be undefined, add if (typeof fn === 'function') Defense — a ReferenceError on the first line will kill all subsequent scripts (paging/animations all break).
  2. Three.js locked to r128：https://cdnjs.cloudflare.com/ajax/libs/three.js/r128/three.min.js(UMD global is the most stable); use OrbitControls with three@0.128.0/examples/js/, not the r150+ path (deprecated).ShaderMaterial({vertexColors:true}) will automatically inject attribute vec3 color, so do not declare it again in vertexShader (redefinition → particles all black).
  3. Canvas / Three.js size and DPI：renderer.setPixelRatio(devicePixelRatio)；setSize(w, h) do not pass the third parameter; get the size from the parent element getBoundingClientRect()(the canvas itself may initially be 0) and listen with ResizeObserver.
  4. Particle parameter quick reference(spherical starfield, camera z≈400, AdditiveBlending): darker 3000 particles / sz 0.5–2.5 / projection factor 300 / alpha 1.0 / mask 0.85; moderate 7000 / 1.2–4 / 550 / 1.3 / 0.78; brighter 12000+ / 2–6 / 700 / 1.8 / 0.4. Principle: the cover should be striking (transparent background + colorful + high alpha), and content pages should be background-like (semi-transparent mask + cool-toned and subdued).
  5. ECharts color scheme: all series colors should be taken from the :root token; do not use the ECharts default palette; put chart initialization into slideInits[N], and the container must have a definite size.
  6. Keyboard events: attach the listener to window；load when window.focus() steals focus (decks are often embedded in iframe previews).
  7. Idempotence of incremental filling：slideInits[N] inside, add an "already initialized" guard (repeated activation should not create the canvas again / bind listeners again).
  8. Build a 3D scene in code(when the immersive 3D signature is chosen): use parametric geometry (combinations of Box/Plane/Cone/Torus/Sphere) to assemble a realistic scene + three types of light: Ambient/Directional/Point, with the whole deck sharing one persistent scene, one camera position per page, and the camera lerping along an arc when paging (the look-at target must be interpolated in sync). For a complete example, see fancy-cookbook.md"Build a 3D scene in code" + "Single 3D world camera waypoint movement". Set up the scene and camera and get them running during the skeleton phase; then only adjust the camera position and that page's HTML page by page.
  9. Avoid the cover debugging black hole: you cannot see the DOM/console and can only guess from screenshots, soprioritize large SVG for the cover/hero's main visual; use Three.js for the background (particles/starfield/the scene template above), and do not hastily build unverified custom geometry on the cover (it is very easy to fall into long guess-and-check rework).For a large hero image use <img> + object-fit rather than background-image— in headless rendering, large images with background-image are often not decoded yet at screenshot time, making the whole page nearly black.

9. references

  • references/style-families.md — Style family library: mood / suitable and unsuitable scenarios / palette examples / font direction / how fancy works in that style. Required reading in Phase 0.
  • references/fancy-cookbook.md — Technique recipes: entrance animations / cross-page transitions / global backgrounds / interactive easter eggs, including core code patterns and safe parameter ranges. Read during Phase 0 selection.