broadsheet-card

name	broadsheet-card
description	Creates validated mobile-first editorial card sets from user-provided topics, outlines, articles, or raw notes. Use for Xiaohongshu/Rednote carousels, WeChat article images, social graphics, self-media explainers, HTML-to-PNG cards, strong covers, CardPlan/ColorPlan planning, design-system guided layouts, and visual quality checks.

Broadsheet Card

Create a mobile-first editorial card set. Treat the task as content editing plus visual publishing: find the point of view, choose a readable mobile platform, map the argument across pages, then typeset and validate the rendered output.

The skill uses one design language from references/DESIGN.md. One language does not mean one template. Keep consistency through type, color, spacing, surfaces, and tactile objects; let each page use the composition that best serves the content.

Production Boundary

Default and best-supported output:

• Platform: Xiaohongshu / Rednote 3:4 carousel
• Canvas: 1080 x 1440 px
• Pages: 4-8, with 6 as the default
• Format: self-contained HTML plus PNG exports

Do not promise perfect WeChat cover or square social output unless the user explicitly asks and the platform spec is added to the plan. Read references/platforms.md before choosing a platform.

Required Workflow

1. Parse the user input into a ContentBrief: topic, audience, use case, source strength, available assets, and desired action.
2. Read references/platforms.md; choose one platform and page size.
3. Read references/DESIGN.md; write a DesignRead.
   • Decide content archetype, reader state, emotional job, evidence role, density, and composition rhythm.
   • Keep clay-editorial as the design language.
   • Choose one or more internal modes: object-led, evidence-led, diagram-led, quote-led, comparison-led, save-led.
4. Read references/copywriting.md; create a CardPlan.
   • Each page needs one main conclusion.
   • Avoid turning every page into a slogan. Include proof, mechanism, or action where the content needs it.
5. Read references/cover-system.md; generate three cover candidates and select one.
6. Read references/color.md; create a ColorPlan.
7. Read references/layout-recipes.md; create a LayoutMap.
   • Pick page skeletons by content need, not by habit.
   • Check capacity and failure modes before writing HTML.
8. CHECKPOINT: Do not write HTML until DesignRead, CardPlan, cover choice, ColorPlan, and LayoutMap agree.
9. Start from templates/base.html and templates/components.css.
   • Use the template as a seed, not as a fixed page sequence.
   • Add custom HTML only when it strengthens the content.
10. Run validation:

• scripts/validate-card-plan.mjs
• scripts/validate-layout.mjs
• scripts/validate-contrast.mjs
• scripts/validate-manifest.mjs

11. Fix failures by rewriting content or layout. Do not shrink critical body text below 28px.
12. Run scripts/render.mjs to export PNGs.
13. Run scripts/make-thumbnail-preview.mjs when image tooling is available.
14. Review against references/quality-rubric.md and deliver the file list plus a short editorial explanation.

Hard Rules

• Never generate HTML directly from a topic. Plan the content first.
• Use one platform size per card set.
• Keep Chinese-first visible text when the source content is Chinese.
• Do not add English mastheads, fake issue metadata, ornamental footers, or repeated rails.
• Do not repeat the same page skeleton across the deck.
• Cover headline must stay readable at 30% preview.
• Body critical text must be 28px or larger.
• Critical text must stay inside the safe area.
• Red accent appears at most twice per page.
• Text must not sit on noisy image or texture backgrounds.
• If content is too long, summarize it. Never fit content by making text tiny.
• Use trusted user assets first. Avoid external fonts, remote CSS, remote scripts, and unsourced images.
• If a requested style harms mobile readability, preserve the intent and adapt it inside the design language.

Page Sequences

Use these as starting rhythms, not fixed templates:

• Judgment guide: cover -> tension -> framework -> proof -> verdict -> checklist
• Tutorial: cover -> promise -> steps -> example -> mistake -> checklist
• Contrarian take: cover -> false belief -> evidence -> new frame -> implication -> summary
• Data explainer: cover -> key number -> context -> interpretation -> consequence -> action
• Product review: cover -> use case -> strengths -> limits -> fit -> verdict
• Notes/book card: cover -> core idea -> quote -> interpretation -> application -> save card

When to Ask or Refuse

Ask for more content if the user gives only a vague theme but expects factual claims. Ask once for images/screenshots if the desired result depends on real visual evidence.

Refuse or redirect requests that require high-stakes advice, fake evidence, unreadable cram layouts, or style mixing that breaks the design system.

Anti-Patterns

Do not create:

• a single reusable newspaper, magazine, or poster template
• pages that are only large slogans without proof or action
• decorative color blocks with no meaning
• generic Canva-like compositions
• old newspaper styling, parchment, scrapbook, or fake archive texture
• fake brand references or copied visual identities
• tiny labels that only decorate
• visible English UI chrome for Chinese-first content
• platform promises that are not backed by a platform spec