メニュー
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.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
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.
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.
| name | plan |
| description | 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. |
Convert a component idea or feature request into a formal Product Requirements Document (PRD). Output a complete spec that can be handed to /new-component or used as a reference during implementation. The PRD becomes the source of truth — implementation must match it, not the other way around.
motion-* component is being planned/clarify questions and is ready to formalize requirementsProduce a markdown document with exactly these sections:
<motion-tag-name>One paragraph. What this component does, why it exists, and what problem it solves for the developer using the library.
Which source directory: primitives / text / scroll / interaction — and the rationale.
Which motion primitives this component builds on (if any): <motion-reveal>, <motion-hover>, <motion-press>, <motion-stagger>, or "none — novel widget".
| Attribute | Type | Default | Description |
|---|---|---|---|
foo | string | "bar" | What it controls. |
List every attribute. For string-literal types, list the accepted values.
Describe the animation in plain English:
bounce and duration valuesDescribe the degraded experience when prefers-reduced-motion: reduce is set. Either: skip animation (apply final state instantly), simplify to a fade-only, or describe the alternative.
| Slot | Description |
|---|---|
| (default) | What slotted content is expected |
<DocsPreview> (HTML structure, placeholder content)Checkbox list. Implementation is complete when ALL are checked:
List what this component explicitly does NOT do.
[NEEDS DECISION] — don't invent answers.After the PRD is approved, pass it to the tasks skill (.claude/skills/tasks/SKILL.md) to decompose into actionable work items.
clarify skill (.claude/skills/clarify/SKILL.md)tasks skill (.claude/skills/tasks/SKILL.md)style-guide skill (.claude/skills/style-guide/SKILL.md)