Use the Transitions.dev Agent Skill to Add Product UI Polish Without Guessing

Reader persona: a founder, product marketer, designer-operator, or frontend lead who wants an AI agent to improve product UI polish without inventing random animations.

Job to be done: safely try the transitions.dev Agent Skill, understand what it installs, and decide how to use it in a product workflow.

Most AI-generated UI motion is either missing or too much.

A dropdown snaps open. A modal fades awkwardly. A success state feels flat. A form error shakes like a cartoon.

The hard part is not asking an AI agent to “make it nicer.”

The hard part is giving the agent a small, reusable motion system so it picks the right transition for the right UI element.

That is why transitions.dev is a useful skill to test.

The X signal that triggered this guide was a post by Jakub Antalik showing a comparison demo and the install command:

npx skills add jakubantalik/transitions.dev

The skill validated in a throwaway folder exposed one skill:

transitions-dev

Its description:

Production-ready CSS transitions for web apps.

What this skill contains

After installation, the skill included these transition references:

01-card-resize.md
02-number-pop-in.md
03-notification-badge.md
04-text-states-swap.md
05-menu-dropdown.md
06-modal.md
07-panel-reveal.md
08-page-side-by-side.md
09-icon-swap.md
10-success-check.md
11-avatar-group-hover.md
12-error-state-shake.md
_root.css
SKILL.md

That is the important thing: it is not one vague prompt.

It is a catalog of concrete CSS transition patterns, with decision rules that help an agent choose between them.

Examples:

• badge appearing on a trigger → notification badge;
• anchored surface opening from a trigger → menu dropdown;
• centered surface → modal;
• list/detail or step-to-step transition → page side-by-side;
• number update → number pop-in;
• success moment → success check;
• invalid field feedback → error state shake.

For operators, this is the difference between “make the app feel better” and “apply the right transition to this exact UI moment.”

First-run install

Use a throwaway project first:

mkdir transitions-eval
cd transitions-eval

Check the Skills CLI:

npx -y skills --help

Expected output includes:

Manage Skills:
  add <package>        Add a skill package
  remove [skills]      Remove installed skills
  list, ls             List installed skills
  find [query]         Search for skills interactively

List the available skill before installing:

npx -y skills add jakubantalik/transitions.dev --list

Expected result:

Available Skills
  transitions-dev

Then install non-interactively into a local OpenClaw-style skill directory:

npx -y skills add jakubantalik/transitions.dev \
  --skill transitions-dev \
  --agent openclaw \
  --copy \
  -y

In validation, the installer copied the skill into:

./skills/transitions-dev

It also created:

skills-lock.json

The installer displayed a security summary and ended with a useful reminder:

Review skills before use; they run with full agent permissions.

Do not ignore that sentence.

How to use it with an agent

The skill defines three namespaced verbs:

transitions reveal
transitions review
transitions apply

Use transitions reveal when you want the agent to list the catalog without touching your code.

Use transitions review when you want the agent to scan a project and identify places where the skill might help. This should be read-only.

Use transitions apply when you want the agent to install the selected transition into code. This is a file-writing action, so it should go through normal review.

A good first prompt:

Use transitions reveal. List the available transitions and explain which three would be most useful for our onboarding flow. Do not edit files.

A good second prompt:

Use transitions review on our app directory. Identify UI moments that could benefit from transitions-dev. Return file paths and recommended transition names. Do not edit files.

Only after that should you ask:

Use transitions apply on this dropdown component. Show the proposed transition and changed files before editing.

Permission and risk notes

This is not a publishing or messaging skill.

It does not need API keys.

It does not need customer data.

The real risk is code change quality:

• adding motion that harms accessibility;
• duplicating CSS root variables;
• applying a transition to the wrong component;
• breaking existing layout or state timing;
• ignoring prefers-reduced-motion.

The skill itself explicitly includes a reduced-motion guard in its design. Still, your review should check that the final code keeps it.

For production apps, use this rule:

Read-only review may run automatically.
File edits require preview and approval.
Production deployment requires normal CI and human review.

A practical operator workflow

Here is a simple workflow for a product team:

1. ask an agent to run transitions review on a feature branch;
2. pick one high-value UI moment, not ten;
3. apply one transition;
4. run the app locally;
5. check reduced-motion behavior;
6. record before/after screenshots or a short Loom;
7. merge only if the UI feels clearer, not just more animated.

Motion should clarify state.

It should not decorate confusion.

Where ClawMama fits

ClawMama is useful when the workflow should become repeatable for a team.

You can put this skill into a managed OpenClaw or Hermes agent, expose the agent as a Telegram bot, and let non-technical teammates ask for a UI motion review without installing Node tooling locally.

New ClawMama users get $2 in credits and can use the latest ChatGPT model without managing a VPS, Docker, runtime upgrades, or model keys.

A practical setup:

Agent role: Product UI polish reviewer
Installed skill: transitions-dev
Allowed default mode: read-only review
Approval required: file edits and pull request creation
Output: file path, UI moment, recommended transition, risk note

That keeps the workflow useful without letting an agent quietly rewrite product UI.

Bottom line

transitions.dev is a strong example of what good agent skills can be:

• specific;
• bounded;
• easy to install;
• grounded in reusable references;
• useful for a real product workflow.

Start with read-only review. Apply one transition. Measure whether the UI is clearer.