スキルを探す

Translate motion, interaction, and visual experience into implementable constraints while preserving accessibility and performance. Apply when working on animations, transitions, scroll effects, or micro-UX.

日本語の概要は準備中です。原文の説明を表示しています。

Design UI as information architecture + interaction + visual tone, then translate into implementable specs. Apply when discussing screen design, component design, design systems, or visual hierarchy.

日本語の概要は準備中です。原文の説明を表示しています。

Apply semantic HTML/JSX and WAI-ARIA correctly and minimally. Apply when implementing any UI, especially forms, interactive components, or when accessibility is mentioned.

日本語の概要は準備中です。原文の説明を表示しています。

Translate designs and UI requirements into robust, extensible implementations. Apply when converting designs to code, implementing components, fixing broken UI, or handling responsive layouts.

日本語の概要は準備中です。原文の説明を表示しています。

Evaluate UI/flows from cognitive load, error prevention, and accessibility perspectives. Apply when reviewing UX, discussing user confusion, high drop-off, or form usability issues.

日本語の概要は準備中です。原文の説明を表示しています。

セマンティックHTML/JSXとWAI-ARIAを「最小で正しく」適用し、キーボード操作・スクリーンリーダ・コントラスト等を満たす実装を作るための判断軸。ネイティブ要素優先、ARIAの過剰使用を避ける。

Agent Browser（Headlessブラウザ自動化CLI）を使ったUI検証・E2Eテスト・スクリーンショット取得の判断軸。アクセシビリティツリーベースの要素選択を優先し、壊れにくいテスト設計を目指す。

ディズニーの12原則とジブリ的自然運動をベースに、UIアニメーションの「なぜ動かすか」「どう動かすか」を判断する。アニメーション/モーション/トランジション設計の相談で、ツール非依存の概念的判断軸として使う。

アーキテクチャ設計（境界/依存/データフロー/非機能/運用）を、制約とトレードオフで言語化し、ADR-liteで合意形成しながら段階的に形にする。doc/input/rdd.md にアーキテクチャ/非機能/運用の要求がある、または設計判断（分割/責務/インタフェース/データ整合/観測性/スケール）相談で使う。

事業仮説を支える一次/二次情報を整理し、意思決定に足る「根拠」「不確実性」「次の調査」を可視化する。でたらめな引用や推測の断言を避け、出典の実在を重視する。

体験品質（動き/触感/視線誘導）を「実装可能な制約」に落とし、アクセシビリティとパフォーマンスを犠牲にせずに表現を実現する。UIの表現・アニメーション・インタラクション設計/実装の相談で使う。

設計と実装を「最小で正確」に進め、差分思考で品質と速度を両立する。設計の溶け込み（責務不明/重複/暫定対応）を防ぎ、レビュー可能な変更へ落とし込むときに使う。

機能・画面の実装着手前に「状態×見た目×周辺」を列挙する体験網羅チェックリスト。宣言外の実装を防ぐ関所として task-run/auto-task 等から使う。

デザインツール（Figma等）やUI要件を「壊れない・拡張しやすい」実装へ翻訳するための判断軸。px写経を避け、比率・構造・制約・状態を先に設計してからUIを組み立てる。

UIキーボードショートカットを「公式基準（W3C APG / WCAG）＋プラットフォーム規約（Apple HIG / Fluent UI）＋デファクトスタンダード（GitHub・Gmail・Slack等）」に沿って設計し、衝突なく・発見しやすく・無効化可能な形で実装するための判断軸。

制度・規約・審査基準・手続き・料金・法令を調べるときに、公式一次情報を最優先し、体験談やブログを結論の根拠にしないための判断軸。ストア審査要件、アカウント登録・種別変更、サブスクの解約・返金、外部サービスの利用規約や料金プラン、税務・法務の手続き、「〜できますか」という可否の問いで使う。費用が発生する手順や不可逆な手続きを提案する前には必ず適用する。

プロダクトのペルソナ/ユーザー像を、仮説と根拠（観察・調査・制約）で組み立て、意思決定に使える形へ整形する。※会話口調のペルソナ（にゃんこ）とは別物。

【穴埋め雛形】このプロジェクト固有の「存在設計・体験設計」のSSOT。judgment-harness のプロジェクト層スキルとして、立ち上げ時に本ファイルを埋めて使う（雛形のままなら未確定＝推測で決めない）。デザイン/UI/モーション/コピーの方針判断、見た目や体験のトーン決め、画面・コンポーネント設計の前段で必ず参照する。

プロトタイプの媒体選択ガイド（判断軸）。この検証は Figma でやるべきか、コードで作るべきか、併用かを決める。proto-loop のステップ2、およびデザイン検討の入口で「Figmaとコードどっちでやる？」に迷ったら適用する。基準の核は「止まっている絵で判断できるなら Figma、動かさないと分からないならコード」。

UIを「情報設計（優先度/構造）＋インタラクション（状態遷移）＋ビジュアル（トーン）」として設計し、実装可能な仕様へ落とす。見た目だけでなく、ルール化（コンポーネント/トークン）に寄せる。

認知負荷・エラー防止・学習コスト・アクセシビリティの観点からUI/フローを評価し、改善案を“検証可能な仮説”として提示する。認知人間工学/ユーザビリティ/アクセシビリティを統合して扱う。

価値提案（誰に/何のために/なぜ勝てる）をレビューし、曖昧さ・矛盾・証拠不足を洗い出して、メッセージとMVPを磨くために使う。

脅威と攻撃面を洗い出し、最小権限と安全な失敗で守るための判断軸。認証/認可、入力検証、秘密情報管理、監査ログ等の設計・実装・レビューで使う。

テストピラミッド・テスト設計・品質戦略を整理する判断軸。テストの粒度・スコープ・優先順位に迷ったときに使う。TDDの具体的な実装手順は developer-specialist と併用する。