# Create an Inside topic pull request

Replace `{{TOPIC}}` with any subject. Give the resulting prompt to an AI coding assistant with access to this repository or the creator kit.

---

Create a beginner-friendly Inside topic about **{{TOPIC}}** and open a focused GitHub pull request in `RodimusGPT/learn-inference`.

Inspect the repository, its contributor instructions, GitHub remote, and default branch. Resolve the GitHub repository from a configured GitHub remote or the canonical URL in `README.md`: `https://github.com/RodimusGPT/learn-inference`. If the creator kit has no Git metadata, clone that repository into an isolated checkout. Fetch the latest `main` from the GitHub remote, then create an isolated topic branch or worktree from that fetched GitHub branch. Keep unrelated working changes intact; do not use a Sites hosting remote as the PR destination. Work from the project root, where `authoring/`, `scripts/`, and `dist/` are siblings; extract the complete source tree first if using the creator kit. Read `authoring/DESIGN_LANGUAGE.md`, `authoring/topic.schema.json`, and `authoring/topic.template.json`. Inspect existing topic documents in `dist/data/topics/` and the app's supported visual behavior. Preserve the current design, library format, Site identity, and audience. Do not create another Site.

Define the beginner's practical question and the explanation's scope. Research unfamiliar or time-sensitive claims using reliable sources, preferring primary documentation or research. Check definitions, calculations, units, causal claims, exceptions, and dates. Never invent empirical data, benchmarks, citations, quotations, or evidence. Distinguish established facts from assumptions and illustrative examples. Put readable source titles and URLs in the relevant expandable detail text, especially for quantitative or disputed claims. Qualify or omit facts that cannot be verified.

Build a coherent teaching narrative of 6–12 slides: orient the reader, introduce the mechanism or relationships, explore a concrete example, address a misconception, check understanding, and finish with a useful mental model. Adapt the sequence to the subject. Explain one idea per slide, with a summary of at most 26 words. Put definitions, sources, caveats, and deeper explanation in optional expandable details. Keep the visible surface concise and plain-spoken.

Prefer a meaningful hands-on Anatomy mechanism for the topic's central process, state change, or tradeoff. Use the Anatomy skill for original filled isometric figures with purposeful parts, correct depth order, and its required audits. Let the reader step through a process, change an input, or compare conditions. The control, conceptual model, visible parts, explanation, and readout must share the same checked ground truth. State explicitly that a machine analogy is conceptual, what its highlights mean, and where the analogy stops. Use a simpler general visual when machinery would distort the explanation; do not force controls onto every slide.

Prefer the reusable `visual: "anatomy"` controller when discrete model states fit. Its slide payload is `figure: {asset: "assets/figures/<topic-id>.svg", label, states: [{id, label, readout, parts: ["part-id"]}]}`. SVG groups must use matching `id` and `data-anatomy-part` values. The existing engine supplies state buttons, keyboard stepping, and play/highlight behavior, so a new topic can reuse it without custom interaction code. Derive the state table, highlighted parts, and readouts from one model. Keep assets local and self-contained. Preserve stable audited geometry where highlights suffice; if real geometry moves or changes shape, include focused source and audit the full range.

Other supported general visuals are `steps`, `comparison`, `number`, `chart`, `check`, and `concept`. Use the schema exactly, a unique lowercase hyphenated topic ID, unique slide IDs, `level: "Beginner"`, and useful category/search tags. A chart needs honest units, matching labels and values, and a caption identifying illustrative data. A check needs at least two choices, exactly one correct answer, and teaching feedback for every choice. Use inference-specific visuals only for subjects they accurately explain.

Preserve cream `#f2f0e6`, moss `#2d4939`, sage `#93a585`, Georgia headings, system sans body, and monospace utility text. Keep controls compact, labeled, and keyboard accessible, with visible focus and clear readouts. Under reduced motion, controls must still update the settled state and result immediately without travel, pulsing, or autoplay. Stop activity offscreen and clean up timers, animation frames, and listeners when leaving a slide. Motion must explain a relationship. Keep all runtime assets local.

Write the new source topic to `dist/data/topics/<topic-id>.json`, and add only the needed local SVG assets and figure source. Validate and build from the project root:

```sh
node scripts/add-topic.mjs --validate dist/data/topics/<topic-id>.json
node --check dist/assets/app.js
python build.py
```

`build.py` derives the catalog and downloadable editions from source topic files. Keep the PR focused on source: the new topic JSON and any needed Anatomy assets/source. Omit generated `dist/data/catalog.json` and `dist/downloads/` bundles from the commit unless a maintainer explicitly requests them. Do not overwrite an existing topic without a request to update it. Do not include credentials, unrelated changes, or generated archives in the commit.

Check library discovery, direct route `#/topic/<topic-id>/1`, slide count/navigation, every visual, check answers and feedback, expanded details, keyboard controls, reduced motion, and a 390px mobile layout. For an Anatomy experiment, verify all state transitions and named parts, model/readout agreement, repeated use, offscreen cleanup, and the applicable zero-failure geometry and line-end audits. Check browser errors and horizontal overflow. Keep concise evidence of the results and any remaining limits.

Create a focused commit, push the topic branch to GitHub, and open a PR with base `main`. Use a clear title and a concise description of the teaching problem, resulting reader experience, preview route, and validation. Include relevant Anatomy audit results. CI will validate the source and attach a reviewable static preview artifact. Make the PR easy to review and merge without unrelated or generated changes.

**Finish by reporting the PR link. Do not merge the PR or deploy to production.** This request's PR boundary overrides any Sites skill default to publish. Preserve `.openai/hosting.json`; publication remains a separate maintainer action. If the user explicitly requests only a local draft or JSON instead, stop at that requested boundary.
