Communitygithub.com

aaronbuchanan/webgl-experience-design

Conceive, prototype, and build websites where real-time graphics drive navigation, storytelling, or interaction. Use for ambitious WebGL experiences, creative direction, graphics prototypes, and production integration; decorative canvas backgrounds alone do not meet this workflow.

What is webgl-experience-design?

webgl-experience-design is a Claude Code agent skill that conceive, prototype, and build websites where real-time graphics drive navigation, storytelling, or interaction. Use for ambitious WebGL experiences, creative direction, graphics prototypes, and production integration; decorative canvas backgrounds alone do not meet this workflow.

Works with~Claude Code~Codex CLI~Cursor
npx skills add aaronbuchanan/webgl-experience-design

Ask in your favorite AI

Open a new chat with this agent skill pre-loaded.

Documentation

WebGL Experience Design

Work as a creative director and graphics engineer together. Aim for the conceptual coherence and execution quality of Active Theory, Lusion, Immersive Garden, Resn, makemepulse, Merci-Michel, Unseen Studio, and Dogstudio. These are benchmarks for judgment, not interchangeable visual styles or reusable production code.

Establish the assignment

Inspect the existing project and respect its stack and scope. Ask only for information that changes direction or feasibility; state other assumptions. Use the brief to identify audience, feeling, content, primary action, assets and rights, devices, delivery constraints, and ownership.

Write one sentence explaining what the visitor can understand or do because of real-time graphics. If removing the canvas leaves the concept and interaction unchanged, strengthen the concept before adding effects. Essential information and actions must still have an intentional accessible fallback.

Before substantial production, record target devices, measurable budgets, required gates, smallest sufficient evidence, and stop conditions using acceptance and handoff. Missing device access is an evidence gap, not a reason to silently substitute emulation.

Research only what changes a decision

Start with relevant entries in the source library; do not load or browse the entire library on every task. Verify current links and APIs when using them. For unfamiliar techniques, consult the technique index.

Use official portfolios, authored case studies, credited talks, public repositories, and runnable demos. Follow credits to collaborators and implementation authors; retain unknown authors as unknown. Separate Observed (direct interaction or pixels), Documented (what an identified author says), and Inferred/proposed (your mechanism). A screenshot cannot prove an engine, physics system, performance, or accessibility.

For each borrowed principle complete the reference analysis: source → effective execution → principle → documented or proposed mechanism → original reinterpretation → smallest prototype. Synthesize across references. Do not reproduce distinctive compositions, complete interaction sequences, branded assets, or copy.

Publicly viewable code is not automatically reusable. Check the exact license and asset exceptions before incorporating code, record version/commit and required notices. Without permission, describe the observable technique and write an original implementation from documented methods. Do not extract proprietary production bundles or use clones as evidence of studio internals.

Develop directions, then resolve the scene

Offer two or three meaningfully different directions, each with a central interaction, reference rationale, 3–5 storyboard frames, content/action placement, fallback, feasibility, and its highest-risk assumption. Use sketches or annotated frames when useful. Explain which direction you recommend and why; honor an already chosen direction. If approval is needed, make the choice concrete first and continue only independent work while waiting.

Resolve the selected direction into a scene/interaction contract using the scene template: hierarchy, coordinate spaces, camera framing, material/light language, type placement, transitions, input and focus behavior, semantic content, loading and failure states. Tie each effect to a creative purpose. Check the composition with effects disabled.

Choose the engine after the visual and interaction plan. Reuse a suitable existing stack. Three.js suits broader scene/asset needs; React Three Fiber suits React lifecycle integration; OGL or native WebGL suit small shader-led scenes. Consider WebGPU only for a demonstrated need and an explicit support/fallback plan. Do not migrate engines for prestige.

Prove the hardest idea

Build a small runnable vertical slice before full production: one distinctive interaction, real input, representative content, primary action, and a failure/fallback path. Follow prototype criteria. Use Tidal Index as a complete example, not a universal starter or a production-ready site.

Expose 2–4 art-direction controls in designer language, such as relief, softness, camera distance, or rhythm. Bound their ranges and explain the perceptual tradeoff; avoid an uncurated shader parameter panel. Every visible control must work. Label simulations and placeholders at the point of use.

If the idea cannot be understood, controlled, or sustained within the target device budget, simplify the representation or revisit the direction. Do not hide an unsuccessful prototype under more polish.

Integrate and qualify

Keep route/content state authoritative outside the renderer. Canvas hits and semantic DOM controls must invoke the same action. Preserve native scroll, URLs/history where applicable, readable selectable content, keyboard access, visible focus, reduced motion, touch, and opt-in sound. Never require sound or pointer precision for the main action.

Apply production guidance only as relevant: quality adaptation, progressive loading, model/texture compression, DOM/canvas alignment, resizing, visibility, context failure, and resource ownership/disposal. Optimize from evidence, starting with pixel cost and overdraw rather than speculative rewrites.

Verify representative desktop and mobile paths, primary conversion, frame stability, load/failure states, navigation, and repeated mount/unmount. Report physical devices separately from emulation. Screenshots establish appearance only. Reuse valid evidence for unchanged artifacts; broaden checks only for a concrete unresolved risk.

Deliver and stop

Deliver the selected direction and storyboard, reference-to-implementation records, scene contract, runnable prototype or implementation, measured evidence with environment, rights/attribution manifest, and handoff checklist. Scale artifacts to the requested stage; a concept request does not authorize full production or publishing.

Stop when the agreed stage passes its gates. Report remaining gaps with exact affected claims. Do not call an implementation production-ready without required device and functional evidence. Do not publish, deploy, contact collaborators, or expand permissions merely because the skill is being used.

Related Skills