Stats
Actions
Tags
Use when the programmer needs to visually understand a system, debug complex behavior, compare architectural approaches, or work through data-heavy decisions. Generates self-contained HTML visualizations using pre-built templates following Edward Tufte's principles. Invoke during brainstorming, architecture decisions, debugging, or when the user asks to "visualize", "see", "map", or "diagram" something.
How this skill is triggered — by the user, by Claude, or both
Slash command
/pair-programming-rounds:tufte-visualizeThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Generate information-dense, interactive HTML visualizations that help programmers reason about their system. Every visualization follows Edward Tufte's principles — maximizing data, minimizing decoration, trusting the viewer's intelligence.
Generate information-dense, interactive HTML visualizations that help programmers reason about their system. Every visualization follows Edward Tufte's principles — maximizing data, minimizing decoration, trusting the viewer's intelligence.
This is a thinking tool, not a charting tool.
Suggest (Claude offers):
Explicit (user requests):
Do not invoke:
Maximize visual elements that convey information. No gradient fills, drop shadows, 3D effects, decorative borders. Grid lines only when they aid reading (lightest gray, #e0e0e0). Labels directly on data, not in separate legends.
When comparing across modules, files, or time: repeat the same visualization with consistent scales. Identical axes and encoding across panels. Shared elements stated once.
Every visualization works at two scales: overview reveals the pattern at a glance, detail available on hover/click without leaving the page. High information density is a feature when the design is sound.
Use whitespace and subtle color differences for separation — never boxes or heavy borders. Color must encode data, never decoration. Maximum 4-5 distinct colors. Typography hierarchy: data labels > annotations > axis labels > titles.
Annotations live adjacent to the data they describe — not in separate panels. Margin notes for extended explanations. No "click here to learn more" indirection.
Visual representation proportional to quantities (Lie Factor near 1.0). Zero baselines for bar charts. Consistent scales. Label data sources and time ranges.
Always use the pre-built templates. The templates are in the templates/ directory adjacent to this subskill's parent skill (i.e., skills/pair-programming-rounds/templates/ relative to the plugin root). Do NOT generate D3 code from scratch. If you cannot locate the template files, ask the user for the plugin installation path.
const DATA = {} with the actual data as a JSON objectTITLE_PLACEHOLDER, SUBTITLE_PLACEHOLDER, CAPTION_PLACEHOLDER, PROVENANCE_PLACEHOLDERdocs/visualizations/round-{N}-{context}-{type}.htmlTitles are questions, captions are answers. A title like "Where does coupling concentrate?" followed by a caption like "The auth module accounts for 60% of cross-module imports" tells the story.
| When the programmer asks... | Template | Data shape |
|---|---|---|
| "What depends on what?" | dependency-map.html | Nodes with ids/labels, edges with source/target/weight |
| "Where is the complexity?" | complexity-dashboard.html | Files with path, directory, and metric values per function |
| "How does data flow?" | data-flow.html | Layers of nodes with transformation edges between them |
| "What breaks if I change this?" | change-impact.html | Tree of files with risk scores (coupling x test coverage gap) |
| "What are the possible states?" | state-machine.html | States with transitions, guards, and happy-path flags |
| "Which approach should we pick?" | comparative-table.html | Rows (approaches) with columns (criteria) and cell values |
| "What happened in what order?" | timeline.html | Events with timestamps, participants, and durations |
| "How big is everything?" | treemap.html | Nested hierarchy with size values and metric colors |
File location: docs/visualizations/ relative to project root.
File naming: round-{N}-{phase-or-context}-{visualization-type}.html
Data embedding: All data embedded directly as JavaScript. No external fetches. Must work as a local file.
Printable: Every visualization includes a data table below the graphic so hover-dependent information is accessible without interaction.
Colorblind-safe: Never use red/green as the only distinguishing colors. Prefer single-hue sequential palettes.
Note in progress file: When a visualization is generated, record it in the Completed Work section of docs/pair-progress.md.
When invoked from the main skill, visualization generation should be dispatched as a subagent task. The subagent:
skills/pair-programming-rounds/templates/The main agent tells the user where to find it and references it in subsequent discussion.
npx claudepluginhub jah2488/pair-programming-rounds --plugin pair-programming-roundsGenerates self-contained HTML pages for technical diagrams, architecture reviews, diff reviews, plans, and comparisons. Renders complex tables as styled HTML instead of ASCII.
Create HTML visualizations from repository documentation, markdown files, plan folders, and user context. Generates maps, flows, diagrams, and recommendation views using Mermaid and custom CSS.
Create SVG-based technical diagrams inside HTML — flowcharts, sequence diagrams, state machines, data-flow diagrams, dependency graphs, request/response timelines. Use whenever the user wants to visualize, illustrate, diagram, or sketch a technical concept, system, or process. Strongly prefer SVG over ASCII art, mermaid blocks, or markdown text for anything spatial or relational. Reach for this whenever an explanation involves arrows, boxes, layers, or sequencing — even when the user doesn't say "diagram".