.md
Skill.mdサーチャーJP
Skill.md一覧に戻る
M
v1.0.0

UIアニメーションの必要性と動かし方を判断できる

by mae616

0
0

説明

できること

  • アニメーションの役割を判断する 情報を伝えるために本当に必要な動きなのか、単なる装飾なのかを判断して、効果的で無駄のないアニメーション設計ができます。
  • 自然で心地よい動きを実現する 物理法則(重力・慣性・摩擦)に基づくイージングやタイミングを理解し、ユーザーが違和感なく受け入れられる動きを実装できます。
  • アクセシビリティを確保しながら設計できる モーション酔いやストレスを感じるユーザーのための prefers-reduced-motion 対応を前提に、全員が快適に使えるアニメーション設計ができます。
  • ツールに依存しない判断軸を持つ CSS・JavaScript・Framer Motionなどツール選択に先立ち、「なぜこう動かすのか」をディズニーの12原則やMaterial Designで言語化でき、チーム全体で判断基準を共有できます。
  • ボタンやモーダル、メニューなど各パターンに最適な動きを設計できる タップフィードバック、画面遷移、メニュー展開など、UIパターン別の動きの工夫を具体的に実装できます。

こんな人におすすめ

  • UXデザイナー・プロダクトデザイナー アニメーションの「説得力ある理由」を持つことで、デザインレビューでの判断が速くなり、デベロッパーとの協業もスムーズになります。
  • フロントエンドエンジニア デザインの意図を理解した上でコードに落とし込め、ツール選択時の判断も自分で行えるようになります。
  • UIアニメーション・モーション設計に関わる全職種 基準がぶれないため、プロジェクト内での一貫性が保ちやすくなります。
SKILL.md の内容
# Animation Principles Skill

## 参照
- Disney's 12 Principles of Animation(Frank Thomas & Ollie Johnston, 1981)
- [Material Design - Motion](https://m3.material.io/styles/motion)
- [Apple Human Interface Guidelines - Motion](https://developer.apple.com/design/human-interface-guidelines/motion)
- [WCAG 2.1 Success Criterion 2.3.3: Animation from Interactions](https://www.w3.org/WAI/WCAG21/Understanding/animation-from-interactions.html)

## 発火条件
- アニメーション/モーション/トランジションの設計・レビューで「なぜこの動きなのか」の判断が必要な場合に適用する。

Skill.md 情報

バージョン
v1.0.0
カテゴリ
design-dev
作成日

インストール

ワンコマンドで導入
1

下の「Skill.mdをダウンロード」ボタンを押す

2

お使いのAIツール(Claude Code・Cursor・Copilot など)にファイルをアップロードして「このスキルを追加して」と入力する

ターミナルから追加する場合
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/mae616/ai-template" -o ~/.claude/skills/SKILL.md

タグ

関連 Skill.md

注目
K

SmartHR UI で規格に沿ったPRを素早く作成

by kufu

Conventional Commits形式に自動対応したPRタイトルを生成できるため、リリースノートに反映されやすいPRが作成できます PR本文テンプレートに沿った構造化された説明を自動生成することで、レビューに必要な情報を漏れなく記載できます 破壊的変更(!マーク)や関連URL、プロダクト側対応事項などを体系的に整理できるため、チーム全体の確認漏れを防げます gh CLIのHEREDOC形式に対応したコマンドを提供するため、手作業でのフォーマット確認が不要になります SmartHR UIリポジトリに定期的にコードを貢献する開発者 PR作成時にテンプレート形式を毎回確認するのが手間と感じている人 プロダクト側の対応が必要な変更を忘れずに記載したい人 Conventional Commitsのルールを正確に守りたい人 SmartHR UIリポジトリのPR作成ルールを定義します。PRタイトルはConventional Commits形式((): )で日本語記述し、破壊的変更は!で示します。PR本文は「関連URL」「概要」「変更内容」「プロダクト側で対応が必要な事項」「確認方法」の5セクションで構成し、該当なしの場合は「なし」と記載します。変更内容にはBefore/Afterコード例やキャプチャを添付し、破壊的変更の場合は具体的な対応方法を記載します。確認方法ではStorybookやChromatic URLを記載します。実行時はgh pr createコマンドのHEREDOC形式で本文を渡します。

テストドキュメントPR
95111.5k2026-04-13
T

Another Quick Switcherのリリース運用を自動化

by tadashi-aikawa

リリース前の検証(CI状態確認)から、Release workflowの実行、完了待機、新規releaseの検出まで一連のリリース運用を再現可能な手順で実行。 リリースノートから関連Issue・PRを自動抽出し、Issue返信文とSNS投稿案(Bluesky)を自動生成。手作業での返信文作成が不要。 --dry-runオプションで事前検証。本実行前に動作確認してからリリースを進められるので安全。 Codex LLMと同梱スクリプトの役割分離。確定的な検証・実行はスクリプト、非確定的な文章生成はLLMが担当する堅牢な設計。 obsidian-another-quick-switcherのメンテナー。毎回のリリース作業を効率化・標準化したい。 オープンソースプロジェクトの管理者。リリースフローの属人性を減らし、再現可能な手順を確立したい。 チーム開発で複数人がリリース対応する環境。誰でも同じ品質でリリース運用できる仕組みが欲しい。 GitHub Actionsと連携したリリース自動化を実装している人。リリースノート生成やIssue通知まで含めた完全自動化を目指す。 実行前提:bun、gh、gh auth statusが利用可能。Codex CLI実行時はghコマンドを最初からエスカレート実行(sandbox・host間の認証コンテキスト差異対応)。基本フロー:リポジトリルートでbun .agents/skills/another-quick-switcher-release/scripts/release.ts実行→スクリプト出力のJSON(RELEASE_RESULT_JSON)を読み取り→assets/templatesのテンプレート使用して標準出力(Bluesky投稿案・Issue返信テンプレート)。Script Options:--branch (対象ブランチ指定、既定master)、--dry-run(dispatch/git pull非実行)、--skip-issue-notify(Issue候補表示スキップ)。Output Contract:スクリプトはJSON出力でrelease・issueCandidatesフィールドを含む。Issue返信はPR除外(isPullRequest=false対象)、author重複除去、tagName・URL置換。Bluesky投稿は利用者視点の日本語要約・URL直記載で標準出力。失敗時は references/release-workflow.md のtroubleshooting参照。

コミット
3814.8k2026-03-29
N

AppleデザインガイドラインでUIを一括設計

by nahisaho

iOS・macOS・watchOSなどAppleプラットフォーム向けのUIを、Apple Human Interface Guidelines(HIG)に自動準拠させて設計できます マージン・スペーシング・グリッド・タイポグラフィ・カラーなど、プラットフォーム別の厳密な仕様に基づいて設計できます Dynamic Type対応やダークモード対応など、ユーザーアクセシビリティに配慮した設計が実装できます Navigation Bar・Tab Bar・Buttons・Lists・Cardsなど、標準コンポーネントの正確な仕様(寸法・色・配置)がすぐに参照できます SF Symbols を活用したアイコン設計を、統一的なガイドラインで実行できます iOS・iPadOS・macOS向けアプリのUIデザインを行うUI/UXデザイナー Appleプラットフォーム開発初心者で、デザインシステムの標準的な仕様を学びたい開発者 複数Appleプラットフォーム(iPhone・iPad・Mac・Watch・TV)で一貫性あるUIを構築したいプロダクトチーム ユーザーのアクセシビリティニーズに配慮したアプリ設計を実装したいプロダクトマネージャー Apple Human Interface Guidelines(HIG)に準拠した洗練なUIデザイン作成スキルです。核心原則は明瞭性(すべてのサイズで読みやすく、装飾は適切)、敬意(UIはコンテンツを補助)、奥行き(レイヤーと動きで階層表現)です。iOS/iPadOS:セーフエリア8pt基本グリッド、マージン最小16pt、Dynamic Type対応フォント(San Francisco)、14段階のテキストスタイル、セマンティックカラー+ダークモード対応が必須。Navigation Bar高さ44pt(コンパクト)/96pt(ラージ)、Tab Bar高さ49pt、ボタン最小タップ領域44x44pt、リスト行最小44pt、カード角丸12pt/16ptが標準。macOS:ウィンドウ最小800x600pt、ツールバー高さ52pt/76pt、サイドバー幅150-250pt、ボタン高さ22-32pt。watchOS:マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。

レビューテストドキュメント
274982026-01-01