html_answer_cards v1.0.0

name: "html_answer_cards" description: "Turn an agent's answer into rich, styled HTML cards: safe rendering of model-generated content (escape + sanitize), reusable card templates, responsive grids, and dark-mode theming with CSS tokens. Triggers on 'answer in HTML', 'render as a card', 'HTML answer', 'answer card template', or when agent output needs to be shown as styled HTML."

HTML Answer Cards

Purpose

Make agent answers look good as HTML without shipping XSS. The pattern: structured answer data goes through a fixed card template, every model-generated string is escaped or sanitized before it reaches the DOM, and one token-based stylesheet handles light/dark mode and responsiveness. The result is a self-contained HTML answer a chat surface, page, or email client can drop in as-is.

Workflow

1. Separate data from markup. The agent produces plain answer data (title, kicker, summary, bullet list, key/value facts, links), never raw HTML. The card template in assets/card.html owns the markup; the agent only fills the fields. If the answer needs rich text, the pipeline is: markdown -> sanitize -> insert. Never raw innerHTML of model text.
2. Sanitize before rendering. Treat every model string as untrusted user input (prompt injection is the new XSS). Server-side: escape with html.escape (Python) or template auto-escaping; never mark model content safe. Client-side: run the markdown-converted HTML through DOMPurify with explicit allow-lists, configured AFTER conversion, not before (see references/sanitization.md). Links get a https?/mailto URI allow-list; kill javascript:, event handlers, and style attributes.
3. Build the card from the template. Copy assets/card.html. Use the semantic slots: <article class="card"> with .card-kicker, .card-title, .card-summary, .card-facts (a <dl>), .card-points (a <ul>), .card-actions (links). Do not invent new class names; new visual needs go through modifiers (.card--accent, .card--compact).
4. Theme with tokens, not hardcoded colors. All color comes from assets/cards.css custom properties (--card-bg, --card-text, --card-muted, --card-line, --card-accent). Dark mode is a single override block keyed to prefers-color-scheme: dark plus an optional [data-theme] manual override. Set color-scheme: light dark so native controls follow the theme.
5. Make it responsive from zero. Base styles are single-column, mobile-first. Multi-card layouts use repeat(auto-fill, minmax(min(280px, 100%), 1fr)), which adapts with no breakpoints. Cards reused in sidebars or panels can opt into container queries (container-type: inline-size) so they respond to their box, not the viewport.
6. Validate the output. Run the checks in references/qa-checklist.md: no horizontal scroll at 320px, light and dark both readable (4.5:1 text contrast), no raw <script>/on* in the final HTML, keyboard focus visible on all links, prefers-reduced-motion respected.

Output Contract

An agent applying this skill produces a self-contained HTML answer:

• One document (or embeddable fragment) using assets/card.html structure and assets/cards.css tokens, with no external CSS/JS/fonts unless the host page already provides them.
• All model-generated strings escaped server-side or DOMPurify-cleaned client-side; final HTML contains no javascript: URIs, event-handler attributes, or <script>/<style> elements from model content.
• Readable in light and dark mode, no horizontal scroll down to 320px wide, semantic landmarks (article, headings, dl/ul where they fit).
• For multi-card answers: a .card-grid wrapper; every card is self-contained so cards can be reordered, filtered, or rendered individually.

Operating Rules

• The template owns markup; the agent owns data. Never concatenate model strings into HTML by hand. This is the rule that prevents XSS, and it has no exceptions.
• DOMPurify defaults are a floor, not a policy. Always pass explicit ALLOWED_TAGS, ALLOWED_ATTR, and ALLOWED_URI_REGEXP; tighten the URI list to what the answer actually needs and re-audit it whenever the library bumps (see references for the rationale and a verified config).
• style attributes and <style> tags from model content are always stripped. If a card needs custom styling, add a named modifier class to the template; never honor inline styles from the model.
• No layout that assumes a fixed width. Cards must survive a 320px phone, a narrow chat pane, and full-bleed desktop without edits.
• Keep the CSS token list short and stable. If a new answer needs a color that is not a token, question the answer first; most of the time it maps to an existing token.
• Respect the reader: honor prefers-reduced-motion, keep link text descriptive (never "click here"), and give every image alt text or alt="" when decorative.