explore-concept

Explore a Concept

[!CAUTION] Provisional / experimental skill. Kept for the record, not endorsed. Its first real run (quaternions → "The Belt") produced a plausible, well-documented, hollow artifact that passed its own review — see the hard-fail reflection under docs/sessions/progress/quaternion-exploration-app-ig4jmy/. The diagnosis there (a natural-language pipeline is blind to a kinesthetic payoff and manufactures false confidence) is a caution about this very skill. Use only with that warning in mind.

The divergent gathering phase that comes before designing a new animath app. Given a mathematical concept, this skill does not collect parallel essays and average them. It convenes the holders of orthogonal, embodied understandings of the concept in one room and makes them teach each other — and then reads the design-relevant friction out of what they actually said. The pipeline:

Stage 1 — Foundation (cited research) → Stage 2 — The Room (a carried-out dialogue) → Stage 3 — The Friction Atlas (read the crossings out of the transcript) → Stage 4 — Building the artifact (the design team turns crossings into 2–4 candidate apps + a draft plan) → /three-hats → BUILDING_AN_APP.md.

Why a dialogue, not parallel lenses

This skill used to fan out ten independent "lens" essays and let a narrator synthesize them. That flattens the very thing that is generative. A synthesis can only surface what each lens already brought; a dialogue surfaces what no single voice held — the content that exists only in the translation between two of them. (In the quaternion trial run, "why can't we do it in three numbers?" produced nothing useful until Hamilton was allowed to refuse Frobenius's one-line "the wall is a wall" and keep asking — at which point the room had to manufacture the concrete answer 15 is not a sum of three squares, aimed straight into Hamilton's own failing ij term. That fact was not retrieved. The friction made it.) The whole skill is therefore organized around keeping the voices orthogonal and in genuine dialogue, and only culling after the fact, from the words.

The animath-specific question the whole thing serves is unchanged: what is the single best first visualization to build here? — but we now answer it by first finding where the learning actually crosses difficult terrain, and only then asking what is buildable.

Input

$ARGUMENTS — the concept to explore (e.g. quaternions, the Fourier transform, Gaussian curvature). A bare concept name is fine; this skill's job is to widen it. If the argument is empty, ask the user for the concept in one line.

Output Files

Resolve the branch slug first: git branch --show-current, strip a leading claude/, replace / with -. All outputs go in that branch's progress folder. Get the YYYY-MM-DD-SNN identifier from the most recent file in docs/sessions/progress/<branch-slug>/ (use the current session's; if there is no progress report yet, use today's date with S01). Write these files ({id} = that identifier):

• docs/sessions/progress/<branch-slug>/{id}-concept-foundation.md — Stage 1 research base (kind: research)
• docs/sessions/progress/<branch-slug>/{id}-room-transcript.md — Stage 2 the carried-out dialogue (kind: dialogue)
• docs/sessions/progress/<branch-slug>/{id}-friction-atlas.md — Stage 3 crossings read out of the transcript (kind: atlas)
• docs/sessions/progress/<branch-slug>/{id}-concept-plan.md — Stage 4 candidates + draft build plan (kind: plan, status: proposed)

Each file is Markdown + YAML frontmatter per docs/sessions/REPORT_STYLE.md (kind, session, date, title, branch, slug, status, build), then ## sections, GitHub-alert callouts and Markdown tables. npm run sessions renders them to the rich HTML view. (Stage 4 may optionally spawn the design-team roles as separate kind: lens files — see Stage 4 — but the four files above are the required spine.)

Stage 1 — Foundation (deep research)

Build a cited, fact-checked evidence base first, so the room argues from shared facts rather than model memory, and so the transcript is auditable (every claim a voice makes should trace to this document). Invoke the deep-research skill with a prompt assembled from the concept and the angles below, scoped tightly enough that it does not need to ask clarifying questions — something like:

Research <concept> for the purpose of designing an educational, interactive visualization. Cover, with sources: (1) history & originator — who introduced it, when, what problem they were actually trying to solve, the key insight, and the near-misses (who reached it and didn't publish, who hit the wall and failed, who saw a piece without recognizing it); (2) genetic origin — how it emerges from simpler, well-understood ideas, and why the obvious simpler version is impossible if it is; (3) natural & applied appearances — where it shows up in physics, engineering, computer graphics, biology, nature, other math, and where it is physically felt (demonstrations a body can do); (4) the standard visual representations used to teach it, and which reveal vs. obscure the structure; (5) canonical learner confusions / pitfalls. Prefer authoritative sources.

Capture the result into {id}-concept-foundation.md. If deep-research is unavailable, do a lighter targeted WebSearch + WebFetch pass over the same points.

[!IMPORTANT] Quarantine the candidate visuals. Put area (4) — "the standard visual representations" — in its own ## Prior-art visualizations (quarantined — do not lead the room) section. The room is seeded with the facts (history, near-misses, genetic origin, applications, felt demonstrations, pitfalls) but is told to let the picture emerge from the dialogue, treating the quarantined section as prior art to differentiate from or earn, never a menu to adopt. Only the Stage 4 design team and the synthesis may lean on it freely.

Also do a quick codebase prior-art scan (for Stage 4): note what already exists that a new app could lean on — e.g. src/math/quat4.ts, src/controls/QuarterTurnControls, the src/lib/particles/ engine + ParticleViewerShell, the 4D projection modes, lib/colormaps.ts, the CSS/DOM app pattern — and skim docs/BUILDING_AN_APP.md and the closed archetype vocabulary (src/chrome/workspace/archetypes.ts).

Stage 2 — The Room (the carried-out dialogue)

Convene a cast of orthogonal, embodied understandings and write the dialogue out in full as text. This is authored as one sustained transcript by a single writer holding every voice — not as parallel agents. The friction is relational (it lives between voices) and cannot be produced by isolated agents writing in separate contexts; that is precisely the failure mode of the old parallel-lens approach. Seed strictly from the Stage-1 foundation.

Casting — span the trajectory no-knowledge → all-we-know → how-we-use-it

Draw the cast from the foundation's facts. Aim to fill each band; some concepts won't populate all of them, and that is itself a finding.

• Originators & near-misses — the historical lineage, including those who reached it and didn't publish, who hit the wall and failed, or who saw a piece without recognizing it. (For quaternions: Hamilton, Rodrigues, Gauss-in-a-drawer, Cayley.)
• The impossibility / structure voices — whoever can answer "why can't we do the obvious simpler thing?" concretely, not by assertion. The wall must have a keeper who can hand a learner a fact they can check. (Frobenius, Hurwitz.)
• Practitioners — the people who use it, who carry the "why care" and the "how we use it" end. (The animator, aerospace attitude control, the graphics engineer; Shoemake.)
• Embodied & natural instantiations — where the concept is felt in the universe, especially felt-but-unformalized: a body, an organism, a physical phenomenon that "knows" the concept without symbols. (The Dirac belt / spinning plate, the spin-½ electron, the falling cat, the brain's head-direction code / a navigating bee or bat.) These are the most valuable voices for animath's manipulate-to-learn ethos — they are pure felt.
• The naive learner — meets the concept for the first time, bounces honestly, says the wrong guess out loud.
• The skeptic — resists the obvious app; keeps the room honest.

Register — how they speak (this is load-bearing)

• Questions, not declamations. No speeches, no "I, Hamilton, declare…". The room runs on genuine questions across the gaps: "How do you…", "What about…", "Why can't we…", "Is that your…?"
• Press. When a voice hits a hard question, do not let the room drop it with a one-line answer everyone nods at. Make the asker refuse to leave it alone until the room manufactures an answer a learner could actually hold. (The richest content in the trial run came entirely from this rule.)
• Carry it out fully as text. Do not summarize "they discussed X." Write the exchange. Some voices speak a lot; some barely; some choose not to speak (a near-miss who "put it in a drawer" can embody that silence). Everyone gets the chance.
• Felt before formal. Let the embodied voices show (a belt, a turning object) rather than state. Where the felt and the formal land on the same spot, let the room notice it in dialogue — do not annotate it from outside.
• Do not pre-cull. The transcript is not pre-filtered for "useful" moments. The words do the culling; Stage 3 reads it out. Resist the urge to append "here are the takeaways" — that is Stage 3's job, and doing it here destroys the evidence.
• The transcript is spoken dialogue only. No margin commentary, no inline "what just happened h

---

Content truncated.