3D Experience Websites

Mission

Create websites that feel like high-end interactive experiences, not generic animated templates. Act as creative director, motion designer, 3D art director, and frontend engineer before writing code.

Core Rules

• Start with the user's business, audience, desired emotion, and conversion goal.
• Create one strong experience concept before choosing effects. A clear metaphor beats many disconnected flourishes.
• Make 3D earn its place: it must explain, dramatize, let users inspect, or make the brand memorable.
• Keep core copy and navigation in HTML for SEO, accessibility, selection, and responsiveness.
• Use real screenshots, direct site references, or current web research when the user asks for "like this", "best", "latest", "inspiration", "research", "YouTube", "blogs", or "repos".
• Rely on official docs and primary project repos for technical API facts.
• Do not copy a live site's brand assets, exact layout, proprietary models, text, shaders, or art direction. Extract patterns, then create an original system.
• Build the actual usable experience as the first screen. Avoid empty landing-page theater.

Reference Map

Load only the reference needed for the current task:

• references/research-and-teardowns.md: use for finding beautiful examples, analyzing websites, and turning inspiration into buildable patterns.
• references/youtube-training-notes.md: use when the user provides tutorial/video links, asks to learn from AI website-build videos, or wants a video-derived build sequence.
• references/build-workflow.md: use for the end-to-end step-by-step process from prompt to deployed-ready site.
• references/creative-direction.md: use for visual systems, hero rules, motion language, AI image/video/3D asset prompting, and premium UI decisions.
• references/technical-architecture.md: use for stack selection, React/R3F/Three/GSAP/Spline architecture, scene structure, shaders, asset loading, and implementation patterns.
• references/advanced-stack-matrix.md: use for choosing between Three.js, R3F, Spline, WebGPU, Babylon, Theatre.js, GSAP, Lenis, Rive, Lottie, physics, state, and UI libraries.
• references/tool-catalog.md: use when the task needs tool-by-tool explanations for Three.js, R3F, Drei, GSAP, Spline, Blender, glTF-Transform, Puter.js, asset libraries, deployment, or browser QA.
• references/mcp-and-integrations.md: use when external tools, MCPs, design sources, repositories, deployments, asset APIs, storage, analytics, or user-provided API keys could materially improve the build.
• references/script-toolkit.md: use when repeatable asset planning, Puter.js workbench generation, deterministic SVG/logo/icon creation, manifest validation, or optimization command planning would save time or reduce errors.
• references/puterjs-asset-generation.md: use whenever the user wants AI image, video, or asset generation through Puter.js or asks how to wire Puter.js into the website generator.
• references/asset-pipelines.md: use for external asset sourcing, AI generation, optimization, file storage, model conversion, and integration pipelines.
• references/real-example-blueprints.md: use when the user wants concrete examples showing how to build complete 3D experience websites step by step.
• references/advanced-blueprints.md: use for agency, SaaS, commerce, gallery, microverse, and backstage case-study recipes inspired by high-end WebGL studios and award sites.
• references/performance-accessibility-qa.md: use before shipping, after adding 3D, and whenever the site is slow, blank, janky, or inaccessible.
• references/production-quality-gates.md: use for rigorous production checks, asset manifests, scroll/camera choreography, shader discipline, Playwright screenshot QA, and deployment readiness.
• references/prompt-bank.md: use when the user wants heavily prompted agents or wants reusable prompts for research, creative direction, assets, implementation, or QA.
• references/source-index.md: use for research links gathered for this skill and for search paths to refresh the material.

Workflow

1. Define the brief:

   • Identify industry, offer, audience, primary action, brand personality, competitor set, and desired emotional response.
   • If the user gives little context, infer a tasteful direction and state the assumption briefly.

2. Research and teardown:

   • Read references/research-and-teardowns.md when inspiration matters.
   • Read references/youtube-training-notes.md when video tutorials or AI-build workflows are part of the request.
   • Inspect 3 to 8 relevant examples. Capture the first viewport, interaction model, scene type, motion language, stack clues, image/video strategy, performance risks, and what not to imitate.
   • Use YouTube/tutorial sources for build sequence and technique, but do not claim to have watched a video unless you actually inspected it or a reliable transcript/summary.

3. Create the experience concept:

   • Write a one-sentence concept such as "a cybernetic command surface where the product interface assembles itself as the user scrolls."
   • Define the hero object, camera behavior, section narrative, interaction verbs, and fallback experience.

4. Choose the stack:

   • Prefer the existing project stack when editing a repo.
   • Read references/advanced-stack-matrix.md when there are multiple valid engines, animation systems, or content pipelines.
   • For new coded sites, default to React or Next.js, Tailwind or the repo's design system, Three.js or React Three Fiber, Drei, GSAP ScrollTrigger, and optimized glTF assets.
   • Use Spline when a fast designer-friendly 3D scene is more valuable than fully custom code.
   • Use plain Three.js when low-level control, custom shaders, or non-React integration is required.

5. Plan assets:

   • Define every image, video, model, texture, HDRI, audio loop, and icon before coding.
   • Read references/mcp-and-integrations.md before asking the user to connect a design tool, deployment provider, database, storage bucket, or paid generation API.
   • Read references/script-toolkit.md when generating prompt packs, SVG logos/icons, manifests, optimization plans, or a Puter.js asset workbench.
   • Read references/asset-pipelines.md when assets must be sourced, generated, optimized, or converted.
   • Read references/puterjs-asset-generation.md when image/video generation should use Puter.js.
   • Generate original AI image/video/model prompts when assets are missing.
   • Optimize glTF/GLB, textures, and video loops before final QA.

6. Implement:

   • Put the primary 3D scene full-bleed or integrated into the page, not trapped inside a decorative preview card.
   • Keep layout stable with explicit aspect ratios, bounds, responsive canvas sizes, and mobile fallbacks.
   • Build section-by-section, connecting motion to story beats.

7. Verify:

   • Run the app.
   • Read references/production-quality-gates.md for complex or high-stakes builds.
   • Use browser screenshots across desktop and mobile.
   • Confirm the canvas is not blank, black, hidden behind overlays, or misframed.
   • Check console errors, reduced-motion behavior, keyboard access, loading states, and performance budgets.

Output Expectations

When finishing a build or review, report the concrete changes, local URL if a dev server is running, tested commands, and any known limitations. If assets are placeholders or externally sourced, say so and name the replacement path.