name: guizang-social-card-skill description: Generate Guizang-style social card image sets, Live Photo motion cards, material-first Live Photo puzzle layouts, triple Live Photo collages, long-video-to-Live-Photo treatments, and WeChat official account cover pairs from articles, scripts, screenshots, product notes, subtitles, photos, or user-supplied videos. Use when the user asks for 小红书图文, Rednote/Xiaohongshu images, social cards, carousel images, 3:4 covers, Live Photo, 实况照片, 单视频实况拼图, 二宫格实况拼图, 三连实况拼图, 四宫格实况拼图, 微信公众号封面, WeChat 21:9 + 1:1 covers, Swiss Style, or magazine-style social images.

Guizang Social Card Skill

Create polished social card packages for Xiaohongshu/Rednote, WeChat Official Account, article covers, and platform thumbnails.

This skill is self-contained. It borrows visual principles from the Guizang PPT style system, but it must not edit the original PPT skill, its templates, or its references. If the original PPT skill is available, you may read it for reference only.

Generated work must live in a task folder, not in the skill root. Default to local-tests/<slug>/ inside this repository, or use the explicit output folder requested by the user. Do not create root-level task folders such as social-card-*, livephoto-*, wechat-*, output/, or loose rendered assets next to SKILL.md.

What To Produce

Use this skill for:

• Social card / carousel image sets: cover plus content pages, especially Xiaohongshu/Rednote 3:4.
• Short Live Photo motion cards when the user asks for Live Photo / 实况照片 and supplies video evidence or screen recordings.
• Material-first Live Photo puzzle layouts when the user has high-quality video assets and wants single-video, two-grid, three-grid, or four-grid motion cards with little or no added text.
• Triple Live Photo collages when the user has three short videos, three results, three viewpoints, or a high-information comparison that should stay inside one image-card unit.
• Long-video intake for Live Photo: diagnose whether to trim, speed up, split into a triple collage, or ask the user for a specific time range before rendering.
• WeChat Official Account cover pairs: one 21:9 main cover plus one 1:1 square cover, composed together in the same HTML for visual checking.
• Screenshot-heavy product posts, article covers, tutorial carousels, outdoor/lifestyle notes, AI/product update explainers.
• Social images that need Guizang-style Swiss or editorial magazine layouts.

Do not use this skill for:

• Full slide decks or horizontal PPT websites. Use the PPT skill for that.
• Long-form video generation. Use a video skill for that. This skill only supports short, layout-bound Live Photo cards that replace a still image slot with video.
• Pure image editing with no layout or article extraction requirement.

Rednote Category Capability (capability circle)

The 11 most-common Rednote (小红书) categories fall into three buckets. See references/category-cookbook.md for the recipe-by-recipe routing.

Strong end-to-end (text, structure, and image story all in scope):

• 旅行 (Travel), 职场 (Workplace), 推荐 (Recommended, after specifying a subtype).

Strong on text & structure; image needs to come from the user or a sourced library:

• 游戏 (Game), 影视 (Film/TV), 美食 食谱方向 (Food — recipes only), 彩妆 教程方向 (Makeup — tutorials only), 健身 (Fitness), 家居 (Home), 穿搭 精选方向 (Outfit — capsule/essay only).

Outside scope — push back honestly rather than promise a result:

• 美食 菜品大片摆盘 (food-photography showcase).
• 穿搭 日常 OOTD 全身 (daily OOTD body shots; we cannot generate or simulate).
• 情感 梦核 / 氛围感装饰风 (dreamcore / aesthetic-light styling — clashes with both Editorial and Swiss).
• Y2K / 千禧辣妹 / 哥特萝莉 / kawaii decorated aesthetics.
• Pure photography showcase posts where the image is the entire deliverable.

When a request falls in the third bucket, name what we cannot do at intake — do not silently retrofit a layout that misses the user's intent.

Core Principle

Expression comes first. The goal is not to squeeze text into posters; it is to turn the source into a clear visual argument.

For each page, decide:

• What should the viewer understand in one glance?
• What evidence, screenshot, or image supports it?
• Which words must be large, and which can become captions or metadata?
• What can be removed because it belongs in the post body, not the image?

Required References

Read these files as needed:

• references/platform-specs.md for exact ratios, output sizes, and naming.
• references/style-system.md for Guizang editorial and Swiss visual rules.
• references/theme-presets.md when choosing electronic-magazine palettes or Swiss accent palettes.
• references/layout-recipes.md when selecting carousel/social-card/WeChat page structures.
• references/components.md for the shared component spec: font stacks, type scale, minimum readable sizes, Chinese title length bands, Swiss card-fill mutual-exclusion rule, image-container ratio classes, spacing tokens, and Lucide icon rules.
• references/background-systems.md when building electronic-magazine WebGL/ink/paper backgrounds.
• references/portrait-fill.md when adapting layouts to 3:4 and avoiding under-filled vertical space.
• references/content-planning.md for cover hooks, page breakdown, and copy compression.
• references/production-workflow.md for HTML/CSS rendering and image handling.
• references/live-photo-production.md when the user asks for Live Photo / 实况照片 / 三连实况拼图, supplies video assets for a social card, or wants Xiaohongshu / WeChat motion-card delivery. It covers information budget, single vs triple Live Photo, long-video intake, and platform publishing reminders.
• references/image-overlay.md whenever text sits on top of a photo: photo qualification, localized tint fallback, and face / subject avoidance via multimodal subject mapping.
• references/screenshot-treatment.md when the user supplies an app / web / code / dashboard screenshot — picks .frame-shot over .frame-img, sets corners/shadow/bg/inset, decides on .device-browser or .device-phone chrome.
• references/map-component.md when the content has spatial relationships (travel route, store locations, walking tour) — real routes default to Mapbox Static or OSM static tiles; schematic SVG is only for conceptual / illustrative maps. Pins are HTML overlays; never use live JS maps.
• references/title-shortener.md when the task is a WeChat 21:9+1:1 cover pair, or any cross-platform reuse — derives the 1:1 short title from the long one (5-step extraction, 4 patterns, anti-patterns, sizing on .poster.square).
• references/category-cookbook.md to route a user-named Rednote category (旅行 / 职场 / 游戏 / 影视 / 彩妆 / 美食 / 穿搭 / 家居 / 健身 / 情感 / 推荐) to applicable recipes and to confirm scope.
• references/qa-checklist.md before delivering final images.

Workflow

1. Intake

Gather only the missing information that changes the output:

• Target platforms and ratios.

• Source text, subtitles, article, or title.

• Rednote category — if the user names one of the 11 common types (旅行 / 职场 / 游戏 / 影视 / 美食 / 彩妆 / 穿搭 / 家居 / 健身 / 情感 / 推荐), route via references/category-cookbook.md to find the right recipes and to confirm the request is inside the capability circle (see "Rednote Category Capability" above). If a request lands in the outside-scope bucket, surface that to the user before designing, do not silently retrofit.

• Supplied images/screenshots and where each should appear. For News / Tutorial / Data / Review content, actively prompt for screenshots or photos — they are the evidence layer. A poster with no real artifact tends to read as filler.

• Supplied video assets, if the user asks for Live Photo. Treat user-provided video as the normal path; web-sourced free video is only for demo/promo cases or when the user explicitly asks for sourced material. Confirm the target platform because duration differs: Xiaohongshu supports 5s; WeChat Official Account Live Photo should stay at 3s and must be uploaded from iPhone. Before cutting, read references/live-photo-production.md and classify the request as single Live Photo, triple collage, or long-video intake. If the source is too long or contains multiple usable moments, do a low-cost diagnosis first, then ask once whether to trim, speed up, split into multiple wells, or use a user-specified time range. If the source is shorter than the target duration, ask whether to provide a longer clip, accept a shorter Live Photo, or explicitly allow a hold/slowdown. If the important focus is ambiguous, suggest possible crop/enlarge options but let the user decide before executing.

• If the user supplies only text (no images at all), ask once before designing:

  这篇我需要 1-2 张图。三种走法：
  A. 你自己有照片 / 截图，传给我（推荐——最不"AI 感"）
  B. 我去 Pexels / Unsplash / Flickr 帮你找
  C. 用 AI 生成
  

  Recommend A in one line — your own photo is what makes a poster not look AI-generated. Accept whatever the user picks (including "都行你看着办") and proceed. Do not re-prompt later, do not keep nudging toward A across multiple turns. This question is one-shot.

• Preferred style if specified: Swiss Style, magazine/editorial, tech, outdoor, etc.

• Hard constraints: title text, no image on 1:1 cover, must include a hardware photo, keep screenshot readable, and so on.

If the user has already supplied enough context, proceed with reasonable assumptions.

If the content involves current product releases, policies, prices, claims, or news, verify unstable facts with browsing and cite sources in the final response.

2. Extract The Story

Turn the source into a page plan before designing.

For Rednote:

• Page 1 is the cover hook.
• Pages 2-N each carry one idea only.
• Use 5-9 pages for most posts. Compress or combine pages when lower areas become empty.
• Keep the post body for nuance; images should carry hooks, comparisons, checklists, and sharp takeaways.

For WeChat:

• Always produce a paired system: 21:9 main cover and 1:1 square cover.
• Build both covers in the same HTML file and add a combined preview section so their visual relationship can be checked together.
• 21:9 keeps the full or near-full title, subtitle, and one strong visual relation.
• 1:1 uses a simplified short title derived from the long title: big centered type, no image by default, no cramped subtitles.

3. Choose Style Mode

Pick one mode per package. The two systems are not bound to specific content types — what changes is the visual stance, not which topic you can talk about. A workplace essay can be Editorial; a travel ledger can be Swiss. Pick by the feeling you want, not by category lookup.

Editorial Magazine x E-ink brings:

• Serif/Songti display + quiet sans body, paper + ink palette.
• Atmosphere layer (paper grain / ink wash / WebGL canvas) over a warm paper base.
• Ledger rows, marginalia, pull quotes, large photo wells — magazine-feature feel.
• Best when you want the page to feel slow, considered, hand-set.

Swiss International brings:

• Inter / Helvetica feel, very light display at large sizes, mono labels at small.
• Strict left-aligned grid, hairline rules, one high-saturation accent.
• Card-fill matrices, KPI towers, h-bar charts, numbered statements — system / data feel.
• Best when you want the page to feel engineered, quantified, decisive.

If both feel viable for a piece of content, the question becomes editorial intent: "is this a feature story or a release note?" That decides the mode, not the topic itself.

Do not mix the two visual systems inside the same image set unless the user explicitly asks for a hybrid.

Then pick one theme:

• Editorial Magazine x E-ink uses one of 6 magazine palettes: Ink Classic, Indigo Porcelain, Forest Ink, Kraft Paper, Dune, or Midnight Ink (the only dark variant; reserved for game key art / night photography / cinematic covers).
• Swiss International uses one of 4 accent palettes: IKB Blue, Lemon Yellow, Lemon Green, or Safety Orange.

Read references/theme-presets.md for exact CSS tokens. Do not invent arbitrary colors unless the user has a strict brand requirement.

4. Plan Pages

Create a concise internal plan:

Page 01 / cover / hook / image source / layout intent
Page 02 / point / key copy / visual evidence / layout intent
...

When the user asks for approval, show this plan before rendering. Otherwise use it internally and proceed.

Use references/layout-recipes.md to choose page structures. Avoid making every page a repeated title-plus-card layout.

For 3:4 images, check references/portrait-fill.md before coding. A short table or ledger must be expanded into a full portrait composition with a quote column, image evidence, marginalia, larger rows, or a background hero zone.

Audience-facing copy must describe the user's actual scene, not the production method. Internal terms such as 3s, 5s, Live Photo, triple collage, information budget, long-video intake, speed-up, highlight detection, one action point, or layout template may guide planning, filenames, QA notes, and delivery summaries, but they must not become the H1, hook, or main body copy unless the user is explicitly making an instructional post about those concepts. Before rendering, read every visible headline once as a real viewer: if it sounds like a task requirement, replace it with scene-specific copy.

Do not add non-template ornaments just to satisfy an automated density warning. Extra rulers, side bars, pseudo time axes, decorative labels, or invented badges must come from an existing layout recipe or a user request. If a density warning appears, fix it by choosing a better recipe, resizing real content, or accepting the advisory warning with a visual rationale; do not put meaningless UI on the card.

For Live Photo cards, plan them as normal social cards first, then decide the motion role: one action point, one small process, a before/after change, three parallel results, or ambience/evidence. The only structural change is that one or more image wells become video wells. Keep the same ratio, crop, safe-area, typography, and style mode rules; apply the still-image crop logic to the video stream. The first frame must pass the same checks as a static image: no excessive crop, key UI/content remains readable, and the card still follows the chosen layout recipe. Read references/live-photo-production.md before rendering.

For material-first Live Photo puzzle cards, let the video assets lead. Use little or no copy: one short headline is enough for a single-video cover, and two-grid / three-grid / four-grid versions should usually have no added text. When a single-video cover adds text on top of the footage, use the M16 Image-Led Cover / text-on-image rules: subject map first, safe quiet zone, Editorial serif/Songti title at regular-medium weight, paper-cream text, and no default full-canvas mask. Do not invent extra kicker, meta, hairlines, labels, rulers, badges, subtitles, or explanatory production terms just to make the overlay feel designed. If only one headline is available, make the typography carry the layout: phrase-aware line break, restrained size, tracking, alignment, and placement. Treat source-embedded text as part of the footage; only avoid adding new text unless the user asks.

4.5. Copy The Seed Template

Do not write HTML from scratch. Pick one seed template based on the style mode chosen in Step 3:

• Editorial Magazine × E-ink → copy assets/template-editorial-card.html into the task folder as index.html.
• Swiss International → copy assets/template-swiss-card.html into the task folder as index.html.

The seed already wires up: font loading, theme tokens, all three poster sizes (.poster.xhs / .poster.square / .poster.wide), the pair-preview frame, grain/background layers, and all class definitions referenced by the layout recipes.

Set the theme/accent on the <html> element:

• Editorial: <html data-theme="ink-classic | indigo-porcelain | forest-ink | kraft-paper | dune | midnight-ink">.
• Swiss: <html data-accent="ikb | lemon-yellow | lemon-green | safety-orange">.

Replace the single placeholder poster after <!-- POSTERS_HERE --> with one <section class="poster ..."> block per page, each carrying the HTML skeleton from a chosen Layout Recipe (M01-M16 for Editorial, S01-S12 for Swiss). Never load the wrong template's class system: Editorial recipes assume serif display + ledger/marginalia/pipeline-v; Swiss recipes assume Inter + card-fills + matrix/h-bar/kpi-tower. Mixing them silently breaks the layout.

5. Build And Render

Default implementation pattern:

• Create a task folder under local-tests/<slug>/ by default, or inside the user-requested output folder. Never put generated task folders, rendered images, MOV files, .pvt packages, or downloaded sources in the skill root next to SKILL.md.
• Put source images in assets/.
• Start from the seed template copied in Step 4.5, not a blank file. Prefer changing only the <!-- POSTERS_HERE --> region page-to-page. If a task needs custom layout CSS, add one clearly named task-scoped block in the copied file and keep semantic defaults reset (figure { margin:0; }, no browser-default spacing surprises).
• Use Playwright or a browser screenshot tool to export each .poster or .cover node.
• Save rendered images in output/.
• Verify dimensions and inspect the rendered PNGs.
• Keep node validate-social-deck.mjs <task-dir> available for auto-check passes. It checks overflow (R1), footer collision (R2), Swiss bold display (R3), minimum font size (R4), 4-band density (R5), .h-xl line caps (R6), browser-default figure margin drift (R7), visual bounds / bottom whitespace (R8), and title-to-content gaps (R9). Exit code 1 on any FAIL — fix before final delivery when auto-check is requested. WARN is advisory but read it.

Live Photo branch:

• Decide the information budget before rendering: 3s fits one action point; 5s fits one small process; triple collage fits three parallel clips but not a complex story; long videos require diagnosis before editing.
• For long sources, avoid claiming precise automatic highlight detection. Probe duration/resolution, make a sparse contact sheet, and choose between trim, speed-up, split/triple collage, or asking the user for a time range.
• Extract a first frame from each video well, place it in the final static card layout, and show/inspect that preview before making .pvt. This catches crop and hierarchy issues with much lower token and render cost.
• Render the paired MOV at the platform duration: 5s for Xiaohongshu, 3s for WeChat Official Account.
• Extract the key JPG from a readable representative frame.
• Package JPG + MOV into .pvt with makelive; AirDrop the .pvt as one item for iPhone tests.
• Validate dimensions, duration, frame count, package contents, and motion quality. Prefer a contact-sheet frame strip for visual checks so only the final tiled image needs human/model inspection. Use references/live-photo-production.md for exact commands and failure-mode checks.

Do not place visible instructions, keyboard shortcuts, or usage explanations inside the images.

For Editorial Magazine x E-ink, use a layered background system. Prefer a subtle WebGL ink-flow canvas or a frozen procedural canvas plus paper grain. Read references/background-systems.md; do not rely on a flat beige background, and do not add page-wide grid/dot backgrounds.

6. Image And Screenshot Handling

When the user provides screenshots:

• Preserve screenshot content unless the user asks for redesign.
• Prefer programmatic framing: target-ratio canvas, safe padding, clean background, readable screenshot.
• Do not stretch screenshots.
• If screenshot clarity matters, enlarge the screenshot area and reduce nearby text.

Text-On-Image Composition

Whenever a poster places text on top of a photo (full-bleed cover, large image well, generated-image overlay), follow references/image-overlay.md:

• Selection first, tint only if needed. A photo covering ≥60% of the canvas must first pass the quiet-zone and light tests in image-overlay.md. Compose without a mask first; if the thumbnail check fails, add only a localized, image-toned tint around the title area. Do not default to full-canvas falloffs.
• Subject mapping is mandatory. Before placing the title, read the image with the Read tool, describe in plain language where the subject's face/focal feature sits, and record the subject map as an HTML comment next to the hero block. Place text only in the documented safe zones.
• Crop discipline — set object-position inline on every photo. The template default (center 50%) is a fallback, not a recommendation. For every <img>, decide based on subject location and write it inline: e.g. style="object-position:center 62%" for mid-body subjects, center 30% for sky-heavy landscapes with horizon-line subjects, center 70% for foreground gear. See the table in references/components.md for ranges and image-overlay.md for face-photo specifics. Skipping this silently crops subjects out of frame on tall ratios (r-3x4, r-21x9).
• Thumbnail test. Downscale the rendered PNG to 360 px wide and confirm the title is still legible. If the title fights the photo, move the title, swap the photo, or add a localized image-toned tint; if the photo looks dead, the tint is too heavy or the photo was wrong for text-on-image.

Editorial dark covers (e.g. game journals on key art) and Swiss covers with hero photos both require these checks. Skipping them is a known failure mode (see style-system.md Anti-Pattern D).

When the user has no images:

• This branch only runs if the Step 1 "三选一" gate landed on B (web-sourced) or C (AI-generated). Never silently fall into B or C — the user picked one.
• For C (AI-generated): use generated bitmaps only where they add real value, usually 1-2 pages. Generate images that match the page's visual role, not generic decoration. Keep generated images free of embedded titles, page numbers, logos, or fake UI labels unless explicitly needed.
• For B (web-sourced): see the Web-Sourced Images section below.

Web-Sourced Images (fallback when user has none)

When the user has no screenshots/photos and a generated bitmap would not fit the page's role (e.g. Editorial atmosphere shot, outdoor / lifestyle backdrop, game cover art, real-world product shot), fetch from the web instead of leaving the page thin.

Policy: grab first, disclose after, let the user decide on attribution. Do not pre-filter sources by guessed license — the user is the rights holder of the final composition and decides what is acceptable.

Recommended sources, in order of preference. All five below are free-tier libraries with no required licensing fees; we do not pull from paid stock sites (视觉中国 / Getty / 站酷海洛 etc.).

1. Unsplash — https://unsplash.com/s/photos/<keyword>. Strong for outdoor / lifestyle / atmospheric backdrops. English keywords work best. License is permissive but verify case by case.
2. Pexels — https://www.pexels.com/search/<keyword>/ or https://www.pexels.com/zh-cn/search/<keyword>/. Supports Chinese keyword search natively — fills Unsplash's gap on 国内场景 (中文街景 / 国风物件 / 本地地名). Use this first when the subject is China-specific or the keyword is Chinese. Free under Pexels License.
3. Flickr CC-licensed pool — https://www.flickr.com/search/?text=<keyword>&license=2%2C3%2C4%2C5%2C6%2C9. The license filter (license=2,3,4,5,6,9) restricts to Creative Commons photos. Fills the "documentary realness" gap: street photography, people-in-context, real interiors, non-styled scenes that Unsplash/Pexels lack. Always preserve CC attribution if the user opts in.
4. Wallhaven — https://wallhaven.cc/search?q=<keyword>. Strong for game / anime / wallpaper themes. Content is user-uploaded, rights are unverified.
5. Direct web search — when a specific subject is needed (a product render, a game still, a historical photo). Use WebFetch / WebSearch to find a candidate URL.

Editorial-mode picking order: Pexels (if keyword is Chinese / China-specific) → Unsplash → Flickr CC (if you need real-life feel) → direct search. Swiss mode rarely needs any of these — product renders, UI screenshots, and keyshot-style images should be user-supplied or AI-generated, not stock.

How to fetch:

• Use WebFetch or curl to download the image into the task folder's assets/ directory.
• Name the file by purpose, not by hash: assets/hero-mountain.jpg, assets/ui-pulse-card.png.
• Record the source URL in a assets/SOURCES.md file next to the images (one line per file: hero-mountain.jpg ← <url>). Always do this even if the user declines attribution in the final image — it preserves provenance for the human author.

After fetching, surface the provenance to the user before finalizing the design:

我从 <site> 取了这些图：
- assets/hero-mountain.jpg — <url>
- assets/ui-pulse-card.png — <url>

⚠️ 版权未经核实。请你判断是否可用。
是否需要在图文中标注来源？
- 要：我把 "Photo · <site> · @<author>" 加到对应页脚 / 角标。
- 不要：原样使用,不加注释。

If the user picks "标注" — add a small mono caption (Swiss: .t-meta 18-20px in corner; Editorial: .label next to the image well). Never crowd the caption into the layout's focal area.

If the user picks "不标注" — proceed silently. The provenance still lives in assets/SOURCES.md for the user's own records.

If an image is only one element among many in a composite (e.g. one of nine photos in a matrix), the user may reasonably skip attribution. Do not force a credit label that breaks the layout.

7. Deliver

Show user first, validate on request. Auto-running the validator after every render takes too long and delays the user from seeing results. Default flow:

1. After rendering completes, immediately show the user the rendered images inline (absolute paths) with a one-sentence summary of what was built.
2. Ask one question: "先你自己看，还是我先自动核查一遍？" (Do you want to review first, or should I run the auto-check?)
3. If the user says "我自己看" / "先给我" / "no need" — stop here, let them inspect, and respond to whatever they raise.
4. If the user says "你查吧" / "auto-check" / "yes" — only then run node validate-social-deck.mjs <task-dir>, fix any FAIL, and re-render before final delivery. Mention density/cap WARNs.

Never silently run the validator before showing the user — it costs minutes per pass and the user often spots issues faster.

Final response (after the user has reviewed or asked for auto-check) should include:

• Output folder path.
• Rendered images shown inline with absolute paths when useful.
• A short note on dimensions and verification (or "not yet validated, awaiting your review").
• For any image fetched from the web: source URL + site + the attribution decision the user made.
• For Live Photo: the .pvt package path, the debug JPG + MOV pair, target platform duration, and validation summary.
• For Live Photo publishing: remind the user of two things: platform limits (5s Xiaohongshu, 3s WeChat Official Account) and publish path (AirDrop the .pvt package as one item to iPhone, then publish from the matching mobile app path; desktop/web upload paths generally cannot recognize .pvt as a publishable Live Photo).
• If the user cannot use the iPhone/AirDrop publishing path (e.g. desktop-only workflow, Android, or a platform that does not support Live Photo), offer a degraded delivery: export a short looping GIF or a silent MP4 clip from the same MOV source. The GIF/MP4 keeps the motion evidence but loses the Live Photo tap-to-play experience. Confirm with the user before switching to this fallback.
• Any unresolved risks, such as source images being low resolution.

Non-Negotiables

• Never edit the original Guizang PPT skill or any upstream skill copied from elsewhere.
• Never create generated work in the skill root. All task artifacts must be under local-tests/<slug>/ by default, or under a user-requested output folder. Root-level generated folders like social-card-*, livephoto-*, wechat-*, and loose output assets are forbidden.
• Do not create random decorative SVG ovals, blobs, rain drops, stickers, or meaningless circles.
• Do not use nested cards or generic SaaS card layouts as the default.
• Do not let text overflow, touch the edge, or collide with the footer band. Pin .foot with margin-top: auto inside a flex column, never with position: absolute over growing content.
• When content overflows, measure the amount before editing. Small overflows should get small fixes: 1-40px means nudge/tighten, 40-90px means local compaction, 90-160px means slight title or paragraph compression, and only 160px+ should trigger recipe changes or content removal. After fixing, check R8 bottom whitespace so the page does not swing from overflow to a giant empty lower band.
• Do not let a title touch the next content block. Main display titles should usually keep at least 28px below; local headings should keep at least 16px. Use validator R9 before relying on visual inspection.
• Do not let text become too small to read on mobile.
• Do not write inline font-size + font-weight on display titles in Swiss. Use the typed classes (.h-hero / .h-statement / .h-xl / .num-mega). A 80-120px headline at weight 700-900 is not Swiss; "the larger, the lighter" is a hard rule.
• Do not deliver Editorial posters with a flat paper background, mono labels on every row, and no atmosphere layer. Run the Editorial Identity Test in references/style-system.md — a serif title alone does not make a poster Editorial.
• Do not fake data, release details, or percentages.
• Do not crop faces, key UI text, or hardware/product details unless the user explicitly accepts it.
• Do not turn a video card into a fake still sequence without saying so. If a source is shorter than the target duration, ask for a longer source, use a shorter platform-safe duration, or explicitly document any hold/slowdown.
• Do not skip the first-frame preview for Live Photo. Video is an image well with motion; its first frame must satisfy the static 3:4 layout and crop rules before rendering the MOV.
• Do not let result videos scroll through section boundaries in a shallow crop; this creates the "overlapping video" failure. Inspect contact sheets and choose a stable time window before packaging.
• Do not guess the user's visual priority when enlarging/cropping video for readability. Offer the crop/enlarge tradeoff and apply it after the user confirms, unless the request already makes the focal region explicit.
• Do not reuse a 21:9 cover by blindly cropping it into 1:1. Compose each ratio separately.
• 3:4 卡必须吃满画布。Content (text + image + data) 必须覆盖 ≥75% 画布高度。任何 >15% 画布高度的纯空白带都需要"留白理由"：(a) hero image 自带呼吸、(b) 单句宣言式 hero statement、(c) 段落顶/底 leading & trailing whitespace（前后总和 ≤15%）。禁止用 <div style="flex: 1"></div> 上下夹击把内容塞到中段——杂志页留白逻辑不适用于社交卡（杂志靠对开页吸收留白，社交卡逐张独立刷，欠填看着像 PPT 漏排）。Recipe-by-recipe 最小密度见 references/layout-recipes.md 每条 recipe 的「Minimum density」段。Render 后必须跑 qa-checklist.md 的 4 横带密度检查。

Guizang Social Card Skill · 小红书图文 / 公众号封面对

English README

一个适配 Claude Code / Codex 等 Agent 环境的图文卡片技能,用于从文章、文案、截图、产品笔记、字幕、照片或用户视频生成小红书 / Rednote 图文组图、Live Photo 动态卡与公众号 21:9 + 1:1 封面对。

内置两套视觉系统,共用一份图文工作流:

• 电子杂志风(Editorial)。像 Monocle / Kinfolk / Cereal 那样克制的版面,适合叙事、生活方式、旅行、阅读、影视、个人观察。
• 瑞士国际主义(Swiss)。网格、单一锚点色、直角发丝线、极致字号对比,适合产品测评、数据、方法论、教程、AI 工具。

这个 Skill 是 guizang-ppt-skill 的姊妹项目,共享美学语言但独立维护。PPT 解决"横向翻页演讲",这里解决"静态信息流图文"。

30 秒开始

npx skills add https://github.com/op7418/guizang-social-card-skill --skill guizang-social-card-skill

也可以直接把这段话发给有 shell 权限的 AI Agent:

帮我安装 guizang-social-card-skill。请把 https://github.com/op7418/guizang-social-card-skill 克隆到 ~/.claude/skills/guizang-social-card-skill,安装完成后检查 SKILL.md、assets/、references/ 是否存在。

已经安装过的话,用这段话更新:

帮我更新 guizang-social-card-skill。请进入 ~/.claude/skills/guizang-social-card-skill 执行 git pull,然后告诉我当前最新 commit。

安装后直接对 Agent 说:

帮我基于这篇文章做一套瑞士风小红书图文,5 张,IKB 蓝。

也可以试这些请求:

基于这份产品测评做一套小红书 3:4,标题用电子杂志风。
帮我把这篇文章做成公众号封面对:21:9 头图 + 1:1 分享卡,视觉保持一致。
我有 3 张露营照片,帮我做一套全图风格的小红书图文。
把这段游戏攻略文案做成一套小红书图文,需要从 wallhaven 拿点游戏原画。
我有一段咖啡视频,帮我做成小红书 5 秒 Live Photo 卡片,文字压在安静区域。
把这三个游戏片段做成三连 Live Photo 拼图,用 Swiss 风介绍攻略要点。

效果

• 🖋 双视觉系统:电子杂志风做氛围与叙事,瑞士风做事实与结构,两套共用同一份工作流
• 📐 3 个画板尺寸:.poster.xhs 1080×1440(小红书 3:4)、.poster.wide 2100×900(公众号 21:9)、.poster.square 1080×1080(公众号 1:1)
• 🎬 Live Photo 动态卡:支持单视频、二宫格、三宫格、四宫格、三连拼图、长视频低成本诊断;小红书按 5s,微信公众号文章内按 3s
• 🧩 28 个版式骨架:Editorial 16 个(M01-M16,含 Image-Led Cover、Pipeline、Before/After 等)+ Swiss 12 个(S01-S12,含 KPI Tower、H-Bar Chart、Matrix + Hero 等)
• 🎨 10 套主题预设:Editorial 6 套(墨水经典、靛蓝瓷、森林墨、牛皮纸、沙丘、Midnight Ink 暗色)+ Swiss 4 套锚点色(IKB Klein Blue、柠檬黄、柠檬绿、安全橙)
• 🖼 图源工作流:用户图优先;无图时按 Unsplash → Pexels → Flickr CC → Wallhaven → 直接搜索的优先级取图,落本地 + 自动写 SOURCES.md
• 🌫 WebGL 墨流背景:杂志风 hero 页可挂动态墨流;低性能或截图时可禁用
• 🪧 文字压图 + 主体避让:满铺图先做 quiet-zone 与主体映射,文字避开人脸、产品和关键动作;需要时只加局部 tint,不默认全图遮罩
• 🧰 截图美化资产:9 张 WebP 真实材质背景(Editorial 5 / Swiss 4),配套 .frame-shot / .device-browser / .device-phone 工具类
• 🗺 地图组件:MapLibre + OSM 真实瓦片,支持多 pin + 连线,适合旅行攻略
• ✅ 校验脚本:validate-social-deck.mjs 自动检测溢出、字号上限、4 横带密度、footer 碰撞
• 📄 单文件 HTML + Playwright 渲染:不需要前端构建链,node render.mjs 直接出 PNG

Live Photo 效果与版式

Live Photo 在这个 Skill 里的定位是"把用户提供的视频装进社交卡版式",不是让 Agent 随机找公开视频,也不是长视频正片剪辑。先让首帧按静态卡片成立,再让 3s/5s 的动作补充信息。

信息量判断是第一步:微信 3s 更适合一个动作点或一次状态变化;小红书 5s 可以容纳一个小过程;三连拼图适合三个并列结果,不适合讲一个必须顺序理解的长故事。

Live Photo 生成指南

1. 确认平台和素材:用户视频是默认输入;公开视频素材只用于 demo / 宣传测试。先确认小红书、微信公众号文章内,还是本地测试。
2. 判断信息量:问自己 3s/5s 内观众能看到什么。如果需要解释、音频或完整教程才能懂,就不应该硬塞进 Live Photo。
3. 选择结构:单个强素材用单视频动态卡;多个好素材用二宫格 / 三宫格 / 四宫格;三个并列结果用三连;长视频先做低成本诊断。
4. 先做静态卡检查:首帧必须像一张合格社交卡。检查裁切、主体、文字位置、平台安全区,不要把制作要求写成观众可见文案。
5. 再生成动态资产:在任务文件夹输出预览视频、关键 JPG、MOV 和 .pvt;不要把生成结果写到 Skill 根目录。
6. 交付时提醒发布路径:小红书按 5s,微信公众号文章内按 3s;通常需要把 .pvt 作为一个包传到 iPhone,再从对应 App 发布,电脑端/网页端一般不能直接发布 Live Photo。

可直接这样让 Agent 做:

把这个咖啡视频做成小红书 5 秒 Live Photo,标题只放一组,避开杯子和手。
这四段旅行视频素材质量很好,帮我做成四宫格 Live Photo,不加文字。
这段 2 分钟游戏视频先做 contact sheet,帮我判断适合截哪 5 秒做攻略 Live Photo。

适合 / 不适合

✅ 合适:小红书图文组图 / Live Photo 动态卡 / 公众号封面对 / 微信朋友圈封面 / 视频号封面 / 文章配图 / 教程拆页 / 数据回顾 / 旅行攻略 / 产品测评 / 截图说明

❌ 不合适:横向翻页 PPT(用 guizang-ppt-skill)/ 长视频正片剪辑 / 纯图片修图 / 无版式诉求的纯文字编辑

11 个小红书品类适配

按"能力圈"分三档,详见 references/category-cookbook.md:

端到端强势(文 / 结构 / 图都在能力圈内):

• 旅行、职场、推荐(指定子类后)

文与结构强势,图依赖用户或搜图源:

• 游戏、影视、美食(食谱方向)、彩妆(教程方向)、健身、家居、穿搭(精选方向)

能力圈外,主动说清(不强行接):

• OOTD 实拍流 / 梦核 / 仿胶片调色 / 真实测肤美妆等强烈依赖摄影或后期的细分赛道

常见使用场景

为什么是单文件 HTML 渲 PNG

• Agent 友好:HTML + CSS 是文本,Agent 能直接写、读、改、验证
• 版式精确:CSS Grid + 严格字号 / 留白 / 网格,远超 Markdown 排版能力
• 图源开放:可以接 Unsplash / Pexels / Wallhaven / Mapbox / OSM 等任意网络资源
• 质量可校验:validate-social-deck.mjs 用 Playwright 跑真实 DOM 测量,不是猜
• 交付简单:output/*.png 直接发,不需要部署、不需要导出工具
• 动态卡可落地:Live Photo 分支输出 JPG + MOV + .pvt,并记录小红书 / 微信的时长限制和手机端发布路径

平台支持

安装

方式一:一行命令安装(推荐)

npx skills add https://github.com/op7418/guizang-social-card-skill --skill guizang-social-card-skill

方式二:把下面这段话直接发给 AI

帮我安装 guizang-social-card-skill 这个 Claude Code skill。请按下面步骤做:

1. 确保 ~/.claude/skills/ 目录存在(不存在就创建)
2. 执行 git clone https://github.com/op7418/guizang-social-card-skill.git ~/.claude/skills/guizang-social-card-skill
3. 验证:ls ~/.claude/skills/guizang-social-card-skill/ 应该看到 SKILL.md、assets/、references/ 三项
4. 告诉我装好了,之后我说"做一套小红书图文"之类的话就会触发这个 skill

把这段话复制粘贴给 Claude Code / Cursor / 任何有 shell 权限的 AI Agent,它会自动完成安装。

方式三:手动命令行

git clone https://github.com/op7418/guizang-social-card-skill.git ~/.claude/skills/guizang-social-card-skill

触发方式

装好后,Claude Code 会自动发现并调用这个 skill。触发关键词:

• "帮我做一套小红书图文 / Xiaohongshu 图文"
• "帮我做一套 Rednote 卡片"
• "做一个公众号 21:9 头图 + 1:1 分享卡"
• "生成一套 social cards / 杂志风社交卡片"
• "把这篇文章做成轮播图文 / 教程拆页"
• "做一套瑞士风的小红书测评 / IKB 风格图文"
• "把这段视频做成小红书 Live Photo / 三连实况拼图"
• "做一个微信公众号文章内 3 秒 Live Photo"

使用流程

Skill 本身是结构化工作流,Agent 会按 7 步走:

1. Intake — 抓 4 件事:目标平台 / 风格 / 内容素材 / 用户图。无图时一次性给 A/B/C 三选(自己拍图 / AI 生图 / 网络取图),不二次劝导
2. Style & Theme — 选 Editorial 还是 Swiss,再从 10 套预设里选主题色。不允许自定义 hex
3. Layout Selection — 根据内容结构从 28 个版式骨架里挑、粘、改文案。Editorial 16 个 / Swiss 12 个
4. Asset Prep — 取图(Unsplash / Pexels / Flickr CC / Wallhaven / 直接搜索),落本地 + 写 SOURCES.md;问用户要不要标来源
5. Compose & Render — 拷种子模板 → 替换 <!-- POSTERS_HERE --> → node render.mjs
6. Deliver & Review — 先把 PNG 给用户看,询问"你自己看还是我先帮你跑 validator",默认不自动核查
7. Iterate — 用户提反馈,改 inline 样式或 swap 版式 / 替图,重渲

Live Photo 请求会在第 5 步进入动态分支:先判断 3s/5s 内能承载的信息量,抽首帧或稀疏 contact sheet 检查裁切,再输出 JPG + MOV + .pvt。交付时会提醒平台限制和发布路径:小红书 5s,微信公众号文章内 3s,通常需要把 .pvt 传到 iPhone 后从对应 App 发布。

详细说明见 SKILL.md。深度细节去看对应 references/*.md。

校验脚本

node validate-social-deck.mjs path/to/task-dir

9 条规则,基于 Playwright 真实渲染测量,不是静态扫描:

• R1 Overflow — 任何 section 超出 .poster 立刻报错,并给出超出像素对应的修正阶梯
• R2 Footer Collision — 内容压到底部 footer / page-number
• R3 Swiss Bold Display — Swiss 大标题违反"越大越细"时报警
• R4 Min Readable Font — 正文、说明、标签字号低于手机可读下限
• R5 4-Band Density — 1440 高画布切 4 横带,每带应有内容或主动留白理由
• R6 H-XL Line Cap — .h-xl / .h-display / .h-statement 行数超出画板预算
• R7 Figure Margin Drift — 浏览器默认 <figure> margin 造成版式漂移
• R8 Visual Bounds — 测量真实可见内容的上/下边界,报告视觉超出和底部空白
• R9 Title Gap — 标题与下一块内容之间的距离过小,避免贴在一起

SKILL.md 第 7 步明确默认不自动跑 validator —— 等用户先看完图再问,避免每轮多花数十秒。

主题色预设

从 references/theme-presets.md 里选一套——不允许自定义 hex 值,保护美学比给自由更重要。

Editorial 6 套

Swiss 4 套

切主题只需替换种子模板的 <section class="poster" data-theme="..."> 属性,所有 CSS 走 var(--...)。

目录结构

guizang-social-card-skill/
├── SKILL.md                              ← Skill 主文件:7 步工作流
├── README.md                             ← 本文件
├── HANDOFF.md                            ← 交接文档:事实 + 版本历史
├── PRODUCT.md                            ← 产品文档:思考 + 决策 + road