Turn a user-confirmed learning goal into an educationally sound, standalone HTML experience through a short design conversation. Use this repository's topics, prerequisites and teaching research; develop targeted research when it is missing or insufficient. Design the interaction and its assessment together, then render, inspect and revise the experience in a browser. A working HTML file is an initial prototype, not sufficient evidence of a good learning experience.

Use information already available in the conversation. Before designing, obtain:

Ask only additional questions whose answers would materially change the design. Prior knowledge, reading independence, access needs, interests, available time, adult support and device may matter; they are not a mandatory questionnaire. Bundle necessary questions into one short turn. For other details, make reasonable assumptions and disclose the consequential ones in the concept. Do not infer mastery or reading ability from age alone. A brief entry task can help calibrate prerequisites when the adult does not know the child's starting point.

When the request already implies an observable goal, propose that goal and the concrete concept in the same turn, ending with one confirmation question covering both. Ground this provisional goal as described below before presenting it; do not require a separate goal-approval round trip. If the goal is genuinely unclear, clarify it first. Full implementation still waits for concept confirmation.

Use the child's language for all child-facing copy: the cover question, instructions, feedback, buttons, accessible names and vocabulary definitions. Use it for the adult note too, unless another language is explicitly requested. Set to the appropriate language tag. Apply that locale's casing and typography while preserving the sentence-case house style. For French, keep punctuation attached with non-breaking spaces: a narrow no-break space (U+202F) before , and a no-break space before (narrow where the chosen locale/style calls for it). Check wrapping at narrow widths; punctuation must not wrap alone. Configure the shared helpers as shown in examples.md.

Read data-and-research.md to locate this repository's data, join topic research and interpret its limitations. Select a small scope matched to the confirmed goal (or the clearly implied goal being proposed alongside the concept), using topic evidence and prerequisite edges to identify the intended outcome and likely starting requirements. Age bands guide selection; they do not override known readiness.

Use existing pedagogy, activity guidance, constraints, misconceptions, assessment and sources to inform the experience. Check that they fit this goal and child; resolve contradictions and verify consequential factual claims. Existing activities are proposals to adapt, not a script or evidence of effectiveness. Do not display publication omission markers as instructional content.

For a missing or inadequate research record, prepare a focused teaching brief:

Use available web/research tools to inspect relevant primary research, evidence syntheses or authoritative teaching guidance. Record what each source actually supports; a curriculum standard establishes alignment rather than efficacy. Never invent references or imply that an unread source was checked. If source access is unavailable, disclose it and label the brief provisional; ask about alternatives only if that limitation prevents a sound design. Keep personal child context out of research queries and reusable research artifacts.

When this new research would help an existing taxonomy topic, suggest an optional os-taxonomy contribution. Follow the contribution guidance in the reference only if the user wants to pursue it. Continue the learning experience independently. Creating an experience does not authorize publishing research or child context.

Read interaction-design.md and visual-design.md before proposing the concept. Design what the child will see and do, and what that action will reveal about understanding. Use the example index to select a relevant example: read its short design note and inspect its key-state screenshots before proposing the concept. After approval, run the example and inspect relevant readable source when adapting its interaction. Examples illustrate specific decisions and carry annotated limits; current skill rules take precedence. Do not copy every example or force its sequence onto a different goal. Before building the full HTML, present a compact, concrete proposal containing:

Invite refinement and wait for the user to confirm the direction before full implementation. This concept checkpoint is required by this workflow; do not one-shot a completed experience from the initial request. If the user already provided an approved concept, validate any missing essentials without repeating an approval ceremony. A small sketch may help the decision, but is not the full experience. After agreement, make routine implementation decisions autonomously.

Default to local, deterministic interactions. Consider runtime LLM calls only when achieving the learning goal requires open-ended reasoning or text production that local rules, simulation or prepared content cannot adequately provide. Do not add an LLM just for conversational decoration, generic hints, personalization or grading answers the browser can already check. Using an LLM to author the experience does not justify LLM calls while the child uses it.

If this condition applies, read llm-connected-experiences.md. During concept design, explain the essential learning role, connection/provider, data sent, account usage/cost and loss of offline operation. Obtain explicit approval from the experience's author before including runtime LLM calls. General concept approval or approval to update this skill is not permission for this capability. An explicit request that already approves these terms counts; do not repeat approval. Without it, continue with an agreed local alternative or explain which part of the goal cannot be met locally. Never silently substitute a narrower task and claim it assesses the original goal.

By default, deliver one HTML file with embedded CSS, JavaScript and required assets that opens directly in a browser without accounts, a build step, a server or network access. Author-approved connected LLM mode is the narrow exception: keep the experience UI and assets self-contained, and disclose the required connection service, parent authentication and network access. Do not call that mode offline or promise that HTML alone supplies the connection. Keep any research/design companion outside the child-facing flow. Use local interactions and no tracking or transmission of child responses by default. Use the bundled Baloo 2 throughout with the Marble component baseline: small sentence-case titles at 500, prominent explanations at 550, and icon-plus-label buttons at 500. Read the exact roles and usage in component-styling.md. Embed the actual font bytes; font substitutions or fallbacks require an explicit project-level exception to the house style. Keep instructions and button labels in sentence case. Use Three.js for spatial experiences involving viewpoint, illumination, depth, occlusion or moving physical objects, including the daytime-Moon example. Build one coherent, polished 3D scene with direct manipulation: drag the Earth, place an observer, or select a prediction in the scene. All 3D uses a crafted cel-shaded look: flat color, deliberate stepped light/shadow bands and clean black outlines. Visual simulations must be beautiful, crafted and polished as well as functional; a working model with placeholder art is not a finished experience. Do not substitute flat comparison panels and external step buttons for spatial interaction. Use 2D for goals whose reasoning is genuinely two-dimensional, such as fraction bars or sentence work. Follow visual-design.md for Marble-derived fonts, colors, tactile controls, scene composition and the standalone Three.js workflow. Respect explicit user constraints.

Choose a coherent learning flow rather than defaulting to a linear sequence. Use guided steps where prerequisites matter; offer selectable investigations, revisiting and open exploration where these serve the goal. A clear next action can be a meaningful choice. For dynamic simulations, read simulation-design.md.

Design the experience around these principles:

Provide basic keyboard operation, readable contrast, responsive layout and non-colour-only feedback. Offer a practical alternative to any essential interaction that requires precise dragging, sound or similar capabilities. Keep progress, hints, retries and restart behavior understandable using scene state, icons and non-text progress marks. Put source acknowledgements and required attribution in the separate adult companion and retain embedded asset license notices in the HTML source; follow the repository's README and provenance notices for reused material. Do not turn the learning canvas into a branded webpage.

Use validation.md during development, starting with the central interaction before polishing the rest. Render in a browser, inspect screenshots and exercise controls, revise the design, then render and check the revision. Assess visual clarity and teaching behavior as well as correct code; a screenshot captured but not inspected is not a UX review. Compare the rendered composition with the Water Lab reference and the explicit visual acceptance criteria; “it loads” is not a polish pass. Use browser tools available in the environment, without requiring a particular automation stack. If browser access is unavailable, report the artifact as a prototype awaiting browser validation rather than presenting the UX as validated. Automated checks cannot establish effectiveness for a particular child.

Deliver the HTML and a short adult-facing note covering the goal, topic IDs, prerequisites/assumptions, research used or newly developed, mastery evidence, optional extension and any remaining limitations. Include a way to open the file and summarize what was actually tested. Do not claim browser or child testing that did not happen. Invite observations from actual use to guide the next revision; do not turn that invitation into a required extra questionnaire.