CtrlK
BlogDocsLog inGet started
Tessl Logo
SkillPublic

visual-explainer

Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data. Use when the user asks for a diagram, architecture overview, diff review, plan review, project recap, comparison table, or any visual explanation of technical concepts. Also use proactively when you are about to render a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead.

66

Quality

83%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide
SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

81%Weight 40%Scale 1-5

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

A highly actionable, well-sequenced skill body: concrete palettes, commands, templates, decision tables, and a real validation checklist with a regeneration loop. The main costs are repetition (forbidden lists and Mermaid rules restated across sections), four dangling ./templates/*.html references that don't exist in the bundle, and inline bulk (slide-deck mode, anti-patterns) that belongs in the reference files.

Suggestions

Deduplicate: state the forbidden fonts/colors/animations and the ASCII-table proactive rule once (e.g. keep them only in the Anti-Patterns section) and reference that section elsewhere instead of restating them 2-3 times.

Fix or remove the four broken ./templates/*.html references (architecture.html, mermaid-flowchart.html, data-table.html, slide-deck.html) — they point at files not present in the bundle, so 'read the reference template' steps will fail.

Move the Slide Deck Mode details (slide types, presets, compositional rules) into ./references/slide-patterns.md, which the body already instructs reading, to slim the main file toward a navigable overview.

DimensionReasoningScore

Conciseness

The body is mostly non-obvious, genuinely useful guidance (exact palettes, font pairings, the stateDiagram-v2 parser caveat, the .node CSS collision constraint) rather than explanations of things Claude already knows, but it is noticeably repetitive: the forbidden font/color lists appear nearly verbatim in both "3. Style" and "Anti-Patterns", the ASCII-table proactive rule appears three times (intro, "Prose patterns" area, Data Tables), and Mermaid TD-vs-LR and zoom-control guidance are each repeated across multiple sections. This lands on anchor 3 ("Mostly efficient but... could be tightened") — above anchor 2's padded explanations, below anchor 4's minor trimmings.

3 / 5

Actionability

Guidance is copy-paste ready throughout: exact hex palettes ("Terracotta + sage (#c2410c, #65a30d)"), named font pairings, a rendering-approach decision table keyed by content type, executable shell commands ("open ~/.agent/diagrams/filename.html", "xdg-open", "which surf", base64 encoding with macOS/Linux variants), a complete HTML file skeleton, and CSS theming snippets. This matches anchor 5 ("Fully executable; copy-paste ready code or commands; specific examples cover the common cases") and clearly exceeds anchor 4's "minor gaps".

5 / 5

Workflow Clarity

The four-step workflow (Think → Structure → Style → Deliver) is clearly sequenced, includes mandatory pre-generation checkpoints ("Read the reference material before generating" with per-content-type file routing), and ends with an explicit pre-delivery validation checklist ("Before delivering, verify: ... Both themes ... No overflow ... File opens cleanly: No console errors") plus a regeneration feedback loop ("If two or more of these are present, the page is slop. Regenerate with a different aesthetic direction"). This matches anchor 5's explicit validation steps, feedback loops, and checklists for complex processes; operations here are not destructive/batch, so no cap applies.

5 / 5

Progressive Disclosure

Structure is good: all four references/*.md files exist, are one level deep, and are clearly signaled with routing rules ("For pages with 4+ sections, also read ./references/responsive-nav.md"; slide mode gated on explicit opt-in with its own reference). However, the body repeatedly points to ./templates/architecture.html, ./templates/mermaid-flowchart.html, ./templates/data-table.html, and ./templates/slide-deck.html — none of which exist in the bundle — and ~400 lines of slide-deck and anti-pattern detail are inlined that could live in the existing reference files. This fits anchor 4 ("Good structure; most content is appropriately placed; references mostly clear; minor organization gaps") rather than anchor 5's clean navigable split, and is well above anchor 3's buried references.

4 / 5

Total

17

/

20

Passed

Description

78%Weight 40%Scale 1-5

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

A strong description with an explicit what, an explicit and unusually thorough when-clause including proactive trigger thresholds, and natural trigger terms. Main deductions: the second-person clause in the proactive trigger (mandated specificity penalty) and some trigger-synonym gaps.

Suggestions

Rewrite the proactive trigger in third person, e.g. "Also use proactively before rendering a complex ASCII table (4+ rows or 3+ columns) — present it as a styled HTML page instead" to avoid the second-person specificity penalty.

Drop the filler adjective "beautiful" and add one or two concrete capability verbs (e.g. "render", "illustrate") alongside "Generate" to broaden action coverage.

Add missing natural synonyms such as "visualization", "chart", or "flowchart" to the trigger list to lift trigger-term coverage toward comprehensive.

DimensionReasoningScore

Specificity

"Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data" names the domain and a concrete primary action, which would otherwise rate 4, but the clause "Also use proactively when you are about to render a complex ASCII table" is second-person voice and the rubric mandates a 1-point specificity penalty for that. "beautiful" is also mild fluff. It sits above anchor 2 ("Names the domain but actions are minimal or generic") because the output form and content types are concrete, and below anchor 4 because of the voice penalty and single-verb action coverage.

3 / 5

Completeness

Both questions are answered explicitly: what — "Generate beautiful, self-contained HTML pages that visually explain systems, code changes, plans, and data"; when — "Use when the user asks for a diagram, architecture overview, diff review... or any visual explanation" plus a proactive trigger for ASCII tables with a concrete threshold ("4+ rows or 3+ columns"). This matches the anchor-5 example structure (what + explicit 'Use when' with concrete trigger phrases) and exceeds anchor 4, which requires only a less-explicit 'when'.

5 / 5

Trigger Term Quality

Triggers include natural phrases users would actually say: "diagram", "architecture overview", "diff review", "plan review", "project recap", "comparison table", "visual explanation of technical concepts". Coverage is good but misses common synonyms and variations ("visualization", "chart", "flowchart", "draw me"), so it falls between anchor 4 and anchor 5's "comprehensive coverage of natural terms including synonyms and file extensions" — clearly above anchor 3's "some relevant keywords but missing common variations".

4 / 5

Distinctiveness Conflict Risk

The niche (self-contained HTML visual explainers) is mostly distinct with dedicated triggers, but "diff review", "plan review", and "project recap" overlap with review/recap skills, and the proactive any-ASCII-table trigger is broad enough to fire during many other skills' output formatting. Fits anchor 4 ("Mostly distinct; minor overlap risk with closely related skills") better than anchor 5's minimal-conflict bar or anchor 3's routine overlap.

4 / 5

Total

16

/

20

Passed

Validation

100%

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository

marchatton/agent-skills

Path

.agents/skills/00-utilities/visual-explainer/SKILL.md

Reviewed

Table of Contents

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.