Motion Brief

Use this skill for an explicitly requested motion brief or interview. Establish the purpose and material behavior of one animation, then record a usable brief. Routine animation implementation can use animate and existing defaults without opening an interview.

Animations get rebuilt three times not because the code was wrong but because nobody decided what the motion was for. This skill front-loads that decision. It does not write the animation. The brief is the deliverable for interview-only requests. If implementation is already explicitly authorized, use the agreed decisions and continue without asking for the same approval again.

Follow the canonical motion policy. Values below are starting points, not universal requirements.

The three rules

1. Ask only unresolved, material questions. Use one question at a time when later choices depend on the answer. Skip questions already answered by the request, code, or agreed defaults.
2. Look up facts; recommend decisions. Anything discoverable in the filesystem — the component, its trigger, the animation stack, the existing easing tokens — you find yourself. Asking the user something you could have read wastes the interview's credibility and their patience.
3. Never ask for a number the user can't feel. "What duration?" and "which cubic-bezier?" are unanswerable. Ask for the sensation or a reference product, then propose the number yourself and let them react to it. People can't author 240ms; they can tell you 240ms feels slow.

Every question ships with your recommended answer, so the user can agree in one word and the interview stays cheap.

Step 1 — Recon

Before the first question, read the code. Establish: