interactive-explainer

Name: interactive-explainer
Author: rianvdm

15stars4forks

How to install interactive-explainer?

rianvdm/product-ai-public/interactive-explainer

$npx -y skills add rianvdm/product-ai-public --skill interactive-explainer

Installs into the current project.

Summary

Builds a self-contained interactive HTML visualisation that makes a process, algorithm, decision logic, or system visually and experientially understandable. Primary input is a linear walkthrough, but works directly from code, documents, or concept descriptions too — and can invo

Files · 1

View on GitHub

SKILL.md

1	# Interactive Explainer
2
3	You build interactive HTML visualisations that make abstract processes, algorithms, and decision logic _experiential_ — something the reader can manipulate and explore, not just read. The goal is to eliminate cognitive debt: after using the visualisation, the reader should feel like they _understand_ the logic, not just that they've seen it described.
4
5	## Source Material
6
7	Preferred input is a linear walkthrough (from the `linear-walkthrough` skill), because walkthroughs are already structured as a logical narrative with clear sections and identified connections. If none exists:
8
9	- Work directly from source material (code, document, concept description)
10	- If the source material is dense, ambiguous, or poorly structured, invoke the `linear-walkthrough` skill first to extract a clear narrative, then use that as input. This produces better visualisations than trying to interpret raw complexity directly.
11
12	## Before You Build
13
14	Identify two things:
15
16	### 1. What is the core thing to make understandable?
17
18	Read the walkthrough and ask: _what is the single most important thing a reader struggles to grasp from reading alone?_ This is usually one of:
19
20	- A decision algorithm — branching logic that leads to different outcomes based on inputs
21	- A sequential process — stages that execute in order, each transforming something
22	- A system with interacting parts — components that affect each other
23	- A concept with a key mechanism — an abstract idea that becomes clear when you can "turn the dial"
24
25	The visualisation should be built around _that one thing_, not an exhaustive diagram of everything.
26
27	### 2. What visualisation type fits?
28
29	\| Core content \| Visualisation type \|
30	\| ------------------------------------ \| ---------------------------------------------------------------------------------------------------- \|
31	\| Decision algorithm / flowchart \| Interactive decision tree — live inputs that traverse the logic and highlight the resulting path \|
32	\| Sequential pipeline / process stages \| Animated step-through — stages that activate in sequence with explanations at each step \|
33	\| System with interacting components \| Clickable component diagram — click to explore each part; relationships animate on hover/click \|
34	\| Parameter-driven concept \| Live explorer — sliders/inputs that change the output in real time, showing cause and effect \|
35	\| Comparative options \| Side-by-side toggle — switch between options and see what changes \|
36
37	If the content is complex enough to merit it, combine types — e.g. a decision tree that also shows parameter effects as sliders. Richer is better _if it adds clarity_. Never add visual complexity that requires the user to understand the visualisation before they can understand what it's visualising.
38
39	Propose the approach briefly before building. One sentence on what you'll build and why, then proceed unless the user redirects. Don't wait for approval — describe and build.
40
41	## Two Output Modes
42
43	### Mode A: Deployed Worker site (preferred for durable explainers)
44
45	For explainers that will be shared with colleagues, maintained over time, and deployed behind Access, use the deployed Worker framework. This is a battle-tested shared CSS/JS engine extracted from two production sites.
46
47	When to use: The user wants a deployed internal site, mentions "deploy", wants something colleagues can bookmark, or the subject is complex enough to warrant multiple guided modes.
48
49	Deployment: Follows the standard `internal-workers-deployment` skill (Data Lab account, `cf-*` naming, wildcard Access).
50
51	Implementation reference: Read `reference/deployed-worker-framework.md` in this skill's directory for the explainer-specific guide covering:
52	- Shared CSS/JS framework (copied verbatim from existing sites)
53	- `window.pageConfig` data model
54	- Page-specific CSS patterns (domain colors, highlights, dark mode)
55	- Diagram HTML components (nodes, arrows, forks)
56	- Mobile responsive breakpoints
57	- Fresh

People who liked this also viewed

6 picks

Type

interactive-explainer

15stars4forks

View on GitHub

How to install interactive-explainer?

rianvdm/product-ai-public/interactive-explainer

$npx -y skills add rianvdm/product-ai-public --skill interactive-explainer

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Interactive Explainer
2
3	You build interactive HTML visualisations that make abstract processes, algorithms, and decision logic _experiential_ — something the reader can manipulate and explore, not just read. The goal is to eliminate cognitive debt: after using the visualisation, the reader should feel like they _understand_ the logic, not just that they've seen it described.
4
5	## Source Material
6
7	Preferred input is a linear walkthrough (from the `linear-walkthrough` skill), because walkthroughs are already structured as a logical narrative with clear sections and identified connections. If none exists:
8
9	- Work directly from source material (code, document, concept description)
10	- If the source material is dense, ambiguous, or poorly structured, invoke the `linear-walkthrough` skill first to extract a clear narrative, then use that as input. This produces better visualisations than trying to interpret raw complexity directly.
11
12	## Before You Build
13
14	Identify two things:
15
16	### 1. What is the core thing to make understandable?
17
18	Read the walkthrough and ask: _what is the single most important thing a reader struggles to grasp from reading alone?_ This is usually one of:
19
20	- A decision algorithm — branching logic that leads to different outcomes based on inputs
21	- A sequential process — stages that execute in order, each transforming something
22	- A system with interacting parts — components that affect each other
23	- A concept with a key mechanism — an abstract idea that becomes clear when you can "turn the dial"
24
25	The visualisation should be built around _that one thing_, not an exhaustive diagram of everything.
26
27	### 2. What visualisation type fits?
28
29	\| Core content \| Visualisation type \|
30	\| ------------------------------------ \| ---------------------------------------------------------------------------------------------------- \|
31	\| Decision algorithm / flowchart \| Interactive decision tree — live inputs that traverse the logic and highlight the resulting path \|
32	\| Sequential pipeline / process stages \| Animated step-through — stages that activate in sequence with explanations at each step \|
33	\| System with interacting components \| Clickable component diagram — click to explore each part; relationships animate on hover/click \|
34	\| Parameter-driven concept \| Live explorer — sliders/inputs that change the output in real time, showing cause and effect \|
35	\| Comparative options \| Side-by-side toggle — switch between options and see what changes \|
36
37	If the content is complex enough to merit it, combine types — e.g. a decision tree that also shows parameter effects as sliders. Richer is better _if it adds clarity_. Never add visual complexity that requires the user to understand the visualisation before they can understand what it's visualising.
38
39	Propose the approach briefly before building. One sentence on what you'll build and why, then proceed unless the user redirects. Don't wait for approval — describe and build.
40
41	## Two Output Modes
42
43	### Mode A: Deployed Worker site (preferred for durable explainers)
44
45	For explainers that will be shared with colleagues, maintained over time, and deployed behind Access, use the deployed Worker framework. This is a battle-tested shared CSS/JS engine extracted from two production sites.
46
47	When to use: The user wants a deployed internal site, mentions "deploy", wants something colleagues can bookmark, or the subject is complex enough to warrant multiple guided modes.
48
49	Deployment: Follows the standard `internal-workers-deployment` skill (Data Lab account, `cf-*` naming, wildcard Access).
50
51	Implementation reference: Read `reference/deployed-worker-framework.md` in this skill's directory for the explainer-specific guide covering:
52	- Shared CSS/JS framework (copied verbatim from existing sites)
53	- `window.pageConfig` data model
54	- Page-specific CSS patterns (domain colors, highlights, dark mode)
55	- Diagram HTML components (nodes, arrows, forks)
56	- Mobile responsive breakpoints
57	- Fresh

People who liked this also viewed

6 picks

Type