説明
できること
- デザイン品質と使いやすさを同時にチェック:インタラクションデザイナーとユーザー代表の視点を並列に起動し、見た目の美しさだけでなく操作感や業務適合性を多角的に評価できます。
- アクセシビリティと業界標準への準拠を自動検証:Material Design 3などのモダンデザイン原則に基づいて、色使い・タイポグラフィ・余白・ダークモード対応などが適切に実装されているか確認します。
- 画面設計から実装まで幅広い成果物に対応:ワイヤーフレーム・画面遷移図・コンポーネント設計・フロントエンド実装など、開発段階に応じたレビューができます。
- 設計者のバイアスを早期に発見:ユーザーの視点とデザイナーの視点の両方から検証することで、想定外の使いづらさや業務フローとのズレを開発前に検知できます。
- レビューフィードバックを統合的に整理:複数の指摘を優先度順に整理し、修正方針を明確にした形でまとめて提供します。
こんな人におすすめ
- UI/UXデザイナー:完成した画面設計やコンポーネントが本当に使いやすいか、業界標準に沿っているか客観的な評価が欲しい人
- プロダクトマネージャー:ユーザーの実際のニーズと設計内容がマッチしているか、実装前にチェックしたい人
- 開発チーム:実装着手前に設計の問題を早期に発見し、手戻りを最小化したい人
- QAエンジニア:テスト仕様書を作成する前に、要件漏れやアクセシビリティ問題を設計段階で洗い出したい人
# UI/UX 成果物レビュー 開発フェーズの UI/UX 成果物(画面設計、画面遷移図、ワイヤーフレーム、コンポーネント設計、フロントエンド実装など)を XP エージェントで並列レビューし、デザイン品質とユーザー価値の両面からフィードバックを統合する。 ## レビューの価値 UI/UX のレビューは見た目の良し悪しを判断する活動ではない。システムメタファーとの整合性、ユーザーの心理モデルへの適合、業務フローとの自然さ、アクセシビリティを同時に検証することで、「ユーザーの問題を本当に解決する」インターフェースを実現する。デザイナーの視点とユーザーの視点を同時に当てることで、設計者のバイアスを早期に発見できる。 加えて、Material Design 3 をはじめとするモダンデザインシステムの原則に照らし合わせることで、業界標準のユーザー体験を担保する。ユーザーは日常的にモダンなアプリケーションに触れており、その操作感覚からの逸脱は学習コストと離脱率の上昇に直結する。
Skill.md 情報
- バージョン
- v1.0.0
- カテゴリ
- design-dev
- 作成日
インストール
ワンコマンドで導入下の「Skill.mdをダウンロード」ボタンを押す
お使いのAIツール(Claude Code・Cursor・Copilot など)にファイルをアップロードして「このスキルを追加して」と入力する
$ mkdir -p ~/.claude/skills/ && curl -sL "https://github.com/k2works/case-study-bouquet" -o ~/.claude/skills/SKILL.mdタグ
関連 Skill.md
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形式で本文を渡します。
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参照。
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:マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。