micro-motion
Skill12 starsChanged 11 days agoMITView on GitHub
Use when an interface needs purposeful feedback, transitions, or reduced-motion behavior, especially when animation risks jank, interruption bugs, or hidden no-JS content.
In this repository21 other files it gives its agents.
- AGENTS.mdAGENTS.md
- llms.txtllms.txt
- a11y-passSkill
- art-directionSkill
- cognitive-a11ySkill
- color-systemSkill
- component-statesSkill
- data-vizSkill
- design-system-interviewSkill
- deslop-uiSkill
- empty-statesSkill
- form-uxSkill
- humanize-copySkill
- i18n-readySkill
- improve-existing-websiteSkill
- responsive-layoutSkill
- spacing-systemSkill
- tastecheck-passSkill
- tasterollSkill
- themingSkill
- web-typographySkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 2 are distinctive, and 3 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 15
Prefer compositor-safe properties: Start with transform and opacity.
- Distinctive: line 19
Design reduced motion as an equivalent state: Keep labels, choices, focus, and content.
- Very specific: line 28
Use semantic duration/easing tokens: acknowledgement 120–160ms, insertion/menu 160–220ms, confirmation/route 220–320ms.
- Distinctive: line 79
Default to CSS; use a library only when gestures, springs, or layout coordination justify it.
- Very specific: line 100
Stop / handoff: Stop when no purpose or interruption policy exists.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Micro-Motion
Motion confirms a change, origin, or what to notice next. If it answers none, cut it.
Non-negotiables (the rules that keep motion feeling good)
- Prefer compositor-safe properties. Start with
transformandopacity. Color, filter, SVG, or measured layout transitions need purpose and target-device trace. - Ease by direction. Ease-out enters, ease-in exits, ease-in-out moves; linear is for a purposeful continuous loop only.
- Design reduced motion as an equivalent state. Keep labels, choices, focus, and content; remove spatial movement.
- Let JavaScript opt elements into waiting states only after the observer is ready. Static CSS must not hide content when JavaScript fails, initializes late, or restores from the back-forward cache.
- Make looping motion controllable and never scroll-jack.
Easing & duration tokens
Use semantic duration/easing tokens: acknowledgement 120–160ms, insertion/menu
160–220ms, confirmation/route 220–320ms. These are starting bands; test on target
device. Motion never delays committed state, focus, or next keyboard action.
Settle before styling
Define usable end state and interruption policy before an entrance. Superseded save, route,
insertion, or dismissal must converge on newest state without stale overlay, announcement,
focus jump, or success message. Motion reflects ownership, not decides it. Unknown
ownership/focus recovery goes to component-states.
The reduced-motion contract
Define the project-level reduced-motion policy once; components reference it. For progressive
reveals, content starts visible. After the observer is attached, JavaScript marks only offscreen
pending elements; never hide an already intersecting element. Remove the marker on reveal and
page restoration.
Gate spatial movement behind no-preference:
/* JavaScript marks only non-intersecting elements after the observer is ready. */
.reveal[data-reveal="pending"] { opacity: 0; }
.reveal:not([data-reveal="pending"]) { opacity: 1; }
@media (prefers-reduced-motion: no-preference) {
.reveal[data-reveal="pending"] { transform: translateY(12px); }
.reveal { transition: opacity var(--dur-base) var(--ease-out),
transform var(--dur-base) var(--ease-out); }
.reveal:not([data-reveal="pending"]) { transform: none; }
}For a legacy retrofit only, the emergency global kill switch in
references/principles.md is permitted after documenting why the primary pattern cannot
be used; it removes useful transitions and is not the default.
Decision order
- Name the user-facing purpose: acknowledgement, continuity, spatial origin, or attention.
- Name trigger, settled state, focus timing, and what wins when interrupted.
- Choose the smallest property, duration, and easing that communicate that purpose.
- Define reduced-motion and no-JS/restoration equivalents.
- Replay rapid repeat, cancellation, navigation, and stale async completion.
For async feedback, tag each request; only its current owner updates status/live announcement. For routes/overlays, cancel superseded animation and make destination DOM/focus authoritative. For list changes, preserve readable DOM order when movement is interrupted.
How to deliver
Deliver a choreography table: interaction, purpose, trigger, duration/easing, settled state, interruption rule, and reduced equivalent. Add one safety row for JS-disabled/restoration. Default to CSS; use a library only when gestures, springs, or layout coordination justify it.
Self-check
- Properties are compositor-safe, or intentional alternative has a target-device trace
- Durations/easings are tokens (
--dur-*/--ease-*); entrances ~200–300ms ease-out (custom curve, not linear) prefers-reduced-motionpath tested (motion off or cross-fade) — content never depends on it- Page reads complete with JS disabled, delayed initialization, and bfcache restore;
pending markers are added only to offscreen elements after observer ownership and cleared on
pageshow - Rapid repeat, cancellation, stale completion, and navigation converge on the current usable state without stale focus, status, or layers
- No scroll-jacking or uncontrolled loops; flashing stays below the safety threshold
- Evidence names tokens, settled state, reduced equivalent, and replay result
<!-- contract:v1:start -->Contract (generated)
Canonical detail: contract.json.
- Route: An interface needs purposeful transition, feedback, choreography, or reduced-motion behavior.; avoid: The request is only static visual styling or decorative animation without an interaction purpose.
- Exclude: Do not add motion without a user-facing purpose. (+2 in contract.json)
- Stop / handoff: Stop when no purpose or interruption policy exists. (+1 in contract.json); receives [component-states, design-system-interview, deslop-ui, tasteroll] -> sends [a11y-pass, tastecheck-pass]
- Output: purposeful motion choreography and token plan
- Evidence:
table_with_evidencewithstatus,reason,remediation,evidence,provenance.
<!-- contract:v1:end -->Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

