feat(skills): add design-motion-principles from kylezantos

Motion/animation design skill with 3-designer lens (Emil Kowalski,
Jakub Krehel, Jhey Tompkins). Two modes: Create and Audit.
Complements frontend-design (broad) with deep motion expertise.

Integration points:
- skills-external/design-motion-principles/ — skill files + references
- link.sh EXTERNAL_SKILLS — symlink to ~/.claude/skills/
- install-plugins.sh step 8c — presence check
- update-all.sh step 7.2 — sync from GitHub
- profiles: design, full, web, web-full — listed as external
- plugin-advisor — decision table, recommended sets, conditional rules
- design-gate — symlink check + non-blocking warning if missing

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

skills-external/design-motion-principles/workflows/create.md

@@ -0,0 +1,87 @@
+# Workflow: Create Mode
+
+Build interactive components with purposeful motion. Light discovery, then generate against the cookbook.
+
+## Required Reading
+
+Read before generating:
+1. `references/motion-cookbook.md` — the recipe source for all motion code
+2. `references/accessibility.md` — `prefers-reduced-motion` is mandatory in everything you generate
+3. `references/creation-gotchas.md` — Claude's failure modes when writing motion; self-check against these
+
+---
+
+## STEP 1: Light Discovery
+
+Establish two things — project context and designer weighting — before generating. Keep it to 1-2 questions.
+
+### Infer First, Ask Second
+
+Check what you can already see:
+- **The request** — what component, what interaction, what stack (React / Framer Motion / CSS / HTML)?
+- **CLAUDE.md, package.json, existing components** — project type and existing animation conventions (durations, easing, libraries)
+
+### Propose Context + Weighting
+
+Map the project type to a perspective weighting using the Context-to-Perspective Mapping table in SKILL.md. State your inference in one short block:
+
+```
+Building: [what — e.g. "a notification toast, React + Framer Motion"]
+Project context: [inferred — e.g. "productivity SaaS dashboard"]
+Proposed weighting: Primary [Designer] · Secondary [Designer]
+```
+
+If `AskUserQuestion` is available and the weighting is genuinely ambiguous, offer:
+- **Confirm** — proceed with the proposed weighting
+- **Adjust** — change primary/secondary designer
+
+Otherwise ask in plain text: "Does this weighting sound right, or should I adjust?"
+
+### Wait Gate
+
+For non-trivial components, **confirm context before generating**. For a small, well-specified request ("add a press-scale to this button"), state the inference in one line and skip straight to STEP 3 — don't manufacture a question.
+
+---
+
+## STEP 2: Load Weighted Knowledge
+
+Based on the confirmed weighting, read the relevant designer file(s):
+- **Read `references/emil-kowalski.md`** if Emil is primary/secondary — restraint, the frequency rule, when NOT to animate
+- **Read `references/jakub-krehel.md`** if Jakub is primary/secondary — production polish judgment, subtlety bar
+- **Read `references/jhey-tompkins.md`** if Jhey is primary/secondary — playful expression, what motion could become
+
+The designer files give you the **judgment** (should this animate, what feel). The cookbook gives you the **code**.
+
+If the component involves complex or numerous animations, also read `references/performance.md`.
+
+---
+
+## STEP 3: Generate
+
+Build the component. Apply, in order:
+
+1. **The frequency gate (Emil)** — Should this animate at all? High-frequency or keyboard-initiated interactions get minimal or no motion. Decide before adding anything.
+2. **Recipes from the cookbook** — Use the weighted designer's patterns. Enter = opacity + translateY + blur. Exit subtler than enter. Custom easing or springs, never bare `ease`.
+3. **Accessibility** — Every animation ships with `prefers-reduced-motion` handling, in the same code. No exceptions, no follow-up.
+4. **Performance** — Animate `transform` / `opacity` / `filter` only. Never `width` / `height` / `top` / `left`.
+5. **Context-appropriate timing** — Emil-weighted → under 300ms. Jakub → 200-500ms polish. Jhey → whatever serves the effect.
+
+---
+
+## STEP 4: Self-Check
+
+Before presenting, verify the generated code against every item in `references/creation-gotchas.md`. Fix anything that matches a gotcha.
+
+Then briefly tell the user the motion decisions you made and why — which designer weighting drove the timing, easing, and whether something was deliberately left un-animated.
+
+---
+
+## Success Criteria
+
+- [ ] Context and weighting confirmed (or inference stated for trivial requests)
+- [ ] Frequency gate applied — motion is purposeful, not decorative-by-default
+- [ ] Recipes drawn from the cookbook, matched to the designer weighting
+- [ ] `prefers-reduced-motion` handled in all generated motion
+- [ ] Only `transform` / `opacity` / `filter` animated
+- [ ] Code self-checked against creation-gotchas.md
+- [ ] Motion decisions explained to the user