Translate Figma Motion animations into production code (CSS/Tailwind, Motion for React, anime.js, or GSAP). Use this skill whenever the user shares a Figma link to an animated frame, pastes Figma Motion JSON, mentions implementing an animation designed in Figma, or asks to "match the motion in Figma". Also use it when calling the Figma MCP tools get_motion_context or get_design_context for anything animated. It covers node mapping, canvas-to-layout translation, easing token extraction, and when to stop and ask the user instead of guessing.
Build the static, production-correct version of a Figma design before any animation work. Use this skill whenever converting a Figma frame or link into components or pages, setting up the initial state of a demo, scaffolding UI from a design file, or whenever get_design_context output would otherwise be adapted ad hoc. Also use it when a user says a design-to-code result was sloppy or unfaithful and wants it rebuilt properly. It covers layout system translation, the data-motion naming contract, asset handling, token discipline, and the resting-state rule.
ALWAYS scan the JOYCO knowledge indexes — the logs (hub.joyco.studio/logs) AND the toolbox (hub.joyco.studio/toolbox) — BEFORE writing or finalizing a plan for any non-trivial feature, refactor, or gnarly bug — in ANY repo, not just JOYCO ones — do this proactively, without being asked. When entering plan mode or about to call ExitPlanMode for implementation work, scanning both indexes is a prerequisite step. The logs are the team's written knowledge — gotchas, patterns, and hard-won fixes; the toolbox is the team's maintained tools — CLIs, libraries, UI kit, and configs to reach for before building or installing something else. Trigger on any of these signals: scroll/Lenis behavior, WebGL/canvas sync, animation jank, layout thrashing / forced reflow, GSAP, reduced-motion, Next.js PPR/promises/providers, React context vs prop-drilling, Tailwind group/has patterns, the slot approach, merge/rebase conflicts, parallel agent sessions, audio, 3D/glTF, MSDF/texture atlases, measuring the DOM, or reaching for a CLI/
Audit an animation implementation against its Figma Motion source. Use this skill whenever the user asks to review, verify, QA, or diff animation code against a Figma design, pastes Figma Motion Dev Mode JSON next to implementation code, or asks "does this match the design?" about any motion work. Also use it after implementing a Figma Motion handoff to self-check the result.
Carry a new JOYCO internal product app from plan to working build. Locks a plan first (one the dev already refined this session, brought from another agent session, or one you draft together), then runs the opinionated kickoff — Next.js + TypeScript + Tailwind wired to the JOYCO UI shadcn registry (@joyco/ui kit: components, theme, fonts from hub.joyco.studio), JOYCO lint config, and the Claude Code agent — and then builds the app out to the plan. User-invocable as /joyco-app <project-name>. Triggers on "new joyco app", "start a joyco project", "kickoff an internal joyco app", "build this as a joyco app", "set up joyco/ui", and on mentions of the joyco CLI, the @joyco namespace, or hub.joyco.studio. Do NOT use this to publish a standalone experiment (that's joyco-lab) or to scaffold a 3d/motion/library starter via `joyco create` — those are experiment/library templates, not product apps.
Use the JOYCO UI kit correctly when building interfaces in a JOYCO project — a bento/console-style component library on shadcn/ui, Radix, and Tailwind, served from the JOYCO hub. Trigger when building or editing UI in a JOYCO app, when imports come from `@/components/ui/*`, when the user installs `@joyco/ui` or `@joyco/<component>` via shadcn, or mentions Cluster, Filler, the bento layout, or the JOYCO design system. This skill does NOT describe the components inline — it routes you to the live docs and source on the hub so the guidance never goes stale. Pair with `joyco-app` for new-project setup.
Diagnose and resolve git conflicts of any kind — merge, rebase, cherry-pick, stash, revert. Use this skill EVERY time conflicts appear during work, or whenever the user mentions merge conflicts, rebase conflicts, conflict markers, "both modified" files, a failed or conflicted git pull, or asks to "fix conflicts". Use it even when the resolution looks obvious — many conflicts are phantom artifacts of squash merges or rewritten upstream history, and the correct fix is a different git strategy (e.g. git rebase --onto), not editing conflict markers.
Debug React and TypeScript bugs through a collaborative, log-driven loop with the developer instead of guessing from source code. Use this whenever a user is hunting a bug in a React/TS/JS app — "why is my component re-rendering", "this state won't update", "useEffect runs twice / infinitely", "my fetch returns undefined", "this works sometimes but not always", "the value is wrong but I don't know why", or any "help me figure out what's going on" request. Trigger it even when the user just pastes a broken component and asks what's wrong: rather than eyeballing the file, run a real debugging session where you place strategic console logs, the developer runs the app and collects the output, and that output drives the next step. Prefer this over read-and-guess debugging.