// Push interfaces past conventional limits with technically ambitious implementations. Whether that's a shader, a 60fps virtual table, spring physics on a dialog, or scroll-driven reveals — make users ask "how did they do that?"
Adapt designs to work across different screen sizes, devices, contexts, or platforms. Ensures consistent experience across varied environments.
Analyze a feature and strategically add animations and micro-interactions that enhance understanding, provide feedback, and create delight.
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, artifacts, posters, or applications. Generates creative, polished code that avoids generic AI aesthetics.
One-time setup that gathers design context for your project and saves it to your AI config file. Run once to establish persistent design guidelines.
| name | overdrive |
| description | Push interfaces past conventional limits with technically ambitious implementations. Whether that's a shader, a 60fps virtual table, spring physics on a dialog, or scroll-driven reveals — make users ask "how did they do that?" |
Start your response with:
──────────── ⚡ OVERDRIVE ─────────────
》》》 Entering overdrive mode...
Push an interface past conventional limits. This isn't just about visual effects — it's about using the full power of the browser to make any part of an interface feel extraordinary: a table that handles a million rows, a dialog that morphs from its trigger, a form that validates in real-time with streaming feedback, a page transition that feels cinematic.
Use the frontend-design skill — it contains design principles, anti-patterns, and the Context Gathering Protocol. Follow the protocol before proceeding — if no design context exists yet, you MUST run teach-impeccable first.
EXTRA IMPORTANT FOR THIS SKILL: Context determines what "extraordinary" means. A particle system on a creative portfolio is impressive. The same particle system on a settings page is embarrassing. But a settings page with instant optimistic saves and animated state transitions? That's extraordinary too. Understand the project's personality and goals before deciding what's appropriate.
This skill has the highest potential to misfire. Do NOT jump straight into implementation. You MUST:
Skipping this step risks building something embarrassing that needs to be thrown away.
Technically ambitious effects almost never work on the first try. You MUST actively use browser automation tools to preview your work, visually verify the result, and iterate. Do not assume the effect looks right — check it. Expect multiple rounds of refinement. The gap between "technically works" and "looks extraordinary" is closed through visual iteration, not code alone.
The right kind of technical ambition depends entirely on what you're working with. Before choosing a technique, ask: what would make a user of THIS specific interface say "wow, that's nice"?
Pages, hero sections, landing pages, portfolios — the "wow" is often sensory: a scroll-driven reveal, a shader background, a cinematic page transition, generative art that responds to the cursor.
Tables, forms, dialogs, navigation — the "wow" is in how it FEELS: a dialog that morphs from the button that triggered it via View Transitions, a data table that renders 100k rows at 60fps via virtual scrolling, a form with streaming validation that feels instant, drag-and-drop with spring physics.
The "wow" is invisible but felt: a search that filters 50k items without a flicker, a complex form that never blocks the main thread, an image editor that processes in near-real-time. The interface just never hesitates.
Charts and dashboards — the "wow" is in fluidity: GPU-accelerated rendering via Canvas/WebGL for massive datasets, animated transitions between data states, force-directed graph layouts that settle naturally.
The common thread: something about the implementation goes beyond what users expect from a web interface. The technique serves the experience, not the other way around.
Organized by what you're trying to achieve, not by technology name.
@starting-style (all browsers) — animate elements from display: none to visible with CSS only, including entry keyframesanimation-timeline: scroll()) — CSS-only, no JS. Parallax, progress bars, reveal sequences all driven by scroll position. (Chrome/Edge/Safari; Firefox: flag only — always provide a static fallback)transition() or View Transitions for DOM-based charts.@property (all browsers) — register custom CSS properties with types, enabling animation of gradients, colors, and complex values that CSS can't normally interpolate.NOTE: This skill is about enhancing how an interface FEELS, not changing what a product DOES. Adding real-time collaboration, offline support, or new backend capabilities are product decisions, not UI enhancements. Focus on making existing features feel extraordinary.
Every technique must degrade gracefully. The experience without the enhancement must still be good.
@supports (animation-timeline: scroll()) {
.hero { animation-timeline: scroll(); }
}
if ('gpu' in navigator) { /* WebGPU */ }
else if (canvas.getContext('webgl2')) { /* WebGL2 fallback */ }
/* CSS-only fallback must still look good */
prefers-reduced-motion — always. Provide a beautiful static alternative.The gap between "cool" and "extraordinary" is in the last 20% of refinement: the easing curve on a spring animation, the timing offset in a staggered reveal, the subtle secondary motion that makes a transition feel physical. Don't ship the first version that works — ship the version that feels inevitable.
NEVER:
prefers-reduced-motion — this is an accessibility requirement, not a suggestionRemember: "Technically extraordinary" isn't about using the newest API. It's about making an interface do something users didn't think a website could do.