|
| 1 | +--- |
| 2 | +name: plannotator-visual-explainer |
| 3 | +description: > |
| 4 | + Generate beautiful, self-contained HTML visualizations themed with Plannotator's design system. |
| 5 | + Wraps the visual-explainer skill by nicobailon with Plannotator theme token integration. Use for |
| 6 | + architecture diagrams, diff reviews, plan reviews, data tables, slide decks, project recaps, or |
| 7 | + any visual explanation of technical concepts — whenever you want output styled consistently with |
| 8 | + Plannotator's UI and compatible with --render-html annotation. Triggers on the same prompts as |
| 9 | + visual-explainer (diagrams, architecture overviews, visual plans, diff reviews) but produces |
| 10 | + output that uses Plannotator CSS custom properties instead of custom palettes. |
| 11 | +--- |
| 12 | + |
| 13 | +# Plannotator Visual Explainer |
| 14 | + |
| 15 | +This skill wraps [visual-explainer](https://github.com/nicobailon/visual-explainer) by Nico Bailon with Plannotator theme integration and additional component patterns. You follow visual-explainer's workflow, references, templates, and anti-slop rules — with Plannotator's color/typography tokens and extended patterns for plans and technical documents. |
| 16 | + |
| 17 | +## Setup |
| 18 | + |
| 19 | +Before generating, ensure `visual-explainer` is available: |
| 20 | + |
| 21 | +1. Check if the skill exists at any of these paths (in order): |
| 22 | + - `~/.claude/skills/visual-explainer/SKILL.md` |
| 23 | + - `~/.agents/skills/visual-explainer/SKILL.md` |
| 24 | + - `~/.codex/skills/visual-explainer/SKILL.md` |
| 25 | + |
| 26 | +2. If not found, install it: |
| 27 | + ```bash |
| 28 | + npx skills add nicobailon/visual-explainer -g --yes |
| 29 | + ``` |
| 30 | + |
| 31 | +3. Read the visual-explainer `SKILL.md` to absorb its full workflow, diagram type routing, structure rules, and anti-slop guidelines. Read its `references/` and `templates/` as directed by its workflow. |
| 32 | + |
| 33 | +## Theme Override |
| 34 | + |
| 35 | +Instead of visual-explainer's custom palettes and font pairings, use Plannotator's semantic theme tokens. Read `references/theme-override.md` for the exact CSS custom properties and mapping table. Apply these **after** reading visual-explainer's references — they replace only the color and typography layer. |
| 36 | + |
| 37 | +## Extended Patterns |
| 38 | + |
| 39 | +Plannotator adds component patterns that complement visual-explainer's toolkit. Read `references/extended-patterns.md` for timelines, inline SVG diagrams, code blocks with syntax highlighting, risk tables, and open question callouts. Use these alongside Nico's `.ve-card`, `.kpi-card`, `.pipeline` components — they share the same theme tokens. |
| 40 | + |
| 41 | +## Design Philosophy: Use the Power of HTML |
| 42 | + |
| 43 | +The point of generating HTML instead of markdown is spatial layout. Don't pack every piece of information into dense cards. Let the page breathe. |
| 44 | + |
| 45 | +- **Whitespace is a feature.** Generous padding, large section gaps, breathing room between cards. If a section feels cramped, it needs more space, not smaller text. |
| 46 | +- **One idea per viewport.** The reader should be able to absorb one concept at a time as they scroll. A hero section, then a diagram, then a detail grid — not all three crammed together. |
| 47 | +- **Visual weight signals importance.** Hero sections dominate (large type, accent-tinted backgrounds, more padding). Supporting details are compact and can collapse. Not everything deserves equal treatment. |
| 48 | +- **Show, don't describe.** A timeline shows sequencing. A diagram shows relationships. A before/after grid shows change. A code block shows the interface. Use the right visual element — don't describe things in prose that a component could show directly. |
| 49 | +- **Timelines show sequence without estimates.** Show the phases and their dependencies, but do not attach hour/day/week estimates. AI consistently misjudges timing. Showing phases in order communicates sequencing; attaching numbers communicates false precision. |
| 50 | + |
| 51 | +## Workflow |
| 52 | + |
| 53 | +1. **Read** visual-explainer's SKILL.md (full workflow, diagram types, quality checks) |
| 54 | +2. **Read** the relevant visual-explainer references and templates for your content type |
| 55 | +3. **Read** `references/theme-override.md` for Plannotator color/typography tokens |
| 56 | +4. **Read** `references/extended-patterns.md` for additional components (timelines, code blocks, risk tables, SVG diagrams) |
| 57 | +5. **Generate** following visual-explainer's structure and rules, with Plannotator tokens and extended patterns. Use Nico's component classes (`.ve-card`, `.ve-card--hero`, `.kpi-card`, `.pipeline`, etc.) for cards and layout. Use the extended patterns for timelines, code blocks, risk tables, and SVG diagrams. |
| 58 | +6. **Deliver** via Plannotator's annotation UI: |
| 59 | + |
| 60 | +**If the output is a plan or proposal** (something the user should approve/deny): |
| 61 | +```bash |
| 62 | +plannotator annotate <file> --render-html --gate |
| 63 | +``` |
| 64 | + |
| 65 | +**If the output is a visual explainer, diagram, or informational page:** |
| 66 | +```bash |
| 67 | +plannotator annotate <file> --render-html |
| 68 | +``` |
| 69 | + |
| 70 | +Always use `--render-html` so the HTML renders as-is in the Plannotator UI with theme inheritance and annotation support. Do NOT use `open` or `xdg-open` directly. |
| 71 | + |
| 72 | +## What visual-explainer provides (do not duplicate) |
| 73 | + |
| 74 | +All of these come from visual-explainer — read them there, don't reinvent them: |
| 75 | +- Diagram type routing (architecture, flowchart, sequence, ER, state, mind map, etc.) |
| 76 | +- Mermaid integration (theming, zoom controls, scaling, layout direction) |
| 77 | +- CSS structural patterns (ve-card, grids, connectors, depth tiers, collapsibles) |
| 78 | +- Slide deck mode (viewport-snapping presentations) |
| 79 | +- Data table patterns (sticky headers, status indicators, responsive scrolling) |
| 80 | +- Anti-slop rules (forbidden fonts, colors, animations, patterns) |
| 81 | +- Quality checks (squint test, swap test, overflow protection) |
| 82 | +- Animation guidelines (staggered entrance, reduced-motion support) |
| 83 | + |
| 84 | +## Plan-specific guidance |
| 85 | + |
| 86 | +When the output is an implementation plan, design doc, or proposal: |
| 87 | + |
| 88 | +**Adapt the visual vocabulary to the task:** |
| 89 | +- **Backend/API work**: Lead with data flow diagrams, schemas, API signatures |
| 90 | +- **Frontend/UI work**: Lead with mockups, component hierarchy, state flow |
| 91 | +- **Infrastructure/DevOps**: Lead with architecture diagrams, deployment flow |
| 92 | +- **Refactoring**: Lead with before/after diagrams showing structural change |
| 93 | +- **Cross-cutting features**: Lead with a system map showing all touchpoints |
| 94 | + |
| 95 | +**Section menu — pick what fits:** |
| 96 | +Solution overview, architecture/data flow diagram, UI mockups, key code, integration points, risks & mitigations, open questions, considerations & rationale, reusability & code quality. Not every plan needs every section — choose what serves the content. |
| 97 | + |
| 98 | +**What NOT to include in plans:** |
| 99 | +- Time estimates (timelines showing sequence are fine, hour/day estimates are not) |
| 100 | +- Boilerplate sections that would just say "N/A" |
| 101 | +- Exhaustive file lists — show the important files, not every file touched |
| 102 | + |
| 103 | +**Quality bar for plans:** The plan should answer "what are we building, why, and how" within 30 seconds of reading. |
| 104 | + |
| 105 | +## PR explainer guidance |
| 106 | + |
| 107 | +When the output is a PR walkthrough, diff review, or code change explainer: |
| 108 | + |
| 109 | +- **TL;DR first** — a bordered card summarizing what the PR does and why, so readers who skim get the gist |
| 110 | +- **Risk map** — visual chips showing which files need careful review vs. which are mechanical |
| 111 | +- **Inline diffs** — use the diff rendering pattern from `references/extended-patterns.md` for important hunks (not every hunk) |
| 112 | +- **File-by-file commentary** — collapsible cards per file with a "why" paragraph explaining the purpose of changes |
| 113 | +- **"Where to focus"** — numbered callouts telling reviewers exactly what to look at and why |
| 114 | +- **Before/after comparison** — two-column grid for behavior changes |
| 115 | + |
| 116 | +See `references/extended-patterns.md` for diff rendering, review comment bubbles, and file badge patterns. |
| 117 | + |
| 118 | +## What this skill adds |
| 119 | + |
| 120 | +- Plannotator theme tokens (colors, typography, radii) — see `references/theme-override.md` |
| 121 | +- Extended component patterns (timelines, code blocks, risk tables, SVG diagrams, open questions) — see `references/extended-patterns.md` |
| 122 | +- Plan-specific guidance (section menu, adaptation by task type, quality bar) |
| 123 | +- `--render-html` delivery with annotation support and theme inheritance |
| 124 | +- Design philosophy emphasizing spatial layout, breathing room, and visual hierarchy |
0 commit comments