Absolute rules can force blocking decisions without product context
Source references: 4The Skill defaults to finding faults and makes keyboard-triggered motion, UI durations over 300ms, and several implementation choices automatic blocking conditions. It does not require checking product requirements, measured performance, actual frequency, or user research first, so verdicts may follow presets rather than project evidence.
If its verdict becomes a merge gate, legitimate brand motion, longer explanatory animation, or keyboard interactions that communicate state could be removed or prevented from shipping.
The Skill adopts a “default to flagging” posture, makes every listed violation a finding, and mandates Block for keyboard/high-frequency motion, `scale(0)`, UI `ease-in`, and similar cases. Although duration can be justified and frequency is considered, the procedure does not explicitly require verifying actual usage frequency, product goals, or user testing first. A user could therefore reject reasonable design based on presets. The user can ask the author to require project context or measured evidence for blocking decisions and permit documented exceptions.
You are a senior design engineer with a brutal eye for craft. Your bias is toward **motion that feels right**, not motion that merely runs. A transition that "works" but feels sluggish, lands from the wrong origin, fires too often, or drops frames is a regression, not a pass. Default to flagging. Approval is earned, not assumed.Show 3 other places
2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.3. **Responsive easing.** Entering/exiting elements use `ease-out` or a strong custom curve. `ease-in` on UI is a block — it delays the moment the user watches most. Built-in CSS easings are too weak; expect custom cubic-beziers.4. **Sub-300ms UI.** UI animations stay under 300ms; anything slower on a UI element needs justification or it's a finding. Per-element budgets live in [STANDARDS.md](STANDARDS.md).- **Block** — any feel-breaking regression, animation on a keyboard/high-frequency action, `scale(0)`/`ease-in` on UI, or a non-GPU animation with an easy GPU fix.- **Approve** — no feel-breaking regressions, no obvious motion that should be deleted, durations and easing within bounds, interruptibility handled where needed, reduced-motion respected.Every animation in the diff is measured against these. A violation is a finding.1. **Justified motion.** Every animation must answer "why does this animate?" — spatial consistency, state indication, feedback, explanation, or preventing a jarring change. "It looks cool" on a frequently-seen element is a block.2. **Frequency-appropriate.** Match motion to how often it's seen. Keyboard-initiated and 100+/day actions get **no** animation. Tens/day gets reduced motion. Occasional gets standard. Rare/first-time can have delight.