# Output Format This file defines the audit's two output modes: - **HTML mode (default)** — a self-contained `.html` file written to the audited project's `motion-audits/` directory and opened in the user's default browser. Each Critical or Important finding gets an auto-looping CSS demo card beside it. - **Terminal mode (flag-triggered)** — the decorated-markdown report rendered inline in the conversation. Use when the user passes `--terminal`, `--inline`, "show the full report inline," "skip the HTML," or any natural-language equivalent. No HTML file is written. The two modes contain the same audit content; only the rendering differs. Do not summarize — users want full per-lens perspectives. --- ## HTML mode ### File structure The HTML output is a single self-contained `.html` document with everything inlined — no external CSS, no external JS, no external fonts (fonts may degrade gracefully if a CDN reference is used). The file scaffolds: ``` {project-name} motion audit — {ISO date} ``` ### Report's own motion posture The report itself has **no** entrance, scroll, or mount animations. No staggered reveals, no fade-in-on-scroll, no motion-on-mount outside the demo cards. The demo cards are the only animated elements in the document — anything else would reproduce the AI-slop patterns the skill audits against. ### Hero header Top of the document. Project name + ISO date + severity counts row + primary lens label. ```html

{project-name} motion audit

{ISO date}

🔴 Critical: {N} · 🟡 Important: {N} · 🟢 Opportunities: {N}

Primary: {Designer Name} — {Perspective Handle}

``` The severity counts pair each emoji with a text label (`Critical: N`, not just `🔴 N`) so the severity signal is readable under red-green color vision deficiency. Each count is an anchor link to the corresponding section in the body — this is the navigation affordance for long audits with many findings. ### Overall Assessment One short paragraph in larger type. Does this feel polished? Too much? Too little? What's working, what's not? ```html

{one-paragraph assessment}

``` ### Per-lens sections Three sections in weighting order: primary, secondary, selective. Each section header pairs the designer name with the perspective handle using an em-dash (`Designer Name — Perspective Handle`): ```html

Emil Kowalski — Restraint & Speed

What's Working Well

✓ {observation} — {file.tsx:line}

Issues to Address

Opportunities

💡 {idea} — {file.tsx:line}

Through Emil's lens: {1-2 sentence summary}

``` The three perspective handles: | Designer | Perspective handle | |---|---| | Emil Kowalski | Restraint & Speed | | Jakub Krehel | Production Polish | | Jhey Tompkins | Experimentation & Delight | Always render section headers as `Designer Name — Perspective` (em-dash). Always close each section with the `Through {Designer}'s lens:` summary — it's a documented lens, not a quote from the person. ### Finding rows (Critical + Important only) Each Critical or Important finding inside an `Issues to Address` block renders as a `.finding-row` with the issue prose on the left and the demo card on the right (two-column at desktop, stacked at narrow widths): ```html

🔴 Critical

{finding title}

{finding explanation}

{file.tsx:line}

↻ looping

{duration} · {easing}

{motion target markup}

``` `{n}` is the finding's 1-indexed position **across the whole report** (not per-section). This guarantees `@keyframes motion-{n}-...` and `.demo-card-{n}__motion-target` selector names are unique across the document, so concatenating multiple findings' CSS in one `