animate

## animate skill の概要

### animate ができること
**animate** skill は、AI エージェントがインターフェースの機能を見直し、明確さ・フィードバック・仕上がりの質を高めるための、意味のあるアニメーション、マイクロインタラクション、モーション効果を加えるのに役立ちます。単なる「派手にして」というプロンプトではありません。重要なのは、**どこで動きが使いやすさに効くのか**、どこは控えめに留めるべきか、そしてノイズが多い・コストの高いアニメーションをどう避けるかを判断することです。

### animate が特に向いている人
この animate skill は、プロダクト UI、ランディングページ、フォーム、ナビゲーション、カード、モーダル、各種インタラクティブ状態などで、「体験が唐突」「平坦」「分かりにくい」と感じているチームに向いています。とくに、モーションシステムをゼロから設計するほどではないが、トランジションやフィードバックの質は上げたい、という UI デザイン作業で力を発揮します。

### 実際に解決したい課題
animate を検討する多くのユーザーは、たいてい次のいずれかを解決したいはずです。

- 機能自体は動くが、静的すぎる、または動きが硬い
- 状態変化が追いづらい
- クリック、読み込み、完了に対するフィードバックが足りない
- 使いやすさを損なわずに、少し楽しさや心地よさを加えたい
- デザイン意図から実装への引き継ぎが曖昧

この skill が最も強いのは、すでに対象となるコンポーネント、フロー、画面などが具体的に決まっているケースです。

### animate が汎用プロンプトと違う点
animate の大きな違いは、モーションを**装飾ではなく設計判断**として扱う点です。元のガイダンスでは、エージェントに対して次のような姿勢を求めています。

- 効果を足す前に、まずアニメーションの機会を評価する
- プロダクトの個性、想定ユーザー、パフォーマンス制約を考慮する
- まず理解しやすさとフィードバックの改善を優先する
- 何にでも動きを付けるのではなく、必要な場所に絞って使う
- 変更案を出す前に、関連するデザイン系 skill で文脈を整える

### 導入前に知っておきたい注意点
最大の注意点は、animate が上流のデザイン文脈に依存していることです。説明にもある通り、まず `/frontend-design` を実行する前提になっており、まだデザイン文脈がない場合は、その前に `/teach-impeccable` を走らせる必要があります。実装スニペットだけを返す、単体のアニメーションレシピが欲しい場合、この skill はその用途にはやや狭めです。

## animate skill の使い方

### skills 環境に animate をインストールする
環境がリモート skill のインストールに対応しているなら、次を使います。

`npx skills add https://github.com/pbakaus/impeccable --skill animate`

導入後は、本番ワークフローで頼る前に、インストールされた skill の内容を必ず確認してください。

### まず読むべきファイル
最初に確認するのは次です。

- `SKILL.md`

このリポジトリのスナップショットでは、この skill に関して実質的に見るべきファイルはこれだけです。つまり、補助アセットやスクリプトを探すよりも、**ワークフロー上の制約を理解すること**に価値があります。

### 必須の前提条件を理解する
animate を使う前提として、skill は次の流れを求めています。

1. `/frontend-design` を呼び出す
2. そのコンテキスト収集プロトコルに従う
3. まだデザイン文脈がない場合は `/teach-impeccable` を実行する
4. パフォーマンス制約を集める
5. そのうえで、はじめてアニメーション機会を評価する

この前提の流れは重要です。ここを飛ばすと、単体で見ると良く見えても、プロダクトのトーン、アクセシビリティ要件、技術的な制約と噛み合わないモーションを足してしまう恐れがあります。

### animate に必要な入力
animate skill が最も機能するのは、次の情報を渡したときです。

- レビュー対象の機能またはコンポーネントを正確に示すこと
- 現状の挙動と課題
- 意図するプロダクトのトーン
- デバイス条件とパフォーマンス制約
- アクセシビリティ上の懸念、とくにモーションへの敏感さ
- 実装提案も欲しい場合はフロントエンドのスタック

弱い入力:
“Add animation to this page.”

強い入力:
“Review our checkout drawer for purposeful motion. The drawer currently appears instantly, quantity updates feel abrupt, and success feedback is easy to miss. Keep motion calm and fast, mobile-safe, and avoid heavy continuous effects.”

### ざっくりした要望を、強い animate プロンプトに変える
animate をうまく使う基本パターンは次の通りです。

1. 対象を明示する
2. どこが静的・分かりづらい・唐突なのかを説明する
3. ブランドやプロダクトの性格を定義する
4. 制約を明記する
5. 単なる演出案ではなく、優先順位付きの改善機会を求める

例:

`Use animate for our pricing toggle and plan cards. We want transitions that clarify monthly vs annual selection, make hover and selection states feel responsive, and avoid gimmicky motion. Audience is B2B, tone is confident and calm, and performance must stay strong on mid-range mobile devices. Recommend the highest-value motion changes first.`

「かっこいいアニメーションを付けて」と頼むより、こちらのほうがはるかに有効です。animate にとって、判断の基準が明確になるからです。

### UI Design 向け animate がハマるユースケース
UI Design のために animate を使うなら、次のような場面に向いています。

- ボタン、トグル、入力欄、カード向けのマイクロインタラクション
- drawer、modal、accordion、tab の状態変化をより滑らかにする
- loading、success、error、completion に対するフィードバックを改善する
- 階層や空間的な関係を、モーションで伝えたい
- コア UX がすでに固まったあとで、小さな心地よさを加えたい

一方で、シネマティックなブランドアニメーション、高度な SVG 演出、全面的なモーションシステム文書化には、そのままだとあまり向きません。そうした用途では、かなり多くの追加指示が必要です。

### 実務でのおすすめワークフロー
実務で animate を使うなら、次の流れが現実的です。

1. アプリ全体ではなく、まず 1 つの機能を選ぶ
2. 必須の前提 skill を使ってデザイン文脈を集める
3. 現状の課題と制約を説明する
4. animate に、最も効果の高いモーション機会を洗い出させる
5. 提案をアクセシビリティとパフォーマンスの観点で確認する
6. 承認した案を、自分たちのスタック向けの実装タスクに落とし込む
7. 低スペック端末と reduced-motion 設定でテストする

この skill は、単体で最終コードを作るものというより、**レビューと計画のレイヤー**として使うと価値が出ます。

### animate に何を出力させるべきか
より実行に移しやすい出力が欲しいなら、animate に次のような成果物を求めると効果的です。

- 優先順位付きのアニメーション機会リスト
- 各モーション判断の理由
- タイミングや強さの提案
- アニメーションを付けないほうがよい箇所の指針
- 特定フレームワーク向けの実装メモ
- reduced motion や注意散漫リスクに絞ったアクセシビリティ確認

こうした依頼のほうが、「何かトランジションを付けて」よりもずっと良い結果につながります。

### 出力品質に大きく効くもの
特に効果が大きい入力は次の通りです。

- 現在のスクリーンショット、または十分に明確な UI 説明
- イベント／状態の地図: hover, press, loading, success, error, dismiss
- プロダクトの印象を playful, premium, calm, efficient のどれに寄せたいか
- パフォーマンス予算と対象デバイス
- no parallax、no looping motion、no layout thrash のような明示的な禁止事項

animate は戦略寄りの skill なので、文脈の質が上がるほど、提案の的確さも大きく上がります。

### animate でよくある使い方のミス
animate で最もよくあるミスは、ユーザー目標を示さずに「ページをアニメーションして」と依頼することです。これでは表面的な提案に寄りがちです。animate は、対象を機能単位に絞り、フィードバック・方向づけ・心地よさといった UX 上の成果に結び付けたときに、より良く働きます。

## animate skill FAQ

### UI をきれいにしたいだけでも animate は向いている？
場合によりますが、そこが animate のいちばん強い使い方ではありません。「きれいにしたい」が、実際にはトランジションを分かりやすくしたい、反応を伝わりやすくしたい、操作感を洗練させたい、という意味なら向いています。装飾的な動きだけが欲しいなら、汎用プロンプトで足りることもあります。

### animate は実装コードも生成してくれる？
この skill の中心は、分析と判断の支援です。スタック情報を渡せば実装寄りの出力も補助できますが、元の内容はコード中心のライブラリ導入ガイドではありません。

### animate は初心者でも使いやすい？
はい。どの機能に手を入れたいかが見えていれば、初心者でも扱いやすいです。ワークフローには明確な方針があり、文脈、UX 上の目的、制約に意識を向けられるのが利点です。いちばんの学習ポイントは、良いアニメーションは効果の選定からではなく、デザイン意図から始まると理解することです。

### どんなときは animate を使わないほうがいい？
次のような場合は animate を使わないほうがよいです。

- 単体のアニメーションパッケージや dependency が欲しい
- モーションと無関係な、完全に汎用の frontend アドバイスが欲しい
- まだ対象機能が決まっていない
- デザインやパフォーマンスの文脈を出せない
- 反復なしで高度かつ本番品質のモーション実装エンジニアリングが必要

### animate は普通のプロンプトとどう違う？
通常のプロンプトは、すぐにエフェクト案に飛びがちです。animate skill では、その前に構造化されたレビュー工程が入ります。つまり、どこが静的・ぎこちないのかを特定し、個性や想定ユーザーを理解し、パフォーマンスも踏まえたうえでモーションを提案します。結果として、数は少なくても質の高いアニメーションになりやすいです。

### animate はアクセシビリティに配慮が必要なプロダクトにも向いている？
はい。適切な入力があれば向いています。元のガイダンスでも、想定ユーザーやパフォーマンス文脈を求めており、そこにはモーションへの敏感さも含めるべきです。必要に応じて控えめな出力になるよう、reduced-motion の期待値は明示的に伝えるのが安全です。

## animate skill を改善するには

### animate の対象をもっと狭くする
animate の結果を最短で良くする方法は、対象範囲を絞ることです。アプリ全体ではなく、1 つのフロー、コンポーネント、状態遷移をレビューさせてください。“Improve motion in onboarding step 2” のほうが、“make our dashboard feel alive” より良い結果になりやすいです。

### 状態ごとのインタラクション詳細を渡す
animate は、どの瞬間にフィードバックが必要かを列挙すると精度が上がります。

- initial load
- hover
- press
- expand/collapse
- submit
- loading
- success/error
- exit

これにより、ユーザー意図に結びついたモーション提案がしやすくなり、単なる装飾案で終わりにくくなります。

### 制約を最初から含める
強い animate プロンプトには、次のような制約が入っています。

- “must feel professional, not playful”
- “no continuous looping motion”
- “optimize for mobile Safari”
- “respect reduced-motion users”
- “avoid expensive blur and layout-triggering effects”

制約があるほど、もっともらしいが不適切な提案を減らせるため、品質は上がります。

### ブレストではなく優先順位付けを求める
最初の出力が盛り込みすぎだと感じたら、animate に次の軸でアイデアを順位付けさせてください。

1. UX value
2. implementation effort
3. performance risk

こうすると、この skill は「やりたいことリスト」を増やす道具ではなく、判断を支える道具になります。

### animate で起こりやすい失敗パターンを把握する
よくある弱い出力には、次のようなものがあります。

- どこにでもアニメーションを足してしまう
- 明確さより楽しさを優先してしまう
- 理由のない曖昧な timing 提案
- プロダクトの個性に合わない効果
- パフォーマンス予算を無視した推奨

こうなった場合は、モーションを半分に減らし、残す変更それぞれの理由を説明するよう animate に求めてください。

### 2 回目の改善では、指示をもっと鋭くする
最初の結果を受けて改善するときは、全面的なやり直しを求めるより、次のように具体的な修正指示を返すほうが効果的です。

- “Make this calmer and faster.”
- “Focus only on feedback for form submission.”
- “Remove anything that feels game-like.”
- “Keep the hierarchy cues, drop decorative motion.”
- “Rewrite for reduced-motion compatibility.”

### animate の後に実装レビューを組み合わせる
良い進め方は、まず animate でモーション戦略を固め、その後に承認済みの案を coding あるいは frontend 実装の工程に渡すことです。こうすることで、そもそも選ぶべきでなかった効果を実装してしまうリスクを減らせます。

### animate は見た目の派手さではなく、UI Design のために使う
UI Design のために animate を最大限活かすなら、成功の基準は「画面がたくさん動くか」ではなく、ユーザーが操作・状態変化・要素同士の関係をより理解しやすくなったかに置くべきです。この視点で使うと、一貫して質の高いモーション判断につながります。