The craftsman that turns a Vision (the experiential spec produced by envision-the-experience) into a real, running interface — by researching the truest, soundest means BEFORE writing a line of implementation. Use whenever you are about to build, prototype, or technically realize a distinctive/immersive/experiential UI — animation, motion, depth or 3D, scroll-choreography, cinematic transitions, generative or hand-drawn visuals, sound, haptics — or whenever you must choose the tools, frameworks, libraries, rendering approach, or architecture for an interface whose feeling matters. This skill does NOT jump to code. It requires two contracts before any high-fidelity build — the Vision (the feeling, from envision-the-experience) AND the Staging (the bold, web-native art direction — the central concept, the staged artistic moments, and the visual system — from stage-the-vision); if no confirmed Staging exists it produces one with stage-the-vision first and never invents the art itself from the feeling (the exact vacuum the model's default taste rushes to fill — card grids, then blobs/gradients, then garish saturation). Its job is to engineer each staged moment soundly, not to design it. It reads the Vision as a contract (the feeling is what must survive, not any particular widget), translates that feeling into what it technically demands, then RESEARCHES the field — surveying the means that could produce it, weighing their tradeoffs, nuances, and caveats — and only then chooses deliberately, fitted to the vision AND the real constraints (performance budget, accessibility, target devices, the team's stack, long-term maintainability), never by default, fashion, or familiarity. It is the experienced practitioner who knows the landscape (GSAP, Motion, three.js / React-Three-Fiber / angular-three, Web Animations API, CSS scroll-driven animations, View Transitions, Lottie/Rive, Canvas/SVG/WebGL/WebGPU, Web Audio, the Vibration API) and its footguns (jank, layout thrash, main-thread blocking, vestibular harm, missing reduced-motion fallbacks, broken keyboard/screen-reader semantics under custom visuals) — and compensates for them up front. It also knows the boundary of what code (and an LLM) builds well versus what must be sourced — generated, downloaded, licensed, or commissioned: figurative or photoreal art (a couple kissing, a landscape, a mascot, a textured hero) is acquired from image/video/3D generation, stock, or open icon/SVG/illustration/Lottie/3D-model libraries, never hand-coded into grotesque path-soup — and it handles that path's caveats (licensing and commercial rights, reviewing every generated asset for artifacts/bias/tone, art-directing it to the Vision's world, optimizing its weight, giving it accessible meaning), often composing sourced assets with coded behavior. It designs the architecture and confirms it before implementing (architecture-first), wraps imperative libraries behind clean Angular seams (angular-native-wrappers), and verifies the built result against the feeling AND the Staging in the running app, not merely that it renders — and it does NOT self-certify aesthetics (a model is confidently wrong about taste): mechanics it checks itself, but whether it looks good and the moment lands is judged against the Staging and by an outside eye (the user, or the great work it adapts), never by its own sense of nice, and it engineers the moments and structure the Staging specifies rather than reskinning the same boxes. Where work is genuinely independent it fans out across subagents — researching the means, sourcing asset candidates, building independent regions, and running verification lenses concurrently — always against the Vision as the shared contract, and always converging on a coherence pass so the parallel pieces add up to one feeling (never fanning out the parts that must know the whole — the rhythm, palette, motion language, and emotional arc). Routes to a reference library (motion & timelines; depth/3D/spatial; scroll & cinematic; SVG/canvas/generative; build-vs-source / sourcing & generating assets; performance & budgets; responsive & adaptive layout — engineering each moment's per-form-factor staging, re-composing rather than shrinking; accessibility/reduced-motion/fallbacks; sound & haptics) — read only the cluster you need. The downstream building member of the experience-design trio envision-the-experience (feeling) → stage-the-vision (the bold, web-native Staging) → realize-the-vision (build); a direct expression of engineering:architect-mentality and engineering:architecture-first.
Install with
Claude CodeCodexCursorGitHub CopilotGemini CLI
Supported by the Atlas install prompt. Skill-specific requirements vary.
Skill stats
Skills1CategoryScience & researchStars0
About this skill
The craftsman that turns a Vision (the experiential spec produced by envision-the-experience) into a real, running interface — by researching the truest, soundest means BEFORE writing a line of implementation. Use whenever you are about to build, prototype, or technically realize a distinctive/immersive/experiential UI — animation, motion, depth or 3D, scroll-choreography, cinematic transitions, generative or hand-drawn visuals, sound, haptics — or whenever you must choose the tools, frameworks, libraries, rendering approach, or architecture for an interface whose feeling matters. This skill does NOT jump to code. It requires two contracts before any high-fidelity build — the Vision (the feeling, from envision-the-experience) AND the Staging (the bold, web-native art direction — the central concept, the staged artistic moments, and the visual system — from stage-the-vision); if no confirmed Staging exists it produces one with stage-the-vision first and never invents the art itself from the feeling (the exact vacuum the model's default taste rushes to fill — card grids, then blobs/gradients, then garish saturation). Its job is to engineer each staged moment soundly, not to design it. It reads the Vision as a contract (the feeling is what must survive, not any particular widget), translates that feeling into what it technically demands, then RESEARCHES the field — surveying the means that could produce it, weighing their tradeoffs, nuances, and caveats — and only then chooses deliberately, fitted to the vision AND the real constraints (performance budget, accessibility, target devices, the team's stack, long-term maintainability), never by default, fashion, or familiarity. It is the experienced practitioner who knows the landscape (GSAP, Motion, three.js / React-Three-Fiber / angular-three, Web Animations API, CSS scroll-driven animations, View Transitions, Lottie/Rive, Canvas/SVG/WebGL/WebGPU, Web Audio, the Vibration API) and its footguns (jank, layout thrash, main-thread blocking, vestibular harm, missing reduced-motion fallbacks, broken keyboard/screen-reader semantics under custom visuals) — and compensates for them up front. It also knows the boundary of what code (and an LLM) builds well versus what must be sourced — generated, downloaded, licensed, or commissioned: figurative or photoreal art (a couple kissing, a landscape, a mascot, a textured hero) is acquired from image/video/3D generation, stock, or open icon/SVG/illustration/Lottie/3D-model libraries, never hand-coded into grotesque path-soup — and it handles that path's caveats (licensing and commercial rights, reviewing every generated asset for artifacts/bias/tone, art-directing it to the Vision's world, optimizing its weight, giving it accessible meaning), often composing sourced assets with coded behavior. It designs the architecture and confirms it before implementing (architecture-first), wraps imperative libraries behind clean Angular seams (angular-native-wrappers), and verifies the built result against the feeling AND the Staging in the running app, not merely that it renders — and it does NOT self-certify aesthetics (a model is confidently wrong about taste): mechanics it checks itself, but whether it looks good and the moment lands is judged against the Staging and by an outside eye (the user, or the great work it adapts), never by its own sense of nice, and it engineers the moments and structure the Staging specifies rather than reskinning the same boxes. Where work is genuinely independent it fans out across subagents — researching the means, sourcing asset candidates, building independent regions, and running verification lenses concurrently — always against the Vision as the shared contract, and always converging on a coherence pass so the parallel pieces add up to one feeling (never fanning out the parts that must know the whole — the rhythm, palette, motion language, and emotional arc). Routes to a reference library (motion & timelines; depth/3D/spatial; scroll & cinematic; SVG/canvas/generative; build-vs-source / sourcing & generating assets; performance & budgets; responsive & adaptive layout — engineering each moment's per-form-factor staging, re-composing rather than shrinking; accessibility/reduced-motion/fallbacks; sound & haptics) — read only the cluster you need. The downstream building member of the experience-design trio envision-the-experience (feeling) → stage-the-vision (the bold, web-native Staging) → realize-the-vision (build); a direct expression of engineering:architect-mentality and engineering:architecture-first.
Quick start
Copy the install prompt. Use the green button above this README.
Send it to your agent. Paste it into your coding agent’s chat and send.
Review the setup. Your agent checks the skill’s instructions, requirements, and installation scope.
The craftsman that turns a Vision (the experiential spec produced by `envision-the-experience`) into a real, running interface — by researching the truest, soundest means BEFORE writing a line of implementation. Use whenever you are about to build, prototype, or technically realize a distinctive/immersive/experiential UI — animation, motion, depth or 3D, scroll-choreography, cinematic transitions, generative or hand-drawn visuals, sound, haptics — or whenever you must choose the tools, frameworks, libraries, rendering approach, or architecture for an interface whose feeling matters. This skill does NOT jump to code. It requires two contracts before any high-fidelity build — the Vision (the *feeling*, from `envision-the-experience`) AND the Staging (the bold, web-native art direction — the central concept, the staged artistic moments, and the visual system — from `stage-the-vision`); if no confirmed Staging exists it produces one with `stage-the-vision` first and never invents the art itself from the feeling (the exact vacuum the model's default taste rushes to fill — card grids, then blobs/gradients, then garish saturation). Its job is to engineer each staged moment soundly, not to design it. It reads the Vision as a contract (the *feeling* is what must survive, not any particular widget), translates that feeling into what it technically demands, then RESEARCHES the field — surveying the means that could produce it, weighing their tradeoffs, nuances, and caveats — and only then chooses deliberately, fitted to the vision AND the real constraints (performance budget, accessibility, target devices, the team's stack, long-term maintainability), never by default, fashion, or familiarity. It is the experienced practitioner who knows the landscape (GSAP, Motion, three.js / React-Three-Fiber / angular-three, Web Animations API, CSS scroll-driven animations, View Transitions, Lottie/Rive, Canvas/SVG/WebGL/WebGPU, Web Audio, the Vibration API) and its footguns (jank, layout thrash, main-thread blocking, vestibular harm, missing reduced-motion fallbacks, broken keyboard/screen-reader semantics under custom visuals) — and compensates for them up front. It also knows the boundary of what code (and an LLM) builds *well* versus what must be *sourced* — generated, downloaded, licensed, or commissioned: figurative or photoreal art (a couple kissing, a landscape, a mascot, a textured hero) is acquired from image/video/3D generation, stock, or open icon/SVG/illustration/Lottie/3D-model libraries, never hand-coded into grotesque path-soup — and it handles that path's caveats (licensing and commercial rights, reviewing every generated asset for artifacts/bias/tone, art-directing it to the Vision's world, optimizing its weight, giving it accessible meaning), often composing sourced assets with coded behavior. It designs the architecture and confirms it before implementing (architecture-first), wraps imperative libraries behind clean Angular seams (angular-native-wrappers), and verifies the built result against the *feeling* AND the Staging in the running app, not merely that it renders — and it does NOT self-certify aesthetics (a model is confidently wrong about taste): mechanics it checks itself, but whether it looks good and the moment lands is judged against the Staging and by an outside eye (the user, or the great work it adapts), never by its own sense of nice, and it engineers the moments and structure the Staging specifies rather than reskinning the same boxes. Where work is genuinely independent it fans out across subagents — researching the means, sourcing asset candidates, building independent regions, and running verification lenses concurrently — always against the Vision as the shared contract, and always converging on a coherence pass so the parallel pieces add up to one feeling (never fanning out the parts that must know the whole — the rhythm, palette, motion language, and emotional arc). Routes to a reference library (motion & timelines; depth/3D/spatial; scroll & cinematic; SVG/canvas/generative; build-vs-source / sourcing & generating assets; performance & budgets; responsive & adaptive layout — engineering each moment's per-form-factor staging, re-composing rather than shrinking; accessibility/reduced-motion/fallbacks; sound & haptics) — read only the cluster you need. The downstream *building* member of the experience-design trio `envision-the-experience` (feeling) → `stage-the-vision` (the bold, web-native Staging) → `realize-the-vision` (build); a direct expression of `engineering:architect-mentality` and `engineering:architecture-first`.
About this listing
Category
Science & research
Reported license
Not specified
Listing language (estimated)
English
Review status
Not individually reviewed
Agent compatibility
Atlas installation supports Claude Code, Codex, and Cursor. Skill-specific dependencies and features are checked during setup.