AOS/skills/design/social-card.md

name, description, type, output_target, primary_when, avoid_when

name	description	type	output_target	primary_when	avoid_when
social-card	Create fixed-canvas social-distribution visual artifacts delivered as HTML-to-image outputs: Xiaohongshu/Rednote covers and carousel cards, WeChat official account cover pairs, Douyin/video covers, social posters, product brief cards, product update images, launch/feature announcement graphics, report summary cards, knowledge cards, screenshot explainers, quote cards, data cards, hiring/event posters, and mobile-first long images.	artifact-skill	html-to-image	social card 小红书封面 小红书图文 小红书卡片 Rednote carousel 微信公众号封面 视频号封面 抖音封面 社媒海报 知识卡片 长图 截图讲解卡 quote card product brief card product update card product launch card feature announcement card release note image company update card event announcement image hiring poster report summary card data summary card 社媒产品简报 产品更新图 功能发布图 版本说明图 产品发布图 活动预告图 招聘海报 公司动态图 报告摘要图 数据摘要图	full slide deck / PPT / presentation long-form webpage meant for scrolling and reading in-browser pure photo editing with no layout or information design dashboard / web app / operational prototype

Social Card Artifact Skill

Use this skill for fixed-canvas social-distribution visuals that are usually authored in HTML/CSS and exported as images.

The routing signal is not only the platform name. Use this skill when the final medium is a social-ready image or image sequence, even if the content is a product brief, product update, report summary, launch announcement, recruiting card, or event notice.

This skill replaces the narrower xiaohongshu-card.md. Xiaohongshu is now one platform preset inside a broader social-card artifact skill.

Core Principle

A social card is a fixed-canvas communication artifact for social distribution. It may be a cover, carousel, announcement, product brief, report summary, screenshot explainer, data card, recruiting poster, event notice, quote card, or long image. The final medium is image, even when authored as HTML.

A social card is not a mini article and not a poster filled with text.

Each card must have one clear job:

• make the viewer stop;
• explain one point;
• show one piece of evidence;
• compare two things;
• guide one step;
• summarize one conclusion.

Do not squeeze the full article into images. The card set is a visual argument outline. Nuance belongs in caption/body text, not in every card.

Internal Brief Before Design

Before choosing layouts, silently resolve:

social_card_brief:
  platform: xiaohongshu | wechat | douyin | generic-social | unknown
  output_target: html-to-image
  canvas_preset: from canvas-and-device.md
  card_count: single | cover-plus-pages | cover-pair | long-image
  audience:
  content_goal: stop | explain | persuade | teach | summarize | compare | prove | announce | update | brief | recruit | share
  visual_intent:
    mode:
    density:
    title_attitude:
    imagery_strategy:
  assets:
    photos:
    screenshots:
    logos:
    data:
  constraints:

Do not show this YAML to the user unless they ask for routing/debug details.

Ask at most one clarification question, and only when the missing answer changes platform, canvas size, or whether image assets are required.

References (load only when triggered)

This is the artifact-specific reference contract for social-card work. It should be read after the primary route selects social-card.md and before generation.

Always read:

• canvas-and-device.md for platform sizes, fixed-canvas presets, safe areas, and export intent.
• horizontal-craft/chinese-typography.md when the output contains Chinese.

Read conditionally:

• horizontal-craft/reference/title-and-breaking.md for covers, large titles, posters, or cards where title breaking is visually dominant.
• horizontal-craft/reference/fonts.md when font choice materially affects the visual direction: poster title, brand card, editorial report card, classical/literary card, public-document style, industrial/tech title, or typography-led design.
• horizontal-craft/color.md when no design system is provided or the color direction is vague.
• horizontal-craft/icon-system.md when functional icons, badges, status marks, or repeated symbolic markers are used.
• horizontal-craft/data-integrity.md for numbers, charts, rankings, market size, ROI, benchmark, dashboard screenshots, or KPI cards.
• horizontal-craft/link-and-proof.md for customer logos, citations, source claims, awards, press mentions, or external proof.
• horizontal-craft/anti-ai-slop.md before final review, not as the primary creative director.

Do not read every reference by default. Read only what the card task needs.

Platform Presets

Platform determines canvas and safe-area behavior. It does not determine the visual style by itself.

Xiaohongshu / Rednote

Use for:

• cover image;
• carousel card set;
• knowledge card sequence;
• recommendation / review / tutorial / checklist;
• screenshot explainer.

Rules:

• Prefer 3:4 portrait unless the user asks for square or a known alternative.
• Cover must communicate the value within one glance.
• Use one idea per page.
• Avoid tiny body copy; cards are read on phones.
• Use 4–8 pages for most carousel posts when the user asks for a set.
• End with a summary, checklist, key takeaway, or share/save reason when useful.

WeChat Official Account Cover Pair

Use when the user asks for 微信公众号封面, 公众号首图, article cover pair, or both main + square cover.

Rules:

• Generate a coordinated pair: one wide main cover and one square cover.
• The wide cover can carry the longer title, subtitle, and visual relation.
• The square cover must use a compressed short title. Do not squeeze the full title into the square.
• Build both covers as related but separately composed designs, not as blind crops.

Douyin / Video / Video Account Cover

Use when the user asks for 抖音封面, 视频号封面, short-video cover, or vertical video thumbnail.

Rules:

• Title must survive thumbnail scale.
• Keep important text away from interface overlay zones where applicable.
• Use stronger focal contrast than article cards.
• Avoid long subtitles.

Generic Social Poster / Card

Use when platform is not fixed.

Rules:

• Infer a canvas preset from the output target, but avoid pretending it is platform-specific.
• If the platform changes later, recompute composition rather than mechanically resizing.

Route Boundaries

Route by final medium, not topic keyword alone.

• If the user wants a full web landing page, use landing-page.md.
• If the user wants a slide presentation, use deck.md.
• If the user wants a product interface prototype, use prototype.md.
• If the user wants a social-distribution image, image sequence, cover, poster, product brief image, update card, or long image, use social-card.md.
• If the user says “产品简报 / 周报 / 报告摘要 / 发布图” without specifying slides or webpage, prefer social-card.md when the deliverable is clearly image-first.

Content Role Planning

Plan pages by role before designing. Repetition is the main failure mode.

Common roles:

• Hook Cover — stop the viewer with a sharp title and one dominant visual.
• Problem Scene — show the pain, mistake, or tension.
• Misconception vs Reality — contrast what people think with what is true.
• Checklist — scannable criteria or action list.
• Comparison — before/after, A/B, old/new, tool/tool, plan/plan.
• Step Flow — a process, workflow, route, or sequence.
• Screenshot Evidence — product/UI/code screenshot with clear framing and annotation.
• Data/KPI Card — one metric family, trend, or ranking.
• Product Brief — one product/update/message compressed into a visual brief.
• Feature Announcement — one feature, one benefit, one proof point, screenshot, or CTA.
• Release Note — version/update summary with clear hierarchy.
• Event / Campaign — time, offer, action, and visual hook.
• Hiring / Recruiting — role, reason to join, requirements, and CTA.
• Report Summary — one finding or section from a longer report.
• Company Update — milestone, partnership, launch, funding, community, or announcement.
• Quote / Thesis — one large sentence as the page subject.
• Image-Led Cover — strong photo first, restrained title.
• Map / Spatial Card — route, places, district, store map, walking guide.
• Summary Card — final takeaway, three-point recap, or save/share reason.

Hard rule: one card = one role. If a card tries to be cover + explanation + proof + CTA, split it.

Style Mode Selection

Pick one visual mode per card set. Do not mix unrelated systems inside the same package.

Editorial Card

Use when the content should feel:

• magazine-like;
• literary / reflective;
• lifestyle / travel / culture;
• slow, considered, tactile;
• quote-led or image-led.

Typical signals:

• paper or ink atmosphere;
• serif/Songti/Mingcho title attitude;
• large photo well;
• marginal notes;
• pull quote;
• restrained palette;
• subtle texture.

Do not use it for high-density tool dashboards, KPI-heavy posts, or sharp product release cards unless the user asks for editorial contrast.

Swiss Card

Use when the content should feel:

• structured;
• systemized;
• data-led;
• product/release focused;
• workplace / AI tools / methods / comparison;
• engineered and decisive.

Typical signals:

• strong grid;
• numbered statements;
• one accent color;
• hairline rules;
• KPI blocks;
• table/matrix structure;
• left alignment;
• high contrast.

Do not make Swiss cards heavy and bold by default. Swiss display titles can be large, but the system should remain precise.

Product Brief / Product Update

Use when the content is a product brief, feature launch, release note, company update, report summary, campaign card, or recruiting/social announcement.

Default treatment:

• For feature updates, release notes, tool explainers, and product briefs, start from Swiss Card or Screenshot Explainer logic.
• For data-backed updates or report summaries, start from Data/KPI Card logic.
• For brand story, founder note, community update, lifestyle campaign, or culture/recruiting story, Editorial Card may be stronger.
• Product cards should clarify one message first, then support it with screenshot, proof, metric, date, or action.
• Do not make product announcements look like full landing pages compressed into one image.

Image-Led Card

Use when the user supplies a strong photo, product image, or scene image that should carry emotion.

Rules:

• Let one image dominate.
• Use title placement based on safe zones.
• Do not place text over faces, hands, product UI, or key objects.
• Do not rely on a full-canvas black gradient to rescue a bad image.

Screenshot Explainer

Use for:

• app / web / code / dashboard screenshots;
• AI tool tutorials;
• product update posts;
• workflow explanation.

Rules:

• Do not paste screenshots naked.
• Use a frame, browser/device chrome, stage, zoom, callout, crop, or annotation.
• Screenshot readability beats decorative layout.
• If screenshot text matters, enlarge the screenshot and reduce surrounding copy.

Data / KPI Card

Use when numbers are the story.

Rules:

• One metric family per card.
• Explain the metric context; do not show fake precision.
• Mark demo/placeholder data clearly.
• Avoid decorative charts with no readable axis, label, or conclusion.

Map / Travel Card

Use only when spatial relationships matter: route, neighborhood, stores, walking plan, location comparison.

Rules:

• Use a real static map when real geography matters.
• Use schematic map only for conceptual relations.
• Do not use a live JS map inside the exported image.

Layout Recipe Selection

Use layout recipes as grammar, not as templates to copy.

Map content intent to layout family:

Intent	Good layout family
Strong cover hook	Issue cover, hero title, image-led cover, hero question
One big thesis	Pull quote, statement page, manifesto card
Many criteria	Checklist, ledger, matrix
Step-by-step	Vertical pipeline, numbered flow, process cards
A/B comparison	Two-column comparison, before/after split, difference table
Product/UI proof	Screenshot frame, browser/device mock, zoom annotation
Product brief / update	Feature brief, release note stack, screenshot + benefit, announcement card
Event / hiring / campaign	Poster hierarchy, date-role-action block, campaign hero
Report summary	Finding card, executive brief, KPI + takeaway, insight stack
Data summary	KPI tower, bar comparison, ranking list, single-chart card
Travel/spatial	Map block, route list, field-note photo
Lifestyle/photos	Image-led cover, photo well, field-note page
Closing	Summary, remember-three, final quote, save card

Do not reuse the same layout family across every page. A good carousel has rhythm.

Cover Title Compression

Covers need short, visual titles.

Rules:

• Prefer 4–14 Chinese characters when possible.
• Preserve the core object and strongest action.
• Remove explanations, long modifiers, background clauses, and vague hype.
• Split into 2–3 intentional lines when needed.
• Do not force a full article title into a cover.
• If the title is long, create hierarchy: main hook + small clarifier, not one giant sentence.

Examples of compression direction:

• 开源了一个 Skill，让 AI 接管你屏幕边那张便签纸 → AI 接管便签纸
• 普通人如何理解 AI Agent 和聊天机器人的区别 → Agent 不只是聊天
• 为什么你做的 AI 产品总是没人愿意第二次打开 → 为什么没人再打开

This is layout adaptation, not copywriting polish. Do not invent claims the content does not support.

Image And Screenshot Treatment

Photo / Image Overlay

Before placing text on an image:

1. Identify the subject and quiet zones.
2. Keep title away from faces, hands, product features, UI text, and important objects.
3. Try composition first; use localized tint only when needed.
4. Avoid default full-canvas dark overlays.
5. Set image crop deliberately. Do not rely on object-position:center for every image.

If the photo cannot support text, use a split layout or framed image instead of forcing overlay.

Screenshot Handling

• Preserve UI content unless the user asks for redesign.
• Use object-fit: contain for screenshots with text, code, dense UI, tables, or app windows.
• Use object-fit: cover only when cropping is safe.
• Add frame, shadow, stage, browser/device chrome, or inset background.
• Prefer one strong screenshot per card over several unreadable tiny screenshots.
• Make callouts spatially close to the UI area they explain.

Portrait Fill Rules

For 3:4 portrait cards, avoid under-filled vertical space.

A card fails if it has a large empty vertical band with no visual reason.

Use one of these fixes:

• enlarge the focal image;
• increase title scale;
• add a quote column;
• add a ledger/list block;
• add evidence image or screenshot;
• add a secondary annotation zone;
• switch to a more suitable layout;
• reduce card count and combine thin pages.

Do not fix under-filled cards by adding random blobs, stickers, gradients, or decorative noise.

Multi-Card Sequence Rhythm

For card sets, vary roles and density.

Recommended rhythm:

01 Cover / hook
02 Problem or context
03–05 Explanation, comparison, checklist, proof, screenshot, data
06–08 Application, examples, workflow, mistakes
Last Summary / save reason / final thesis

Rules:

• Do not make every page title + bullets.
• Do not put two full-bleed image covers back to back unless the user explicitly wants a photo essay.
• After an image-heavy cover, use a more structured text/data card to let the eye settle.
• If the user asks for one card only, make it self-contained: hook + focal visual + 1–3 supporting fragments.

Template Relationship

If a social-card template exists:

• Read the template SKILL.md / .md first.
• Do not read pattern.html by default.
• Read pattern.html only when the markdown lacks layout/interaction detail or the card requires a complex layout reference.
• When reading pattern.html, extract only layout relationships, section rhythm, component relationships, and responsive/canvas behavior.
• Do not copy DOM structure, class names, CSS tokens, placeholder content, or visual styling wholesale.

Templates are starting points. This skill decides whether the card needs editorial, Swiss, image-led, screenshot, data, or map treatment.

HTML-To-Image Implementation Contract

File structure is decided by card_count:

• single → one self-contained HTML file. Inline all styles. No shared assets.
• multi-card carousel, cover-plus-pages, or WeChat cover pair → one HTML file per card, plus a shared design-token stylesheet and a preview page.

Per-card file rules (multi-card sets)

• Each card is its own HTML file. The <body> is the canvas: set explicit width/height from canvas-and-device.md, no outer wrapper page, no scrolling.
• All cards in one package link the same shared/tokens.css. It is the single source of truth for colors, fonts, spacing scale, and the canvas reset (margin resets for body, figure, h1, p, ul, etc.).
• Card files may add card-private layout CSS, but must not override global tokens locally. Hardcoded colors/fonts that duplicate or contradict tokens are a defect.
• Mixed canvas sizes in one task (e.g. WeChat 21:9 + 1:1 pair) are handled naturally: each file declares its own body dimensions; never share one body size across different presets.
• Generate preview.html that embeds every card via <iframe> in reading order, scaled to fit. It exists for sequence-rhythm review only and is not a deliverable.
• Editing or regenerating one card must touch only that card's file (and never shared/tokens.css unless the change is intentionally package-wide).

Shared rules (all cases)

• Use explicit canvas dimensions from canvas-and-device.md.
• Keep safe areas and platform UI overlays in mind.
• Make text selectable in source HTML but visually composed as an image.
• Export = set viewport to the card's canvas dimensions and take a full-page screenshot of body. Do not use element/node clipping; it is fragile with transforms, shadows, and devicePixelRatio.
• Export images in stable order and with stable names, matching their source files.

Suggested structure and naming:

output/
  shared/tokens.css
  card-01-cover.html
  card-02-<topic>.html
  preview.html
  social-01-cover.png
  social-02-<topic>.png

For WeChat cover pairs:

output/
  shared/tokens.css
  wechat-21x9-cover.html
  wechat-1x1-cover.html
  preview.html
  wechat-21x9-cover.png
  wechat-1x1-cover.png
  wechat-cover-pair-preview.png

Handoff

Social cards are authored as HTML but normally delivered as images.

Default handoff:

• Save the editable HTML source as the source of truth: one self-contained file for single cards; per-card files plus shared/tokens.css for sets.
• Export the final card or card sequence as PNG unless the user asks for JPG/PDF/ZIP.
• Preserve the selected canvas preset from canvas-and-device.md.
• For multi-card sequences, export one image per card file and keep ordering stable; card files and exported images can be generated and exported in parallel.
• If the user later asks to revise one card, regenerate only that card's HTML file and re-export only that image.
• For WeChat cover pairs, deliver both the main wide cover and the square cover.
• Do not deliver only a scrollable webpage when the user asked for a social card, cover, poster, carousel, or long image.
• If image export is not available in the current step, still structure the HTML so it can be captured cleanly later and state that export remains pending.

Use the standard export.md flow for actual image/PDF/ZIP packaging. Use the standard Design Skill version-management flow only when an editable HTML entry file is delivered as a web project.

Quality Checks

Run quality-gate.md as the shared blocking check first. On top of it, this skill adds social-card-specific checks before delivery:

• correct platform size and ratio;
• title readable at phone thumbnail size;
• no text overflow;
• no accidental edge touching;
• one focal point per card;
• product/update/report cards have one clear message, not a compressed landing page;
• Chinese title breaks intentionally;
• screenshots remain readable;
• images are not distorted;
• no important face/object/UI cropped accidentally;
• no fake data, invented customer logos, or unsupported claims;
• card set does not repeat the same layout page after page;
• 3:4 portrait cards do not have unjustified empty lower space;
• style mode stays consistent across a package;
• in multi-card sets, every card file links the same shared/tokens.css, with no local hardcoded colors/fonts that duplicate or contradict tokens;
• every card file's body dimensions match its declared canvas preset;
• no random decorative blobs, stickers, gradients, or emoji icons unless required by the chosen visual language.

Common Failure Cases

Avoid:

• treating a social card as a compressed article, landing page, or slide deck;
• turning a product brief into a tiny website screenshot full of sections;
• every page using the same title-plus-bullet structure;
• putting long subtitles on covers;
• using tiny Chinese text on mobile images;
• hiding screenshot evidence behind decoration;
• using stock/photo/generative images as filler rather than evidence;
• mixing editorial serif paper style with Swiss KPI grid without intent;
• making every social image look like a Xiaohongshu template when the platform is WeChat, Douyin, or generic;
• copying pattern.html instead of adapting the pattern;
• adding visual noise to solve empty composition;
• letting per-card files drift stylistically because tokens were redefined locally instead of read from shared/tokens.css;
• rebuilding the entire card set when the user asked to change one card.

Scope Pushback

Be honest when the request is mostly photography, not card design.

Push back or ask for assets when the user wants:

• outfit/body-shot OOTD images;
• food-plating photography showcase;
• pure aesthetic/dreamcore mood images;
• celebrity/person-specific imagery without supplied assets;
• product photo results where the product image is the entire deliverable.

Offer a layout direction using user-supplied photos/screenshots, sourced images, or generated images only if appropriate.