Scaffold a new motion-* web component end-to-end — TypeScript source, types file, Vite build entry, package.json subpath export, src/index.ts re-export, and a docs page. Use when the user asks to add, scaffold, or create a new component named like motion-X.
Audit the codebase for animation primitive violations, duplicated animation logic, composition opportunities, and architectural drift. Produces a prioritized list of improvements with specific file locations.
Ask focused clarifying questions before building any new component or feature. Forces shared understanding of animation behavior, props API, trigger conditions, accessibility, and done criteria BEFORE writing any code.
Turn a vague component idea or feature request into a structured Product Requirements Document covering purpose, props API, animation behavior spec, accessibility, and docs structure. Use before implementing anything non-trivial.
Run pre-publish verification for the motion-components package — typecheck, preload-rule check, library build, and bundle size budget. Use before bumping the version or running npm publish.
Spec-first development loop for motion components — define the types contract and observable behavior before writing any implementation code, then implement to match the spec. Prevents drift between intent and code.
The motion-components project conventions — code style, component architecture, animation rules, doc page structure, naming, and what NOT to do. Reference this whenever editing source, adding components, or writing docs pages.
Break a PRD or feature description into discrete, actionable work items ordered by dependency. Outputs a numbered list of tasks ready to implement one at a time, each small enough to complete in a single session.