Stats
Actions
Tags
From explain-this
Use when creating an interactive educational article, explainer, or distill-style essay - a single self-contained HTML page with hand-built canvas figures the reader can interact with. Covers articles built from user-provided files (paper, blog post, transcript, research report), topic-driven articles needing web research, and the mix of both. Trigger phrases include "make an explainer", "turn this paper into an interactive article", "build a distill-style essay", "explain X visually", or any request to produce an interactive HTML walkthrough with hand-rendered canvas figures. For explaining a codebase or source files, use explaining-codebases instead. Use even when the user describes the goal without naming the format - if they want an interactive, narrative article with figures the reader can play with, this skill applies.
How this skill is triggered — by the user, by Claude, or both
Slash command
/explain-this:creating-explainersThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
This skill produces a **single self-contained HTML article** in the style of distill.pub - serif typography, a sticky two-column layout, and hand-built Canvas figures the reader can interact with. The output is one `index.html` file that opens directly in a browser; no parent project, no build step, no shared infrastructure required.
This skill produces a single self-contained HTML article in the style of distill.pub - serif typography, a sticky two-column layout, and hand-built Canvas figures the reader can interact with. The output is one index.html file that opens directly in a browser; no parent project, no build step, no shared infrastructure required.
Core constraints (non-negotiable):
<style> block in <head>; all JS at the bottom of <body>. The only external network requests are Google Fonts.references/figure-archetypes.md).references/voice-and-style.md before drafting prose.If you find yourself reaching for a framework or asking "should I just use React for this", stop. The constraint is the point.
Use whenever the user asks to:
Don't use for:
explaining-codebasesIntake is one phase: gather what the article is built from. The material can be given files, web research, or both. Pick the references that apply and read them when you reach this phase, not upfront.
| You have | Read | Source of truth |
|---|---|---|
| Files (paper, URL, paste, transcript, report) | references/intake-from-files.md | The provided document(s) |
| Only a topic | references/intake-from-research.md | Web research, then synthesis |
| Files and a topic that needs more | both | Files as spine, research as supporting |
Mixed intake. When the user provides files and the topic also needs material the files do not cover (recent developments, criticisms, corroboration), read both references and combine them via spine-vs-supporting. Synthesize across everything into one outline and one article.
If you only have a topic and web search is unavailable, ask the user to paste sources. Do not write a technical explainer from training data alone.
The article is too rich to one-shot. Work in stages and check in with the user.
1. Intake -> gather material (files, research, or both)
2. Research-time fact-check -> if you researched, verify sources before drafting (REQUIRED)
3. Outline -> propose sections + figure list, get user approval
4. Scaffold -> copy template, fill metadata
5. Prose pass -> write all sections with figure placeholders
6. Figures pass -> implement each interactive figure
7. Post-draft fact-check -> audit every claim against its source (REQUIRED, blocking)
8. Polish -> captions, cross-links, mobile check
Pause for user approval after the outline (step 3). This is the highest-leverage check-in - if the outline is wrong, everything after it is wasted work. Show the user: title, subtitle, section list with one-line summaries, and a numbered figure list with what each figure shows and how the reader interacts with it.
Steps 2 and 7 are gates, not suggestions. Use fact-checking-explainers. The article is not done until the post-draft fact-check returns zero unresolved claims - every checkable claim is supported. See the Quality Checklist.
Don't pause between the other steps unless something is genuinely ambiguous. Show progress, don't ask for permission to keep working.
Every article has the same skeleton. Use assets/article-template.html as the starting point - copy it to the output path and fill in the marked {{PLACEHOLDERS}}. Don't try to rebuild this structure from scratch; it captures invariants (DPR-aware canvas init, sidebar scroll-tracking, responsive breakpoints) that are easy to get wrong.
The skeleton provides:
initCanvas() utility (DPR-scaled, returns CSS dimensions)See references/template-walkthrough.md for what every block in the template does and where to fill in your content.
Each interactive figure is a self-contained IIFE:
(function() {
const { canvas, ctx, w, h } = initCanvas('canvas-myfig');
let state = { /* ... */ };
function draw() { /* render */ }
function step() { /* advance state */ }
document.getElementById('myfig-step').addEventListener('click', () => { step(); draw(); });
draw();
})();
State lives in closure variables, not globals. There's exactly one shared utility: initCanvas(id), defined once near the top of the script block.
Most figures fall into one of a few archetypes. Pick the closest and adapt:
requestAnimationFrame loop with time accumulatorCode templates and the math for each are in references/figure-archetypes.md. Read it when implementing a figure - the 3D archetype in particular has subtle correctness issues (back-face culling sign, painter's algorithm tie-breaks) that the reference handles.
Aim for 3-5 figures per article. Fewer feels under-baked; more diffuses focus. Each figure should pay off something the prose has just set up - no "decorative" figures.
Read references/voice-and-style.md before writing prose. Quick reminders:
.callout for "the key insight" moments (sparingly, 3-5 per article).epigraph for one or two quoted lines from the source—) - use regular hyphens or rewrite the sentenceBefore declaring the article done, verify:
fact-checking-explainers on the finished article; every checkable claim is supported by its cited source (or the real code), with zero unresolved unsupported or contradicted claims. This gate must pass before delivery.index.html is fully self-contained (no external CSS/JS files in the new directory)<h2 id="..."> anchors and scroll-tracking highlights the section in viewThe "test it locally" step is python3 -m http.server 8000 from the directory containing the file, then open it in a browser. If you have browser tooling available, do this. If you don't, at minimum grep for common bugs: getElementById calls without matching IDs, canvas IDs referenced before declaration, initCanvas not defined.
| Mistake | Why it happens | Fix |
|---|---|---|
| Reaches for React/Vue/D3 | Default frontend habits | Re-read the constraint - vanilla only, IIFE pattern |
| Generates a single huge file in one shot | Trying to be efficient | Outline first, get approval, then build progressively |
| Figures are decorative, not load-bearing | Figures added "because explainers have figures" | Each figure must illustrate something the prose just set up. If it doesn't, cut it |
| Voice reads like documentation | Defaulting to neutral/expository tone | Read voice-and-style.md, rewrite for second-person and concrete scenes |
| Uses em-dashes | LLM default punctuation | Search the file for — and replace before delivering |
| Captions describe what the figure is | Easy to write, low value | Captions should tell the reader what to look for and bold the key term |
| Hard-codes canvas pixel sizes without DPR scaling | Skipping initCanvas() | Always use the shared utility - blurry canvases on retina is the symptom |
Read these as needed during the workflow - don't load them all upfront.
assets/article-template.html - the starting skeleton, copy this into the new article directoryreferences/template-walkthrough.md - what every block in the template doesreferences/figure-archetypes.md - code patterns for the common figure typesreferences/voice-and-style.md - writing patterns, paragraph examples, callout/epigraph usagereferences/color-palettes.md - accent color sets per article, how to pick a palettereferences/intake-from-files.md - extracting structure from a provided paper, blog post, or transcriptreferences/intake-from-research.md - web research workflow when only a topic is givenRelated skills:
fact-checking-explainers - REQUIRED gate at research-time and before deliveryexplaining-codebases - use instead of this skill when the subject is a codebase or source filesnpx claudepluginhub analyticalmonk/explain-thisCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.