[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M7514NMJSFGF8RM6A6RWP1ZE":3,"skill-same:01M7514NMJSFGF8RM6A6RWP1ZE":49},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":19,"linkOnly":20,"markdownContent":21,"markdownBody":22,"frontMatter":23,"refName":26,"commitSha":27,"skillDirectory":28,"forksCount":29,"repositoryHtmlUrl":30,"repositoryHomepageUrl":31,"ownerHtmlUrl":32,"ownerBlogUrl":31,"ownerDescription":33,"updatedAt":34,"install":35,"resources":48},"01M7514NMJSFGF8RM6A6RWP1ZE","motion-design-principles",null,"The craft layer for motion: pick the right easing (ease-in, ease-out, ease-in-out, spring), get timing and spacing right, build the anticipation-action-follow-through arc, and apply Disney's 12 principles to UI and product video. Use when animating any UI transition, modal, button, page load, or product-video scene, or when someone says \"make this feel less janky\", \"smoother\", \"more polished\", \"the animation feels off\", \"why does this look cheap\", or asks \"ease-in or ease-out\" \u002F \"spring or interpolate\". Do NOT use for shot planning (use video-storyboard), directing a product demo (use product-demo-director), animating text (use kinetic-typography), timing to music (use sound-and-music-sync), platform reframing (use social-video-formatter), or color and light (use motion-color-and-light).","SkillMedev\u002Fskills","SkillMedev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F298078254?v=4","01M74ZSGTQ918CB0VXW4EG3RMX","SkillMe","01M74ZSGVBT497NA95CBT8JTY4",25,"MIT","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmotion-design-principles\u002FSKILL.md",[],[],"2026-11-11 18:11:01",false,"---\nname: motion-design-principles\ndescription: \"The craft layer for motion: pick the right easing (ease-in, ease-out, ease-in-out, spring), get timing and spacing right, build the anticipation-action-follow-through arc, and apply Disney's 12 principles to UI and product video. Use when animating any UI transition, modal, button, page load, or product-video scene, or when someone says \\\"make this feel less janky\\\", \\\"smoother\\\", \\\"more polished\\\", \\\"the animation feels off\\\", \\\"why does this look cheap\\\", or asks \\\"ease-in or ease-out\\\" \u002F \\\"spring or interpolate\\\". Do NOT use for shot planning (use video-storyboard), directing a product demo (use product-demo-director), animating text (use kinetic-typography), timing to music (use sound-and-music-sync), platform reframing (use social-video-formatter), or color and light (use motion-color-and-light).\"\nmetadata:\n  title: \"Motion Design Principles\"\n---\n\n# Motion Design Principles\n\nThis is the taste layer. It decides *how* something should move so it reads as\npolished and intentional instead of janky, floaty, or cheap. It does not write\nthe code that plays the motion — once you have decided the curve, the timing, and\nthe arc, that decision is the *input* to a directing\u002Frender skill (for product\nvideo, hand it to **product-demo-director**) or to your CSS\u002FJS transition (for\nUI). Keep the two jobs separate: this skill owns the judgment; the directing\nskill owns the orchestration and mechanics.\n\nFire on anything about how motion *feels*: \"make this less janky\", \"smoother\",\n\"more polished\", \"more alive\", \"the easing is off\", \"this looks cheap\", \"should I\nease-in or ease-out\", \"spring or interpolate\".\n\n## When to use a sibling instead\n\nThis skill is the curve\u002Ftiming\u002Farc judgment only. Defer when the real question is:\n\n- **Which shots, scene order, or a beat list** → **video-storyboard**.\n- **Directing a full product demo** — cursor moves, screen captures, feature\n  callouts, the end-to-end scene assembly → **product-demo-director**. (This skill\n  produces the motion spec it consumes.)\n- **Animating text or letterforms** — type that flies\u002Fbuilds\u002Freveals →\n  **kinetic-typography**.\n- **Timing motion to a beat, score, or sound effect** → **sound-and-music-sync**.\n- **Cropping or reframing for a platform** (9:16, 1:1, safe areas) →\n  **social-video-formatter**.\n- **Light, exposure, glow, or color motion** → **motion-color-and-light**.\n\n## Operating procedure\n\nDiagnose before you prescribe. Most \"janky\" motion is one of four named\nproblems, and each maps to a specific fix below. Work the steps in order — the\neasing fix is worthless if the timing is wrong, and the timing fix is worthless\nif the element has no arc.\n\n### Step 1: Name what feels wrong\n\nWatch the motion (or the description of it) and classify it. Almost every\ncomplaint is one of these:\n\n- **Linear \u002F robotic** — moves at constant speed, stops dead. No easing. Fix in\n  Step 2.\n- **Floaty \u002F mushy** — too slow, or eases in *and* out when it should snap in.\n  Wrong duration or wrong curve. Fix in Step 2 and Step 3.\n- **Janky \u002F stuttery** — enters and exits at the same speed, or every property\n  animates on the same flat timeline with no offset. Missing spacing and arc.\n  Fix in Step 3 and Step 4.\n- **Dead \u002F lifeless** — technically correct but boring: no anticipation, no\n  overshoot, no follow-through. Missing the arc and secondary motion. Fix in\n  Step 4 and Step 5.\n\nWrite the diagnosis down in one line before touching anything. \"The modal is\nfloaty because it fades over 600ms with ease-in-out\" is a fix; \"make it nicer\"\nis not.\n\n### Step 2: Pick the easing curve\n\nEasing is the speed-over-time shape of the motion. The curve carries almost all\nthe perceived quality. Match the curve to what the element is doing:\n\n- **ease-out** (fast start, slow settle) — the default for **things entering** and\n  for anything the user triggered. It feels responsive because motion begins\n  immediately, then decelerates into place. Use for: elements appearing,\n  dropdowns opening, a tapped button responding, content sliding in. If unsure,\n  reach for ease-out.\n- **ease-in** (slow start, fast exit) — for **things leaving**. The element\n  accelerates away off-screen. Used alone on an *entrance* it feels sluggish and\n  laggy, which is the #1 cause of \"floaty\". Use for: dismissals, close, exits.\n- **ease-in-out** (slow, fast, slow) — for **moving something already on screen\n  from A to B**: a card reordering, a carousel advancing, a toggle sliding. Both\n  ends are anchored, so easing both ends reads as controlled. Do not use it for\n  entrances — the slow start kills responsiveness.\n- **spring** (physics: mass, stiffness, damping — overshoots and settles) — for\n  motion that should feel **alive and physical**: a modal popping in, a toggle\n  knob, a like button, a notification dropping in. The slight overshoot is what\n  reads as \"alive\". Tune damping for personality: lower damping = bouncier and\n  more playful, higher damping = tighter and more corporate.\n\nThe `spring() vs interpolate()` decision (when you reach for each in code) is in\nthe **Quality bar** and the runnable artifact below. The short version: spring\nfor physical\u002Flively transforms, interpolate for precise timed-to-the-frame values\nlike opacity fades, color, and progress bars.\n\n### Step 3: Set timing and spacing\n\n**Timing** is total duration. **Spacing** is how the distance is distributed\nacross that duration — spacing *is* easing made literal (an ease-out is bunched\nframes at the end). Two rules:\n\n- **Duration scales with distance and size, not taste.** A small element moving a\n  short distance should be fast (UI: ~150–250ms). A large element or a long\n  travel needs longer (~300–500ms) or it teleports. Big full-screen \u002F hero\n  motion in video can run longer. Same motion, longer distance → longer duration.\n- **Enter and exit are not symmetric.** Exits should be faster than entrances\n  (~0.7–0.8x) — the user is done with the element, so get it out of the way.\n  Equal enter\u002Fexit durations are a classic source of \"janky\".\n\nFor product video, convert to frames the moment you leave this skill:\n`frames = round(seconds * fps)`. Those frame counts are the literal input you\nhand to **product-demo-director** (which turns them into the timed scene plan).\n\n### Step 4: Build the anticipation → action → follow-through arc\n\nReal motion is rarely a single move. The richest, most \"alive\" motion has three\nbeats:\n\n1. **Anticipation** — a tiny opposite-direction wind-up before the main move (a\n   button dips *in* slightly before popping, a card pulls back before sliding\n   out). It primes the eye and makes the action read as intentional. Keep it\n   small and fast; too much looks like a glitch.\n2. **Action** — the main move, carrying the easing from Step 2 and the duration\n   from Step 3. This is where the spacing lives.\n3. **Follow-through** — the element settles past its target and back (the spring\n   overshoot), and any attached\u002Fsecondary elements lag slightly behind the\n   leader (a label catching up to the card it sits on). This is what sells\n   weight and life.\n\nNot every micro-interaction needs all three — a 150ms tooltip is just action. But\nwhen something feels \"dead\", it is almost always missing anticipation or\nfollow-through. Add the arc before adding flourish.\n\n### Step 5: Apply the relevant Disney principles\n\nDisney's 12 principles of animation map directly onto UI and product motion. You\ndo not apply all twelve; you reach for the few that fix the diagnosed problem.\nThe full mapping is in `references\u002Ftwelve-principles`. The high-leverage ones:\n\n- **Slow in & slow out** → easing (Step 2). The single biggest quality lever.\n- **Anticipation** → the wind-up (Step 4).\n- **Follow-through & overlapping action** → overshoot + lagging secondary\n  elements (Step 4). The difference between \"correct\" and \"alive\".\n- **Timing** → duration and spacing (Step 3).\n- **Squash & stretch** → subtle scale on press\u002Fimpact to imply mass; in UI keep\n  it to a few percent or it looks like a toy.\n- **Staging** → move one thing at a time so the eye knows where to look; never\n  animate six things at once on the same curve.\n- **Secondary action** → a small supporting motion (a shadow deepening as a card\n  lifts) that reinforces the main one without competing.\n- **Exaggeration** → push the key pose slightly past realistic; restrained in UI,\n  freer in a punchy product video.\n\n### Step 6: Hand off the spec\n\nFill the motion-spec template below — curve, duration (and frames), the arc\nbeats, and the spring-vs-interpolate call per property. That filled spec is the\nhandoff artifact: for a product-video scene it goes straight into\n**product-demo-director**; for UI it becomes your transition\u002Fkeyframe values.\nPair it with **motion-color-and-light** if the scene also needs light\u002Fexposure\nmotion, **kinetic-typography** if text is animating, and **sound-and-music-sync**\nif the timing must land on a beat.\n\n## Quality bar\n\nMotion is A+ only when all of these hold:\n\n- The diagnosis is named (linear \u002F floaty \u002F janky \u002F dead), and every change traces\n  to it. No \"made it nicer\" without a reason.\n- **Entrances ease-out, exits ease-in, on-screen A→B ease-in-out, lively\u002Fphysical\n  uses spring.** No raw linear motion ships except deliberate constant-speed\n  loops (a spinner, a marquee).\n- Duration scales with distance\u002Fsize, and the exit is faster than the entrance.\n- The `spring()` vs `interpolate()` call is explicit per property: **spring for\n  physical transforms** (scale, translate, the pop\u002Fslide\u002Fsettle — you want the\n  overshoot); **interpolate for precise timed values** (opacity fades, color,\n  progress, anything where overshoot would look wrong). A fade driven by a spring,\n  or a logo pop driven by linear interpolate, is a defect.\n- At least one of anticipation or follow-through is present on hero \u002F signature\n  motion; lifeless motion is missing exactly these.\n- One thing leads at a time (staging); properties are offset rather than all\n  firing on one flat timeline.\n- Curve, duration, and frame counts are written down and ready to hand to\n  product-demo-director or a transition — this skill never leaves the decision\n  implicit.\n\n## Do NOT\n\n- Do NOT ship linear easing for entrances or exits — it is the robotic default and\n  reads as unfinished. Constant speed is only for intentional loops.\n- Do NOT ease-in an entrance or ease-out an exit — that is the floaty\u002Flaggy feel\n  reversed. Entrances ease-out, exits ease-in.\n- Do NOT use equal enter and exit durations; exits should be ~0.7–0.8x faster.\n- Do NOT drive a fade, color, or progress bar with a spring — the overshoot makes\n  values run past their range and flash. Use interpolate for timed values.\n- Do NOT drive a lively pop\u002Fslide\u002Fscale with linear interpolate when you want it\n  to feel alive — use a spring for the overshoot.\n- Do NOT animate many properties on one flat timeline; stage and offset them.\n- Do NOT over-anticipate or over-overshoot in UI — a few pixels \u002F a few percent.\n  Big wind-ups and bounces read as a glitch or a toy.\n- Do NOT plan shot order or assemble the demo here — hand the spec to\n  product-demo-director; storyboard order is video-storyboard.\n\n## Easing & spring picker\n\nSelf-contained Node script. Save as `motion_pick.js` and run with\n`node motion_pick.js`. Edit the `requests` array for the elements you are\nanimating; it returns the curve, a distance-scaled duration (ms and frames), the\nexit duration, and the spring-vs-interpolate call. No dependencies.\n\n```javascript\n\u002F\u002F Motion picker. Edit `requests`, then: node motion_pick.js\nconst fps = 30 \u002F\u002F for product video; UI ignores the frame column\n\n\u002F\u002F role: 'enter' | 'exit' | 'move' | 'lively'\n\u002F\u002F distancePx: how far it travels (drives duration). sizePx: rough element size.\nconst requests = [\n  { name: 'Modal pop-in',    role: 'lively', property: 'scale',   distancePx: 0,   sizePx: 600 },\n  { name: 'Modal backdrop',  role: 'enter',  property: 'opacity', distancePx: 0,   sizePx: 1920 },\n  { name: 'Toast slide-in',  role: 'enter',  property: 'translate', distancePx: 320, sizePx: 360 },\n  { name: 'Toast dismiss',   role: 'exit',   property: 'translate', distancePx: 320, sizePx: 360 },\n  { name: 'Card reorder',    role: 'move',   property: 'translate', distancePx: 140, sizePx: 280 },\n  { name: 'Progress fill',   role: 'move',   property: 'width',     distancePx: 800, sizePx: 800 },\n]\n\nfunction curveFor(role) {\n  if (role === 'enter') return 'ease-out'\n  if (role === 'exit') return 'ease-in'\n  if (role === 'move') return 'ease-in-out'\n  return 'spring' \u002F\u002F lively\n}\n\n\u002F\u002F Duration scales with travel distance and element size. Floor + slope, clamped.\nfunction durationMs(role, distancePx, sizePx) {\n  const reach = Math.max(distancePx, sizePx * 0.4)\n  let ms = 140 + reach * 0.45\n  ms = Math.min(Math.max(ms, 140), 600)\n  if (role === 'exit') ms *= 0.75 \u002F\u002F exits are faster\n  return Math.round(ms)\n}\n\n\u002F\u002F spring for physical transforms; interpolate for timed values.\nfunction driver(role, property) {\n  const physical = property === 'scale' || property === 'translate'\n  if (role === 'lively') return 'spring()  \u002F\u002F want the overshoot'\n  if (physical && role !== 'move') return 'spring()  \u002F\u002F physical, lively settle'\n  return 'interpolate()  \u002F\u002F precise, timed-to-frame'\n}\n\nconst pad = (s, n) => String(s).padEnd(n)\nconsole.log(pad('ELEMENT', 18), pad('CURVE', 12), pad('MS', 6), pad('FRAMES', 8), 'DRIVER')\nfor (const r of requests) {\n  const curve = curveFor(r.role)\n  const ms = durationMs(r.role, r.distancePx, r.sizePx)\n  const frames = Math.round((ms \u002F 1000) * fps)\n  console.log(pad(r.name, 18), pad(curve, 12), pad(ms, 6), pad(frames, 8), driver(r.role, r.property))\n}\n```\n\n### Worked example output\n\nWith the requests above the script prints:\n\n```\nELEMENT            CURVE       MS     FRAMES   DRIVER\nModal pop-in       spring      252    8        spring()  \u002F\u002F want the overshoot\nModal backdrop     ease-out    600    18       interpolate()  \u002F\u002F precise, timed-to-frame\nToast slide-in     ease-out    284    9        spring()  \u002F\u002F physical, lively settle\nToast dismiss      ease-in     213    6        interpolate()  \u002F\u002F precise, timed-to-frame\nCard reorder       ease-in-out 203    6        interpolate()  \u002F\u002F precise, timed-to-frame\nProgress fill      ease-in-out 500    15       interpolate()  \u002F\u002F precise, timed-to-frame\n```\n\nRead it: the modal *pops* with a spring (overshoot = alive) while its backdrop\njust *fades* with timed interpolate — two different drivers on the same component,\nexactly as the Quality bar demands. The toast enters in 284ms and dismisses\nfaster at 213ms (the 0.75x exit rule), and its slide is physical so it springs in\nbut interpolates out. The progress bar is a precise width value — never a spring,\nor the fill would jiggle past 100%. The frame column is what you hand to\nproduct-demo-director for a product-video version of any of these.\n\n## Template: motion-spec\n\nCopy this, fill the FILL fields, and hand it to product-demo-director (video) or\nuse it as your transition values (UI).\n\n```\nMOTION SPEC. [FILL: element \u002F scene name].  Context: [UI | product-video]\n\nDIAGNOSIS\n  Feels:        [FILL: linear \u002F floaty \u002F janky \u002F dead \u002F new build]\n  Because:      [FILL: one line]\n\nCURVE & TIMING\n  Role:         [FILL: enter \u002F exit \u002F move A->B \u002F lively]\n  Curve:        [FILL: ease-out \u002F ease-in \u002F ease-in-out \u002F spring]\n  Duration:     [FILL]ms   ( = [FILL] frames @ [FILL]fps )\n  Exit faster:  [FILL]ms   (~0.75x of entrance, if it exits)\n\nARC\n  Anticipation: [FILL: wind-up, or \"none\" for a micro-interaction]\n  Action:       [FILL: the main move]\n  Follow-thru:  [FILL: overshoot + which secondary element lags]\n\nPER-PROPERTY DRIVER (spring vs interpolate)\n  [FILL property] -> spring()       (physical: scale \u002F translate, want overshoot)\n  [FILL property] -> interpolate()  (timed: opacity \u002F color \u002F progress)\n\nDISNEY PRINCIPLES IN PLAY\n  [FILL: e.g. slow-in\u002Fout, anticipation, follow-through, staging]\n\nHANDOFF\n  -> product-demo-director with the frame counts above, OR\n  -> CSS\u002FJS transition with the ms + cubic-bezier \u002F spring config above.\n```\n\n## references\u002Ftwelve-principles\n\nDisney's 12 principles, mapped to UI and product-video motion. Reach for the few\nthat fix the diagnosed problem; you never apply all twelve at once.\n\n1. **Squash & stretch** — deform on impact\u002Fpress to imply mass. UI: a few percent\n   scale on a button press; a notification squashing slightly as it lands. Too\n   much looks like a toy.\n2. **Anticipation** — a small opposite-direction wind-up before the action. Primes\n   the eye, makes the move read as intentional. The fix for \"dead\" motion.\n3. **Staging** — direct attention to one thing at a time. Do not animate six\n   elements on one curve; lead with the hero element, let the rest follow.\n4. **Straight-ahead vs pose-to-pose** — in code you work pose-to-pose: define key\n   states (closed -> open) and let easing\u002Finterpolation fill the between frames.\n5. **Follow-through & overlapping action** — elements settle past their target and\n   attached parts lag behind the leader. The single biggest \"alive\" lever after\n   easing. This is the spring overshoot plus offset secondary motion.\n6. **Slow in & slow out** — easing itself. Things accelerate and decelerate; they\n   do not start and stop at full speed. The biggest quality lever overall.\n7. **Arc** — natural motion follows curved paths, not straight lines. A dropped\n   element or a flung card reads better arcing than moving dead-straight.\n8. **Secondary action** — a supporting motion that reinforces the main one (a\n   shadow deepening as a card lifts). Supports, never competes.\n9. **Timing** — number of frames \u002F duration. Controls weight and mood: fewer\n   frames = snappy and light, more = heavy and deliberate. Scale with distance.\n10. **Exaggeration** — push the key pose past literal realism for clarity and\n    energy. Restrained in UI, freer in a punchy product video.\n11. **Solid drawing** — in motion design, consistent perspective, depth, and light\n    so animated elements feel volumetric, not flat. Pairs with\n    motion-color-and-light.\n12. **Appeal** — the whole thing should feel charismatic and clear, not muddy or\n    busy. The sum of the other eleven applied with restraint.\n\nThe four that fix 90% of UI\u002Fproduct complaints: **slow-in\u002Fout** (easing),\n**timing** (duration\u002Fspacing), **anticipation**, and **follow-through**. Start\nthere, then add staging and secondary action for richness.\n\n## references\u002Fspring-vs-interpolate\n\nThe decision you hand to product-demo-director, stated plainly:\n\n- **Reach for `spring()`** when the motion should feel *physical and alive* and a\n  slight overshoot\u002Fsettle improves it: pops, scale-ins, slide-ins, toggles, like\n  buttons, a logo entrance, a card lifting. Tune `damping` for personality — lower\n  is bouncier\u002Fplayful, higher is tighter\u002Fcorporate. Springs are great on\n  transforms (scale, translate) and bad on bounded values.\n- **Reach for `interpolate()`** when you need *precise, timed-to-the-frame*\n  control and overshoot would be wrong: opacity fades (0->1), color shifts,\n  progress\u002Fwidth bars, cross-fades, exits, and anything that must land exactly on\n  its end value. Always clamp so it never runs past its range.\n- **Common pattern:** drive the *transform* with a spring and the *opacity* with\n  interpolate on the same element — it pops in physically while fading cleanly.\n  That split is the single most useful motion idiom and it is exactly what the\n  picker script encodes.\n\nWhen unsure: is overshoot a feature here? Yes -> spring. No -> interpolate.\n","# Motion Design Principles\n\nThis is the taste layer. It decides *how* something should move so it reads as\npolished and intentional instead of janky, floaty, or cheap. It does not write\nthe code that plays the motion — once you have decided the curve, the timing, and\nthe arc, that decision is the *input* to a directing\u002Frender skill (for product\nvideo, hand it to **product-demo-director**) or to your CSS\u002FJS transition (for\nUI). Keep the two jobs separate: this skill owns the judgment; the directing\nskill owns the orchestration and mechanics.\n\nFire on anything about how motion *feels*: \"make this less janky\", \"smoother\",\n\"more polished\", \"more alive\", \"the easing is off\", \"this looks cheap\", \"should I\nease-in or ease-out\", \"spring or interpolate\".\n\n## When to use a sibling instead\n\nThis skill is the curve\u002Ftiming\u002Farc judgment only. Defer when the real question is:\n\n- **Which shots, scene order, or a beat list** → **video-storyboard**.\n- **Directing a full product demo** — cursor moves, screen captures, feature\n  callouts, the end-to-end scene assembly → **product-demo-director**. (This skill\n  produces the motion spec it consumes.)\n- **Animating text or letterforms** — type that flies\u002Fbuilds\u002Freveals →\n  **kinetic-typography**.\n- **Timing motion to a beat, score, or sound effect** → **sound-and-music-sync**.\n- **Cropping or reframing for a platform** (9:16, 1:1, safe areas) →\n  **social-video-formatter**.\n- **Light, exposure, glow, or color motion** → **motion-color-and-light**.\n\n## Operating procedure\n\nDiagnose before you prescribe. Most \"janky\" motion is one of four named\nproblems, and each maps to a specific fix below. Work the steps in order — the\neasing fix is worthless if the timing is wrong, and the timing fix is worthless\nif the element has no arc.\n\n### Step 1: Name what feels wrong\n\nWatch the motion (or the description of it) and classify it. Almost every\ncomplaint is one of these:\n\n- **Linear \u002F robotic** — moves at constant speed, stops dead. No easing. Fix in\n  Step 2.\n- **Floaty \u002F mushy** — too slow, or eases in *and* out when it should snap in.\n  Wrong duration or wrong curve. Fix in Step 2 and Step 3.\n- **Janky \u002F stuttery** — enters and exits at the same speed, or every property\n  animates on the same flat timeline with no offset. Missing spacing and arc.\n  Fix in Step 3 and Step 4.\n- **Dead \u002F lifeless** — technically correct but boring: no anticipation, no\n  overshoot, no follow-through. Missing the arc and secondary motion. Fix in\n  Step 4 and Step 5.\n\nWrite the diagnosis down in one line before touching anything. \"The modal is\nfloaty because it fades over 600ms with ease-in-out\" is a fix; \"make it nicer\"\nis not.\n\n### Step 2: Pick the easing curve\n\nEasing is the speed-over-time shape of the motion. The curve carries almost all\nthe perceived quality. Match the curve to what the element is doing:\n\n- **ease-out** (fast start, slow settle) — the default for **things entering** and\n  for anything the user triggered. It feels responsive because motion begins\n  immediately, then decelerates into place. Use for: elements appearing,\n  dropdowns opening, a tapped button responding, content sliding in. If unsure,\n  reach for ease-out.\n- **ease-in** (slow start, fast exit) — for **things leaving**. The element\n  accelerates away off-screen. Used alone on an *entrance* it feels sluggish and\n  laggy, which is the #1 cause of \"floaty\". Use for: dismissals, close, exits.\n- **ease-in-out** (slow, fast, slow) — for **moving something already on screen\n  from A to B**: a card reordering, a carousel advancing, a toggle sliding. Both\n  ends are anchored, so easing both ends reads as controlled. Do not use it for\n  entrances — the slow start kills responsiveness.\n- **spring** (physics: mass, stiffness, damping — overshoots and settles) — for\n  motion that should feel **alive and physical**: a modal popping in, a toggle\n  knob, a like button, a notification dropping in. The slight overshoot is what\n  reads as \"alive\". Tune damping for personality: lower damping = bouncier and\n  more playful, higher damping = tighter and more corporate.\n\nThe `spring() vs interpolate()` decision (when you reach for each in code) is in\nthe **Quality bar** and the runnable artifact below. The short version: spring\nfor physical\u002Flively transforms, interpolate for precise timed-to-the-frame values\nlike opacity fades, color, and progress bars.\n\n### Step 3: Set timing and spacing\n\n**Timing** is total duration. **Spacing** is how the distance is distributed\nacross that duration — spacing *is* easing made literal (an ease-out is bunched\nframes at the end). Two rules:\n\n- **Duration scales with distance and size, not taste.** A small element moving a\n  short distance should be fast (UI: ~150–250ms). A large element or a long\n  travel needs longer (~300–500ms) or it teleports. Big full-screen \u002F hero\n  motion in video can run longer. Same motion, longer distance → longer duration.\n- **Enter and exit are not symmetric.** Exits should be faster than entrances\n  (~0.7–0.8x) — the user is done with the element, so get it out of the way.\n  Equal enter\u002Fexit durations are a classic source of \"janky\".\n\nFor product video, convert to frames the moment you leave this skill:\n`frames = round(seconds * fps)`. Those frame counts are the literal input you\nhand to **product-demo-director** (which turns them into the timed scene plan).\n\n### Step 4: Build the anticipation → action → follow-through arc\n\nReal motion is rarely a single move. The richest, most \"alive\" motion has three\nbeats:\n\n1. **Anticipation** — a tiny opposite-direction wind-up before the main move (a\n   button dips *in* slightly before popping, a card pulls back before sliding\n   out). It primes the eye and makes the action read as intentional. Keep it\n   small and fast; too much looks like a glitch.\n2. **Action** — the main move, carrying the easing from Step 2 and the duration\n   from Step 3. This is where the spacing lives.\n3. **Follow-through** — the element settles past its target and back (the spring\n   overshoot), and any attached\u002Fsecondary elements lag slightly behind the\n   leader (a label catching up to the card it sits on). This is what sells\n   weight and life.\n\nNot every micro-interaction needs all three — a 150ms tooltip is just action. But\nwhen something feels \"dead\", it is almost always missing anticipation or\nfollow-through. Add the arc before adding flourish.\n\n### Step 5: Apply the relevant Disney principles\n\nDisney's 12 principles of animation map directly onto UI and product motion. You\ndo not apply all twelve; you reach for the few that fix the diagnosed problem.\nThe full mapping is in `references\u002Ftwelve-principles`. The high-leverage ones:\n\n- **Slow in & slow out** → easing (Step 2). The single biggest quality lever.\n- **Anticipation** → the wind-up (Step 4).\n- **Follow-through & overlapping action** → overshoot + lagging secondary\n  elements (Step 4). The difference between \"correct\" and \"alive\".\n- **Timing** → duration and spacing (Step 3).\n- **Squash & stretch** → subtle scale on press\u002Fimpact to imply mass; in UI keep\n  it to a few percent or it looks like a toy.\n- **Staging** → move one thing at a time so the eye knows where to look; never\n  animate six things at once on the same curve.\n- **Secondary action** → a small supporting motion (a shadow deepening as a card\n  lifts) that reinforces the main one without competing.\n- **Exaggeration** → push the key pose slightly past realistic; restrained in UI,\n  freer in a punchy product video.\n\n### Step 6: Hand off the spec\n\nFill the motion-spec template below — curve, duration (and frames), the arc\nbeats, and the spring-vs-interpolate call per property. That filled spec is the\nhandoff artifact: for a product-video scene it goes straight into\n**product-demo-director**; for UI it becomes your transition\u002Fkeyframe values.\nPair it with **motion-color-and-light** if the scene also needs light\u002Fexposure\nmotion, **kinetic-typography** if text is animating, and **sound-and-music-sync**\nif the timing must land on a beat.\n\n## Quality bar\n\nMotion is A+ only when all of these hold:\n\n- The diagnosis is named (linear \u002F floaty \u002F janky \u002F dead), and every change traces\n  to it. No \"made it nicer\" without a reason.\n- **Entrances ease-out, exits ease-in, on-screen A→B ease-in-out, lively\u002Fphysical\n  uses spring.** No raw linear motion ships except deliberate constant-speed\n  loops (a spinner, a marquee).\n- Duration scales with distance\u002Fsize, and the exit is faster than the entrance.\n- The `spring()` vs `interpolate()` call is explicit per property: **spring for\n  physical transforms** (scale, translate, the pop\u002Fslide\u002Fsettle — you want the\n  overshoot); **interpolate for precise timed values** (opacity fades, color,\n  progress, anything where overshoot would look wrong). A fade driven by a spring,\n  or a logo pop driven by linear interpolate, is a defect.\n- At least one of anticipation or follow-through is present on hero \u002F signature\n  motion; lifeless motion is missing exactly these.\n- One thing leads at a time (staging); properties are offset rather than all\n  firing on one flat timeline.\n- Curve, duration, and frame counts are written down and ready to hand to\n  product-demo-director or a transition — this skill never leaves the decision\n  implicit.\n\n## Do NOT\n\n- Do NOT ship linear easing for entrances or exits — it is the robotic default and\n  reads as unfinished. Constant speed is only for intentional loops.\n- Do NOT ease-in an entrance or ease-out an exit — that is the floaty\u002Flaggy feel\n  reversed. Entrances ease-out, exits ease-in.\n- Do NOT use equal enter and exit durations; exits should be ~0.7–0.8x faster.\n- Do NOT drive a fade, color, or progress bar with a spring — the overshoot makes\n  values run past their range and flash. Use interpolate for timed values.\n- Do NOT drive a lively pop\u002Fslide\u002Fscale with linear interpolate when you want it\n  to feel alive — use a spring for the overshoot.\n- Do NOT animate many properties on one flat timeline; stage and offset them.\n- Do NOT over-anticipate or over-overshoot in UI — a few pixels \u002F a few percent.\n  Big wind-ups and bounces read as a glitch or a toy.\n- Do NOT plan shot order or assemble the demo here — hand the spec to\n  product-demo-director; storyboard order is video-storyboard.\n\n## Easing & spring picker\n\nSelf-contained Node script. Save as `motion_pick.js` and run with\n`node motion_pick.js`. Edit the `requests` array for the elements you are\nanimating; it returns the curve, a distance-scaled duration (ms and frames), the\nexit duration, and the spring-vs-interpolate call. No dependencies.\n\n```javascript\n\u002F\u002F Motion picker. Edit `requests`, then: node motion_pick.js\nconst fps = 30 \u002F\u002F for product video; UI ignores the frame column\n\n\u002F\u002F role: 'enter' | 'exit' | 'move' | 'lively'\n\u002F\u002F distancePx: how far it travels (drives duration). sizePx: rough element size.\nconst requests = [\n  { name: 'Modal pop-in',    role: 'lively', property: 'scale',   distancePx: 0,   sizePx: 600 },\n  { name: 'Modal backdrop',  role: 'enter',  property: 'opacity', distancePx: 0,   sizePx: 1920 },\n  { name: 'Toast slide-in',  role: 'enter',  property: 'translate', distancePx: 320, sizePx: 360 },\n  { name: 'Toast dismiss',   role: 'exit',   property: 'translate', distancePx: 320, sizePx: 360 },\n  { name: 'Card reorder',    role: 'move',   property: 'translate', distancePx: 140, sizePx: 280 },\n  { name: 'Progress fill',   role: 'move',   property: 'width',     distancePx: 800, sizePx: 800 },\n]\n\nfunction curveFor(role) {\n  if (role === 'enter') return 'ease-out'\n  if (role === 'exit') return 'ease-in'\n  if (role === 'move') return 'ease-in-out'\n  return 'spring' \u002F\u002F lively\n}\n\n\u002F\u002F Duration scales with travel distance and element size. Floor + slope, clamped.\nfunction durationMs(role, distancePx, sizePx) {\n  const reach = Math.max(distancePx, sizePx * 0.4)\n  let ms = 140 + reach * 0.45\n  ms = Math.min(Math.max(ms, 140), 600)\n  if (role === 'exit') ms *= 0.75 \u002F\u002F exits are faster\n  return Math.round(ms)\n}\n\n\u002F\u002F spring for physical transforms; interpolate for timed values.\nfunction driver(role, property) {\n  const physical = property === 'scale' || property === 'translate'\n  if (role === 'lively') return 'spring()  \u002F\u002F want the overshoot'\n  if (physical && role !== 'move') return 'spring()  \u002F\u002F physical, lively settle'\n  return 'interpolate()  \u002F\u002F precise, timed-to-frame'\n}\n\nconst pad = (s, n) => String(s).padEnd(n)\nconsole.log(pad('ELEMENT', 18), pad('CURVE', 12), pad('MS', 6), pad('FRAMES', 8), 'DRIVER')\nfor (const r of requests) {\n  const curve = curveFor(r.role)\n  const ms = durationMs(r.role, r.distancePx, r.sizePx)\n  const frames = Math.round((ms \u002F 1000) * fps)\n  console.log(pad(r.name, 18), pad(curve, 12), pad(ms, 6), pad(frames, 8), driver(r.role, r.property))\n}\n```\n\n### Worked example output\n\nWith the requests above the script prints:\n\n```\nELEMENT            CURVE       MS     FRAMES   DRIVER\nModal pop-in       spring      252    8        spring()  \u002F\u002F want the overshoot\nModal backdrop     ease-out    600    18       interpolate()  \u002F\u002F precise, timed-to-frame\nToast slide-in     ease-out    284    9        spring()  \u002F\u002F physical, lively settle\nToast dismiss      ease-in     213    6        interpolate()  \u002F\u002F precise, timed-to-frame\nCard reorder       ease-in-out 203    6        interpolate()  \u002F\u002F precise, timed-to-frame\nProgress fill      ease-in-out 500    15       interpolate()  \u002F\u002F precise, timed-to-frame\n```\n\nRead it: the modal *pops* with a spring (overshoot = alive) while its backdrop\njust *fades* with timed interpolate — two different drivers on the same component,\nexactly as the Quality bar demands. The toast enters in 284ms and dismisses\nfaster at 213ms (the 0.75x exit rule), and its slide is physical so it springs in\nbut interpolates out. The progress bar is a precise width value — never a spring,\nor the fill would jiggle past 100%. The frame column is what you hand to\nproduct-demo-director for a product-video version of any of these.\n\n## Template: motion-spec\n\nCopy this, fill the FILL fields, and hand it to product-demo-director (video) or\nuse it as your transition values (UI).\n\n```\nMOTION SPEC. [FILL: element \u002F scene name].  Context: [UI | product-video]\n\nDIAGNOSIS\n  Feels:        [FILL: linear \u002F floaty \u002F janky \u002F dead \u002F new build]\n  Because:      [FILL: one line]\n\nCURVE & TIMING\n  Role:         [FILL: enter \u002F exit \u002F move A->B \u002F lively]\n  Curve:        [FILL: ease-out \u002F ease-in \u002F ease-in-out \u002F spring]\n  Duration:     [FILL]ms   ( = [FILL] frames @ [FILL]fps )\n  Exit faster:  [FILL]ms   (~0.75x of entrance, if it exits)\n\nARC\n  Anticipation: [FILL: wind-up, or \"none\" for a micro-interaction]\n  Action:       [FILL: the main move]\n  Follow-thru:  [FILL: overshoot + which secondary element lags]\n\nPER-PROPERTY DRIVER (spring vs interpolate)\n  [FILL property] -> spring()       (physical: scale \u002F translate, want overshoot)\n  [FILL property] -> interpolate()  (timed: opacity \u002F color \u002F progress)\n\nDISNEY PRINCIPLES IN PLAY\n  [FILL: e.g. slow-in\u002Fout, anticipation, follow-through, staging]\n\nHANDOFF\n  -> product-demo-director with the frame counts above, OR\n  -> CSS\u002FJS transition with the ms + cubic-bezier \u002F spring config above.\n```\n\n## references\u002Ftwelve-principles\n\nDisney's 12 principles, mapped to UI and product-video motion. Reach for the few\nthat fix the diagnosed problem; you never apply all twelve at once.\n\n1. **Squash & stretch** — deform on impact\u002Fpress to imply mass. UI: a few percent\n   scale on a button press; a notification squashing slightly as it lands. Too\n   much looks like a toy.\n2. **Anticipation** — a small opposite-direction wind-up before the action. Primes\n   the eye, makes the move read as intentional. The fix for \"dead\" motion.\n3. **Staging** — direct attention to one thing at a time. Do not animate six\n   elements on one curve; lead with the hero element, let the rest follow.\n4. **Straight-ahead vs pose-to-pose** — in code you work pose-to-pose: define key\n   states (closed -> open) and let easing\u002Finterpolation fill the between frames.\n5. **Follow-through & overlapping action** — elements settle past their target and\n   attached parts lag behind the leader. The single biggest \"alive\" lever after\n   easing. This is the spring overshoot plus offset secondary motion.\n6. **Slow in & slow out** — easing itself. Things accelerate and decelerate; they\n   do not start and stop at full speed. The biggest quality lever overall.\n7. **Arc** — natural motion follows curved paths, not straight lines. A dropped\n   element or a flung card reads better arcing than moving dead-straight.\n8. **Secondary action** — a supporting motion that reinforces the main one (a\n   shadow deepening as a card lifts). Supports, never competes.\n9. **Timing** — number of frames \u002F duration. Controls weight and mood: fewer\n   frames = snappy and light, more = heavy and deliberate. Scale with distance.\n10. **Exaggeration** — push the key pose past literal realism for clarity and\n    energy. Restrained in UI, freer in a punchy product video.\n11. **Solid drawing** — in motion design, consistent perspective, depth, and light\n    so animated elements feel volumetric, not flat. Pairs with\n    motion-color-and-light.\n12. **Appeal** — the whole thing should feel charismatic and clear, not muddy or\n    busy. The sum of the other eleven applied with restraint.\n\nThe four that fix 90% of UI\u002Fproduct complaints: **slow-in\u002Fout** (easing),\n**timing** (duration\u002Fspacing), **anticipation**, and **follow-through**. Start\nthere, then add staging and secondary action for richness.\n\n## references\u002Fspring-vs-interpolate\n\nThe decision you hand to product-demo-director, stated plainly:\n\n- **Reach for `spring()`** when the motion should feel *physical and alive* and a\n  slight overshoot\u002Fsettle improves it: pops, scale-ins, slide-ins, toggles, like\n  buttons, a logo entrance, a card lifting. Tune `damping` for personality — lower\n  is bouncier\u002Fplayful, higher is tighter\u002Fcorporate. Springs are great on\n  transforms (scale, translate) and bad on bounded values.\n- **Reach for `interpolate()`** when you need *precise, timed-to-the-frame*\n  control and overshoot would be wrong: opacity fades (0->1), color shifts,\n  progress\u002Fwidth bars, cross-fades, exits, and anything that must land exactly on\n  its end value. Always clamp so it never runs past its range.\n- **Common pattern:** drive the *transform* with a spring and the *opacity* with\n  interpolate on the same element — it pops in physically while fading cleanly.\n  That split is the single most useful motion idiom and it is exactly what the\n  picker script encodes.\n\nWhen unsure: is overshoot a feature here? Yes -> spring. No -> interpolate.\n",{"name":5,"metadata":24,"description":7},{"title":25},"Motion Design Principles","main","97a13607d669157a4a16d5ba79b77f208319f7b9","skills\u002Fmotion-design-principles",3,"https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills","https:\u002F\u002Fskillme.dev","https:\u002F\u002Fgithub.com\u002FSkillMedev","MCP-native catalog of Claude Agent Skills. Browse, recommend, install, and auto-apply skills in chat. Open source, every skill free and clonable on GitHub.","2026-10-14 03:19:31",{"source":8,"skillName":5,"commands":36,"prompt":46,"zipAvailable":47},[37,40,43],{"tool":38,"command":39},"npx","npx skills add SkillMedev\u002Fskills --skill motion-design-principles",{"tool":41,"command":42},"bunx","bunx skills add SkillMedev\u002Fskills --skill motion-design-principles",{"tool":44,"command":45},"pnpm","pnpm dlx skills add SkillMedev\u002Fskills --skill motion-design-principles","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fmotion-design-principles\u002FSKILL.md",true,[],[50,60,67,74,81,88],{"skillNo":51,"name":52,"nameZh":53,"description":54,"descriptionZh":55,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":56,"categories":57,"keywords":58,"publishedAt":59},"01M75271B256DF3FX2VG5VRYEE","zone-2-cardio-plan","有氧运动计划","Use when someone asks to build a steady-state cardio plan, train an aerobic base or Zone 2, structure easy or endurance weekly cardio, train by heart-rate zones, or improve resting heart rate, VO2, or endurance. Builds a heart-rate-zone aerobic training block with session structure, modality choice, and progression. General fitness guidance, not medical advice. Do NOT use to design a strength or lifting program (use Strength Training Plan), high-intensity interval conditioning, HIIT, or circuits (use Conditioning & HIIT Program), or a mobility\u002Fflexibility routine (use Mobility Routine).","当有人要求制定稳态有氧训练计划、进行有氧基础训练或达到第二区间、安排轻松或耐力型的每周有氧训练、按心率区间训练，或提高静息心率、最大摄氧量或耐力时，可以使用此方案。该方案构建了一个包含训练计划结构、训练方式选择和进度安排的心率区间有氧训练模块。本方案仅提供一般健身指导，不构成医疗建议。请勿用于设计力量或举重训练计划（请使用力量训练计划）、高强度间歇训练 (HIIT) 或循环训练（请使用体能训练和 HIIT 计划），或灵活性\u002F柔韧性训练（请使用灵活性训练计划）。","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fzone-2-cardio-plan\u002FSKILL.md",[],[],"2026-11-11 18:27:18",{"skillNo":61,"name":62,"nameZh":6,"description":63,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":64,"categories":65,"keywords":66,"publishedAt":59},"01M7526VP1QBBKYBE17S1WR86Y","youtube-script-writer","Writes retention-engineered long-form YouTube scripts on a hook\u002Fbody\u002Fpayoff architecture - a first-30-seconds hook that survives the retention cliff, a beat-sheet body with mini-hooks and bridges, timed pattern interrupts, and a payoff that over-delivers - with B-roll and editing cues marked inline. Use when someone says \"script my next video\", \"my retention graph dies at the start\", \"tighten this draft\", or \"outline a video on X\". Do NOT use for the 3-second opener of TikTok, Reels, or Shorts - use video-hook-writer instead; do NOT use for spoken voiceover synced to on-screen tutorial actions - use narration-script instead; do NOT use for a sales demo built on a buyer's discovery notes - use demo-script instead; do NOT use to design the thumbnail and title - use thumbnail-concept instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fyoutube-script-writer\u002FSKILL.md",[],[],{"skillNo":68,"name":69,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":59},"01M7526P2T0WKMHDXS4Q58237T","win-back-campaign","Designs segmented win-back email sequences for dormant users - dormancy tiers, a three-beat sequence with a single proportional incentive, and a suppression rule - and measures success by re-activation, not opens. Use when someone says \"our users went quiet\", \"design a win-back campaign\", \"how do I re-engage lapsed customers\", \"should we email people who haven't logged in for months\", or lifecycle messaging has stopped landing with a lapsed segment. Do NOT use for recovering an unfinished checkout - use abandoned-cart-sequence instead. Do NOT use for diagnosing and fixing why active customers cancel - use churn-reduction instead. Do NOT use for building always-on onboarding or nurture flows - use email-drip-builder instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwin-back-campaign\u002FSKILL.md",[],[],{"skillNo":75,"name":76,"nameZh":6,"description":77,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":78,"categories":79,"keywords":80,"publishedAt":59},"01M7526HF2RCDJ50P93WRZRHVV","wikipedia-style","Writes neutral, verifiable, encyclopedic prose following Wikipedia's core content policies and manual of style - NPOV, inline citations, notability-backed claims, and a strict ban on promotional language. Use when someone asks \"write this like a Wikipedia article\", \"draft a Wikipedia page for this company or person\", \"make this neutral and encyclopedic\", or \"why does my article draft keep getting rejected\". Do NOT use for persuasive or opinion writing - use op-ed-writer instead; for thesis-driven academic papers, use academic-essay; for verifying claims in existing text, use fact-checker.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwikipedia-style\u002FSKILL.md",[],[],{"skillNo":82,"name":83,"nameZh":6,"description":84,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":85,"categories":86,"keywords":87,"publishedAt":59},"01M7526D43CTGRKGKNQ2GB0KVX","whitepapers","Structures and writes authoritative B2B whitepapers - a standalone executive summary, a data-sized problem statement, methodology, evidence-driven findings, recommendations, and a soft call to action - flagging every claim that needs a real citation. Use when a marketer asks \"write a whitepaper on this topic\", \"turn our research into a lead-gen asset\", \"make this credible enough for executives\", or a draft reads like a product pitch instead of analysis. Do NOT use for customer-story-driven proof - use case-study-builder instead; for policy audiences, use policy-brief.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhitepapers\u002FSKILL.md",[],[],{"skillNo":89,"name":90,"nameZh":6,"description":91,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":92,"categories":93,"keywords":94,"publishedAt":59},"01M75268423Y3K50SY5WC2NX2G","white-space-analysis","Finds unmet market gaps by ranking jobs-to-be-done on importance versus satisfaction, overlaying them against current solutions and workarounds, and validating that each gap is real, winnable, and worth winning. Use when someone asks \"where are the gaps in this market\", \"what's underserved here\", \"where should we play next\", or is hunting for product, feature, or market-entry opportunities. Do NOT use for profiling competitors and building battle cards - use competitive-intelligence instead; for putting a dollar figure on an identified opportunity - use market-sizing instead; for extracting jobs-to-be-done from raw customer interviews - use jtbd-extractor instead.","https:\u002F\u002Fgithub.com\u002FSkillMedev\u002Fskills\u002Fblob\u002Fmain\u002Fskills\u002Fwhite-space-analysis\u002FSKILL.md",[],[]]