UI・デザイン実装

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形式で本文を渡します。

リリース前の検証（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参照。

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：マージンプラットフォーム別に設定。各プラットフォーム仕様が詳細に定義されています。

Material Design 3をベースに、タイポグラフィ（フォント）・カラー・立体感を戦略的に組み合わせた上質なUIを実現できます。 Google Fontsなどのモダンフォント（Poppins、Inter、Plus Jakarta Sansなど）を活用し、見出しと本文で異なるウェイトを使い分けることで、ビジュアル階層を明確にできます。 ダークテーマ・ライトテーマで統一感のあるカラーパレットを定義し、プライマリ・セカンダリ・ターシャリカラーを配置することで、ユーザーに印象的な体験を提供できます。 シャドウやグラスモーフィズム（ぼかし効果）を活用した奥行き表現で、フラットで単調な見た目から脱却できます。 UIを実装する際のチェックリストがあるため、デザイン品質を属人的にせず、チーム全体で統一した基準を保つことができます。 Flutter開発者で、デフォルトのデザインから抜け出し、プロフェッショナルな見た目にしたい人 アプリのUIを「ユーザーの目に留まる」印象的なものにしたい起業家やプロダクトマネージャー チーム開発でUIの美しさ・一貫性を保ちたいテックリード Material Designの基本は知っているが、洗練されたビジュアルの作り方を学びたいデザイナー FlutterアプリのUIを「ありきたりなデフォルト」から脱却させ、プロフェッショナルで印象的なデザインを実現するためのガイドラインです。タイポグラフィ面では、google_fontsパッケージでPoppins・Inter・Plus Jakarta Sansなどモダンフォントを使用し、FontWeightを極端に組み合わせ（w300とw800）、サイズ階層（headlineLarge:32sp/w800、bodyLarge:16sp/w400など）を設定します。カラー・テーマは、ダークテーマで深いダークグレー背景に鮮やかなインディゴ・シアン・ピンクを、ライトテーマでクリーン白背景にビビッドなインディゴ・スカイブルー・ピンクを配置し、Dominant Color（主色）を大胆に、Sharp Accents（アクセント色）を控えめに使用します。Elevation&Depthは、フラットすぎるデザインを避け、カードに微妙な立体感を持たせ、ソフトシャドウ（blur:10、opacity:0.04）やグラスモーフィズム効果（BackdropFilter）で奥行きを表現します。

設計JSON（トークン・コンポーネント・コンテキスト）から見た目のみのUI骨格を自動生成：ロジック・状態管理・API通信は一切含めず、Figma レイアウト（Auto Layout・constraints・resizing）を CSS flex・grid・breakpoints に忠実に変換。 複数技術スタック対応で標準配置を自動適用：React（src/components/）、Vue（src/components/*.vue）、SwiftUI（Sources/UI/）など、スタック別の公式ディレクトリ構造に自動配置、Storybook 対応も同時に生成。 トークン・コピー・アセットの SSOT 一元参照で二重管理を排除：design-tokens.json の color・typography・spacing、copy.json の文言、assets.json の画像を外部参照、値の埋め込みは禁止（magic number ゼロ）。 レスポンシブ規則（Figma→CSS マッピング）を自動適用：constraints/resizing ルール（SCALE→flex-grow、TOP_BOTTOM→h-full など）を breakpoints に従い自動変換、手作業ブレを完全排除。 デザインシステムオーナー・UI エンジニア：SSOT 確定後、実装前のUI骨格を素早く可視化したい フロントエンドアーキテクト：複数スタック対応の UI ファイル配置を標準化・保守しやすくしたい プロダクト開発チーム：Figma → コード間のスタイルズレを自動検出・修正したい デザイナー×エンジニアの協働チーム：「見た目は完成、あとはロジック」という分業を効率化したい コマンド：/design-ui [$TARGET] [$PAGE_KEY]（$TARGET：react/vue/svelte 等、$PAGE_KEY：design_context.json の pages[].key、省略時全ページ対象）。実行は /design-ssot または /design-mock の SSOT 成果物（design-tokens.json、components.json、design_context.json、copy.json、assets.json）を入力。出力：スタック別標準配置への静的 UI ファイル一式＋Storybook（対応スタックのみ）。禁止：状態・ロジック・データ取得・RDD逸脱スタック（指定時は ADR-lite 要）・copy.json の推測埋込。copyKey 不足は推測禁止、ユーザーに /design-ssot やり直し依頼。レスポンシブ規則：Auto Layout→flex + tokens gap/padding、constraints（SCALE→w-full、TOP_BOTTOM→h-full）、resizing（FILL→flex-1、HUG→max-content）、breakpoints は design-tokens.json 準拠、tokens 外の値・magic number 禁止。見た目基準ビューポート：rdd.md 「ターゲット表示環境」参照、未記入時は desktop 1440x900・mobile 390x844・tablet 834x1194 推奨デフォルト。

components.json で定義されたUIの見た目パターン（variants）を、React・Vue・Swiftなど各フレームワークの「型付きProps」に自動変換できます。 size（小/中/大）や色、状態などのバリエーションを、それぞれのフレームワークの正しい書き方に統一できます。 再利用可能なUIコンポーネントとして仕上げ、Storybook（UI見本帳）への自動登録・テストも同時に完了させます。 デザイン仕様を実装コードに自動反映するため、手作業でのコピペ・ミスを防ぎます。 デザイナーが作った UI部品を、エンジニアが実装する際の橋渡しが必要な方 React・Vue・Swift など複数フレームワークで同じUIを使い回したい組織 「デザイン → 実装」の工程を自動化・スピードアップしたいチーム このスキルは /design-assemble コマンドで実行します。doc/input/design/components.json の variants（size/tone/state等）を型付きProps/属性にマッピングし、選択されたテクノロジースタック別に再利用可能なUIコンポーネントを生成します。デフォルトは doc/input/rdd.md で指定されたスタック；引数で変更する場合は ADR-lite 承認が必須です。出力は React の場合 src/components/{Name}.tsx（Props型定義付き）、Vue は src/components/{Name}.vue、Svelte は src/lib/{Name}.svelte、SwiftUI は Sources/UI/{Name}.swift（enum/case）、Flutter は lib/widgets/{name}.dart、Web Components は src/components/{name}.ts となります。すべてのコンポーネントに JSDoc/Docstring/Swift Doc による Docコメントを付与し、a11y（アクセシビリティ）準拠（セマンティックHTML・WAI-ARIA）、Lint/Type/Test/Story の全緑、仕様追加禁止が必須です。マッピング規約は doc/input/design/ssot_schema.md を参照し、RDD/SOLID 原則に従う；逸脱は ADR-lite で理由と影響を明記する必要があります。

TSVファイルから読み込んだ情報を自動的に視覚的で分かりやすいDrawIO形式の図に変換できます。複雑な価値デザインモデルを図として一目で理解できるようにします。 匠Method（しょうこうmethod）の価値デザインモデルの視覚化に特化した図を生成でき、ビジネスロジックやサービス構造を正確に表現できます。 DrawIO形式のXMLを生成するため、diagrams.netで編集・共有できる形式になり、チームでの図の修正や更新が容易です。 UML図の記法やレイアウト最適化の知識に基づいて設計された図なので、見栄えが良く、情報が整理されています。 追加指示がある場合は、その指示を優先的に考慮して図を生成できるため、カスタマイズされた図要望にも対応できます。 ビジネスモデルやサービスの価値構造を図で説明・共有したいマネージャーや企画担当者 匠Methodを使用してシステムやサービスを設計しているチーム 複雑な関係性を図で可視化して、ステークホルダーに説明したい人 diagrams.netで後から図を修正・改善できる形式での成果物を求める人 このスキルは、匠Methodの価値デザインモデルの視覚化に特化したDrawIO生成エキスパートであり、TSVファイル（output/value-design.tsv）から情報を読み込み、DrawIO形式のXMLを生成します。専門分野はDrawIO（diagrams.net）のmxGraphModel XMLフォーマット、UML図の記法、情報デザインとレイアウト最適化です。実行手順は5ステップ：(1)Taskツールで ValueDesignDrawioGenerator エージェントを起動、(2)既存ファイル output/drawio/value-design.drawio があれば削除、(3)Writeツールで新しいDrawIOファイルを生成（共通ルールに従う）、(4)出力確認手順に従ってファイル作成を検証、(5)完了報告を実施。呼び出し元から追加指示（$ARGUMENTS）が渡された場合は、通常の処理に加えてその指示を優先的に考慮して実行します。

brainbase-uiのコード変更時に、バージョン番号を自動的に更新する手順を提供します。 MAJOR・MINOR・PATCH の3段階で、変更内容に応じたセマンティックバージョニングを適用できます。 package.json と index.html（デスクトップ・モバイル両対応）に統一されたバージョンを自動反映できます。 サーバーの再起動コマンドを自動実行し、バージョン変更を即座に反映できます。 コミットメッセージに自動的にバージョン情報を付与し、変更履歴を正確に追跡できます。 brainbase-ui の開発・保守を担当する開発者 UIのリリース管理を確実にしたいプロジェクトマネージャー バージョン管理の手順をチーム全体で統一したい開発リーダー ユーザー向けにUIバージョンを常に正確に表示したい製品チーム バージョン形式は「v0.0.0」（vプレフィックス必須、セマンティックバージョニング採用）。更新基準：破壊的変更は MAJOR、新機能追加は MINOR、バグ修正・小さな改善は PATCH。更新手順：①package.json の"version"フィールド更新、②index.html の2箇所（デスクトップ版: id="app-version"、モバイル版: id="mobile-app-version"）を手動更新、③サーバー再起動（ps aux | grep "node.*server.js" | grep -v grep | awk '{print $2}' | xargs killで停止後、nohup node server.js > /tmp/brainbase-ui.log 2>&1 &で起動）、④コミットメッセージに「feat(ui): 説明 (v0.1.1)」形式でバージョン含める、⑤デスクトップ左ナビ最上部・モバイルセッション一覧ヘッダーで表示確認、curl http://localhost:3000/api/versionで確認可能。実装場所：package.json（正本）、server.js（/api/versionエンドポイント）、index.html（バージョン表示要素）、app.js（loadVersion()関数）、style.css（.app-versionスタイル）。

開発中のウェブアプリケーションの画面をスクリーンショットで確認できます。 複雑なUIのアクセシビリティツリー（要素の構造・テキスト・ボタン配置）をテキストで取得し、分析できます。 ログイン・フォーム入力・ボタンクリック・セレクト操作など、ブラウザ上のインタラクション（操作）を自動実行できます。 APIの通信内容（ネットワークリクエスト・レスポンス）をキャプチャ・確認できます。 バグ調査や画面の現状把握を素早く行えます。 開発中のフロントエンド画面をAIに見てもらいながら改善指示したい開発者 複雑な画面のバグ原因を特定するため、AIと一緒に操作・確認したい人 E2Eテスト作成前に、実際の画面動作を確認・検証したい人 認証が必要なページにログインして、その先の画面をAIに確認させたい人 このスキルは開発中の画面を確認する「AIの目」として機能します。テスト実行ツールではなく、観察・調査・確認目的で使用します。 基本フロー 1. ページを開く：agent-browser open 2. 画面状態を把握：snapshot（テキスト・効率的）またはscreenshot（画像・視覚的） 3. 要素を操作：snapshot取得時の@ref参照を使用してクリック・入力・選択を実行 4. 遷移・待機：ページ遷移完了を待ち、新しい画面状態を再度snapshot snapshot（テキスト）の利点 アクセシビリティツリー形式で出力（@e1、@e2などの参照付き） トークン効率が良い（シンプルな画面向き） 要素参照をそのまま操作に使える screenshot（画像）の利点 複雑な画面・レイアウト全体を視覚的に把握 テーブル多数の場面で効率的 ログイン・認証対応 認証情報は.env.testやCLAUDE.mdの「テスト設定」セクションから読み取る ハードコード（スキルに直書き）は禁止 ネットワーク調査 agent-browser network har start/stopでAPI通信をキャプチャ agent-browser network requestsでリクエスト一覧を確認

古い記法を自動検出: プロジェクトのドキュメント内で Nuxt UI v3 の廃止された記法（UFormGroup、options= など）を一括スキャンし、問題箇所を特定します。 修正方法を自動提案: 検出された各問題に対して、v4 の推奨記法への修正方法を自動生成します。 一括自動修正: 検出された問題を確認後、ワンコマンドで全てのドキュメントを修正できます。 修正品質の確保: 説明文とコードブロックを区別し、意図的に書かれた v3 の例まで誤検出を避けます。 チェック対象の柔軟指定: 特定ディレクトリのみのチェック、または全体チェック（docs/、.claude/skills/ など）を選択できます。 Nuxt UI フレームワークを使用するフロントエンド開発者 プロジェクトのドキュメント品質を統一したい技術リード v3 から v4 への移行を進めているプロジェクトマネージャー 複数人で書かれたドキュメントのメンテナンスを担当する編集者 docs/working/ を中心にプロジェクト内の Markdown ドキュメントをスキャンし、Nuxt UI v3 の古い記法を検出・修正します。検出パターン：UFormGroup → UFormField、:options=/options=/v-bind:options= → :items=、UButtonGroup → UFieldGroup。実行手順は (1)スコープ確認、(2)ファイルスキャン（find で .md ファイル検索）、(3)パターン検出（grep` で各パターン検索）、(4)結果レポート（問題箇所を一覧表示）、(5)修正オプション提示（自動修正・手動修正・スキップ）。自動修正時は各ファイルに Edit ツール適用し置換実行。検出ロジックではコードブロック内のみを対象、説明文での意図的な v3 例は除外し、文脈確認で誤検出を回避します。

UI要素の自動調査: ウィンドウ内のボタン、テキストボックス、リストなど全ての UI要素をツリー状に可視化し、各要素の ID・名前・状態を確認できます。 要素のワンクリック操作: 特定のボタンやメニュー項目を指定してクリックし、結果をスクリーンショットで検証します。 テキストの自動入力: テキストボックスへの文字入力を自動化し、入力後の値を検証できます。 スクリーンショット撮影: Windows アプリケーションの画面を動的にキャプチャし、操作前後の変化を可視化します。 複数ウィンドウの管理: 複数のアプリが起動している環境で、対象ウィンドウを自動で特定・操作できます。 Windows デスクトップアプリの自動テストを実施したい QA エンジニア 業務アプリの繰り返し操作を自動化したい事務担当者 UI変更の影響範囲を調査・確認したい開発者 レガシーアプリの動作検証を効率化したい担当者 WPF UI自動化エージェントを使用して、UI操作を自動実行します。モード判定は引数から自動判定：inspect モード（UI調査・確認）、click モード（要素クリック）、type モード（テキスト入力）。各モードで list_windows・resolve_target・focus_window でウィンドウを特定後、list_controls（depth=4）でコントロールツリーを取得し、screenshot で画面をキャプチャ。click/type モードではセレクタ（automation_id > name+control_type > bounding_rect）で要素を指定し、click・type_text を実行。結果は screenshot と read_text で検証します。

macOS の LaunchAgent（ログイン時に自動実行するプログラム）から画面キャプチャを実行できるように設定できます。通常は「画面を記録する権限がない」エラーが出ますが、このスキルで解決します。 Python スクリプト（PIL.ImageGrab など）を LaunchAgent で常駐化し、定期的にスクリーンショットを撮らせることができます。 .app バンドル（Mac アプリケーション形式）と LaunchAgent plist の紐付けにより、macOS が「このプロセスはアプリ X の一部」と認識し、権限を適用する仕組みを構築します。 macOS で Python/シェルスクリプトを自動実行させたいが、画面キャプチャ権限で詰まっている開発者 ターミナルから手動実行では動くのに、LaunchAgent（自動実行）では動かない現象に困っている方 毎日定時に自動レポート生成（スクリーンショット付き）のような、画面キャプチャを伴う常駐化を実現したい方 macOS Sequoia 以降、LaunchAgent プロセスからの画面キャプチャは TCC（Transparency, Consent, and Control）により「権限なし」エラーで失敗します。解決には3つのピースが必要：(1) .app バンドル化（macOS がアプリケーションとして認識）、(2) LaunchAgent plist での AssociatedBundleIdentifiers で .app と紐付け（権限を継承）、(3) screencapture コマンド使用（PIL.ImageGrab の代替）。.app 最小構成は MyApp.app/Contents/Info.plist と MyApp.app/Contents/MacOS/run.sh。Info.plist には CFBundleIdentifier（例: com.example.myapp）、CFBundleExecutable、LSUIElement=true（Dock 非表示）、NSScreenCaptureUsageDescription を記述。run.sh は shebang で #!/bin/bash から始め、export HOME=/Users/ユーザー名、export PATH=/opt/homebrew/bin:... で環境変数を明示的に設定（launchd は ~/.zshrc を読まない）してから Python スクリプトを実行。LaunchAgent plist は ~/.config/LaunchAgents/ に配置し、Label、ProgramArguments、RunAtLoad=true、AssociatedBundleIdentifiers=["com.example.myapp"] を記述して、launchctl load で登録。これにより画面収録の許可ダイアログで .app を選択可能になり、権限が付与されます。

画面のUI要件を入力すると、Web Component Framework（WCF）で実装するのに必要な「最小コンポーネント構成」を自動で提案します。 必要なコンポーネントID・依存関係・パターンを、レジストリ（部品カタログ）から自動検索して、JSON形式で構造化して返します。 要件の「状態」（ローディング中・エラー・空・デフォルト）が不足していれば自動で補完し、何を補完したかを記録します。 曖昧な要件には「これについて確認したいこと」を明示し、実装前の齟齬を減らします。 WCFを使ったコンポーネント設計・実装を行うフロントエンド開発者 新しい画面を設計する際に「どのコンポーネントを組み合わせるか」を効率的に決めたい設計者 インストール前に最小構成を確認して、作業スコープを明確にしたい開発チームリーダー 入力：screen_goal、target_user、states（loading/error/empty/default最低）。出力契約は「人間向けMarkdown説明 + 機械可読JSON」。JSONに含まれる：componentIds（該当する部品）、dependencyIds（依存する部品）、patternIds（再利用パターン）、assumptions（補完した仮定）、openQuestions（曖昧な点）。情報源優先度は install-registry.json → pattern-registry.json → custom-elements.json/MCP。手順：(1)要件を「入力・操作・出力・状態」に分解 → (2)registry から候補抽出 → (3)不足分を MCP/CEM で補完 → (4)dependencies 展開 → (5)JSON 契約で返す。MCPが使えない場合は registry と custom-elements.json のみで候補返却。

Vue 3 SFC（Single File Component）を複数の観点から自動一括レビューし、改善点を指摘します。 Composition API の型安全性を検査。Props・Emits の型定義、ref/reactive/computed の使い方、watch の依存明示などを確認します。 TypeScript の型チェックで、any 型の使用、null/undefined 握り潰し、API型の正確性などを検出します。 Tailwind CSS 準拠をチェック。インラインスタイルの使用、レスポンシブ対応、色パレット統一、ダークモード対応を確認します。 Biome linting・formatting ルールへの準拠、アクセシビリティ（ARIA・alt属性・フォーム関連付け）まで、網羅的にレビューします。 Vue 3 プロジェクトで品質基準を統一したいチームリード SFC を書く際にベストプラクティスを自動でチェックしたい開発者 TypeScript の型安全性や Tailwind CSS の使用パターンを統一したい方 UI コンポーネントのアクセシビリティを確保したい方 起動方法: $ARGUMENTS でファイルパターンを指定、未指定の場合はユーザーに確認。以下 6 つのカテゴリを全チェック。 Vue 3 / Composition API: `` の使用、defineProps/defineEmits の型付け、ref/reactive/computed の使い分け、watch での依存明示、ライフサイクルフック位置を検査。アンチパターンとして any 型、プリミティブの reactive ラップ、テンプレート内 inline 関数、v-for の key 未設定・index 使用、v-if と v-for の併用を警告。 TypeScript 型安全性: Props を interface/type で型定義、ref のジェネリクス省略チェック、API レスポンス型を shared/api から引用、non-null assertion（!）で値を握り潰さない、readonly Props 保護、as const の enum 代替使用を確認。 Tailwind CSS: インラインスタイル不使用、独自 CSS はスコープ内、breakpoint prefix（sm:/md:/lg:）の使用、繰り返しクラス列の @apply・子コンポーネント切り出し、色パレット変数統一、dark: prefix の使用を検査。 Biome: 未使用 import・変数、console.log 残存、代入を含む条件式、== 使用（=== へ）の他、2スペースインデント・セミコロン設定準拠、import 自動整列を検査。 アクセシビリティ: インタラクティブ要素の aria-label・可視テキスト、画像の alt 属性、フォーム label・input 関連付け（for/id）を確認。 出力: 重大（修正必須）・警告（修正推奨）・情報（参考）・合格の 4 レベルで file:line 形式で報告。問題 0 件なら「全チェック合格」を表示。

アプリUIとプレビュー領域で異なるスタイリング手法を正確に使い分けられます。 Tailwind CSS v4のユーティリティクラスを使ってアプリUIの見た目を効率的に構築できます。 プレビュー領域ではinline styles（React.CSSProperties）でユーザーが操作するスタイル属性を柔軟に適用できます。 TailwindとCSSの混在による不具合を根本的に防ぎ、コードの一貫性を保ちやすくなります。 React + Tailwind CSS v4でUIコンポーネントを実装するフロントエンド開発者 タイポグラフィやスタイルプレビュー機能を作る開発者 Tailwindとinlineスタイルをどちらにするか判断に迷う方 コンポーネント設計時のスタイリングルールを明確にしたい方 スタイリング規約は、Tailwind CSS v4とinline stylesの厳密な使い分けを定めています。アプリUIの領域（ヘッダー、コントロールパネル、ボタン、レイアウト）ではTailwindユーティリティクラスを使用し、プレビュー領域ではinline styles（React.CSSProperties）でユーザー操作対象のスタイルのみ適用します。両者を混在させることは禁止です。Tailwindはレスポンシブブレークポイントやdarkモードプレフィックスに対応し、カスタム値は[]記法で指定します。プレビュー領域のコンテナ（レイアウト、パディング、背景色）はTailwind使用が許可されますが、ユーザーが操作するCSSプロパティのみstyle属性で設定します。@applyやプレビューへのTailwindクラス、アプリUIへのinline styles使用は禁止パターンです。

データが「事実なのか・推定値なのか・AI生成なのか」を視覚的に区別するデザインガイドを使って、ユーザーが情報の信頼度を一目で判断できます。 テーブル、フィルタ、比較ビューなど、ダッシュボード画面で必須の機能の実装ルールが明示されているので、バラバラな実装を防げます。 Instagram URL / ユーザーネーム入力のバリデーション仕様が含まれ、不正な形式の入力を事前ブロックできます。 ローディング・空状態・エラー・非公開アカウントなど、あらゆる状態表示のパターンが定義されているので、ユーザー体験の一貫性が保たれます。 レスポンシブ対応（デスクトップ主体、タブレット動作、モバイル制限表示）とInstagram API の遅延対策（スケルトンローダー）も含まれています。 Instagram 分析など、推定値と事実値が混在するダッシュボードを設計・実装するフロントエンドエンジニア データの信頼度を明確に表現する必要がある分析ツール・SaaS の UI 設計者 テーブル、フィルタ、比較ビュー機能を含む複雑なダッシュボードを標準化したいチーム Instagram API 連携時の遅延対策やエラーハンドリングをガイドに従いたい開発者 データ表示の原則では、fact（事実）は通常表示、estimated（推定）はグレー系+[推定]バッジ+信頼度アイコン、llm_generated は[AI分析]ラベル、unavailable は—表示+[取得不可]ツールチップで区別します。信頼度は high=グリーン dot、medium=イエロー dot、low=レッド dot+警告アイコンで表現します。状態管理は、ローディング時スケルトン、空状態は「候補がありません。URLを入力して追加してください」、エラーはメッセージ+再試行、非公開アカウントは「非公開のため分析できません」と表示します。テーブル設計はtemplates/table-filter-template.md参照で、ソート・フィルタ・ページネーション（20件/ページ）・列表示切り替えが必須機能です。比較ビューは最大10件横並び、超過時横スクロール、選択候補を固定ヘッダー表示、数値は棒グラフ、推定値と事実値で色分けします。フォーム入力はhttps://www.instagram.com/username/「https://instagram.com/username」「@username」「username」が有効で、TikTok URLや空文字は無効です。レスポンシブは1280px 以上デスクトップ、768〜1279px タブレット、モバイル制限表示対応。gotchas として、API応答2〜10秒でスケルトン必須、LLM テキストの innerHTML 直接挿入禁止（XSS対策）、比較ビュー10件固定は横スクロール必須を記載。

既存の高品質コンポーネントライブラリから最適なベースを選んで、ゼロから作るより遥かに効率よく実装できます。shadcn/ui、Aceternity UI、Magic UI などから用途に合ったコンポーネントを参照し、プロジェクトに合わせてカスタマイズします。 「AI感」を徹底的に排除したUIを実現できます。フォントサイズ比、色彩設計、タイポグラフィ（文字詰め・行間）のプロパターンを適用することで、人間のUIデザイナーが作ったような洗練された仕上がりになります。 ボタン1つから画面全体まで、あらゆるUI実装に対応します。コンポーネント、セクション、ページ、ダッシュボード、フォーム、ランディングページなど、UI実装の粒度を問わず使えます。 トーン・用途に応じた最適なデザインライブラリを自動選択します。ビジネス向け、クリエイティブ、テクニカル、マーケティング など、プロジェクトの文脈に合った参照ライブラリを提案します。 既存デザインシステムとの一貫性を保ちながら実装します。プロジェクトが使っているフレームワーク、技術スタック、デザイン原則を最優先で遵守します。 フロントエンド開発者で、デザイン品質を上げたいが自分でデザインするのは得意ではない人 「AI が作ったようなUIになってしまう」という課題に悩んでいるプロダクトマネージャーやデザイナー ランディングページ、ダッシュボード、管理画面など、多種多様なUI を短時間で実装したい人 既存コンポーネントライブラリを活用しながら、プロジェクト独自のカスタマイズを効率よく進めたい人 このスキルは、AIが生成するUIに見られる「ジェネリック感」を避けるため、既存の高品質コンポーネントライブラリを参照・選択・カスタマイズするアプローチを採用します。 フェーズ1では、実装前に要件を明確化します。作成するもの（コンポーネント/ページ等）、ターゲットユーザー、プロジェクトのトーン（ビジネス/カジュアル/クリエイティブ等）、技術スタック、既存デザインシステムを確認します。 フェーズ2では、参照ライブラリから最適なベースコンポーネントを探索します。用途別の参照ライブラリ選択ガイド（フォーム→shadcn/ui、ダッシュボード→shadcn/ui+Tremor、ランディング→Aceternity UI等）に従い、Context7 MCPのドキュメント取得ツールで対象ライブラリのドキュメントを取得します。完全一致するコンポーネントがあれば採用、なければ最も近いものをベースにカスタマイズします。 フェーズ3では、AIが生成するUIの共通のアンチパターンを意識的に回避します。タイポグラフィではフォント・見出し本文サイズ比・font-weight の多段階使い分け・letter-spacing調整を実施。カラーではオフホワイト背景・彩度調整・テキスト色調整・控えめなアクセントカラー使用を実施します。

型安全で保守性の高いコンポーネントを生成：type定義とNamedExportを基本とした標準的な書き方でコンポーネントを作成し、リファクタリング時の変更が最小限に抑えられます。 Next.js App Routerの規約に沿った実装：'use client'宣言の判定を自動化し、Server ComponentとClient Componentの使い分けを正確に行えます。 Tailwind CSSのみでスタイリングを統一：UI libraries（shadcn/ui、MUIなど）に依存せず、標準HTMLタグと Tailwind ユーティリティクラスで統一感のあるデザインを実現できます。 コンポーネント配置を正確に判定：汎用パーツと機能別パーツの配置ルール（common / domain）を遵守し、プロジェクト構造を統一できます。 Props分割代入とrealuct.FCの非使用：最新のReact慣例に従い、将来的なアップグレードへの耐性を確保できます。 新しいフロントエンドコンポーネントの実装を一貫性を保って進めたいチームメンバー 既存コードベースの規約をAIに守らせたいプロジェクト管理者 Next.js App Router＋Tailwind CSSのプロジェクトに参加し、初期段階で間違わないようにしたい開発者 UIライブラリに依存しない、カスタマイズ性の高いコンポーネント実装を希望する人 コンポーネント実装では、React.FCは使用せず通常の関数コンポーネントとして定義します。Propsの型定義はinterfaceではなくtypeを推奨し、コンポーネント直上に記述します。Propsは引数部分で分割代入して受け取ります。エクスポートはexport defaultではなくexport constのNamedExportを使用し、リファクタリングの容易性と一貫性を確保します。 Next.js App Routerでは、useState、useEffect、useCallback、useSWR、onClick、onChange、window・documentなどの機能を使用するファイルは必ずファイルの最上部に'use client'を記述します。これら機能を使用しないコンポーネントはServer Componentのままで'use client'は記述しません。 スタイリングはPure Tailwind CSSのみで、shadcn/ui、MUI、Chakra UIなどのコンポーネントライブラリは使用しません。標準的なHTMLタグに直接Tailwindユーティリティクラスを適用します。汎用パーツ（Button等）はsrc/components/commonに、機能パーツ（Form等）はsrc/components/domainに配置します。

複雑なスキルを「単一の責務を持つ小さなコンポーネント」に自動分解し、各コンポーネントの入出力を明確に定義できます。 分解したコンポーネントを自動的にセキュリティ検査（シェルインジェクション、認証情報漏洩、危険なファイル操作など）にかけ、安全性を確保してからDB登録できます。 コンポーネント間の依存関係（data-flow、sequential、requires等）を自動で識別・記録し、将来の再利用時に組み合わせやすくします。 スキルの資産化によって、同じ処理パターンを別のスキルでも再利用でき、開発効率が大幅に向上します。 複数のスキルを開発・運用しており、共通パターンの整理・資産化を進めたい人 セキュリティ品質を重視し、自動検査を通したコンポーネント登録を実現したい開発チーム skills_kv.dbコンポーネントレジストリを活用したスキル設計をしたい技術リーダー 既存スキルの保守性を向上させ、将来の拡張や修正を容易にしたい人 このスキルは5段階処理で実行されます。Phase 1は入力取得（SKILLファイルパス指定、直接ペースト、既存スキル名指定）。Phase 2はコンポーネント分解で、1責務・入出力明確・再利用可能な粒度を基準に、各コンポーネントにname（kebab-case）、description、category（testing-quality等9種類から選択）、tags（3-5個）、input_spec、output_spec、contentを決定。Phase 3はセキュリティ検査で、シェルインジェクション、認証情報漏洩、危険ファイル操作、無断外部通信、依存脆弱性の5カテゴリをチェック、結果はsafe/warning/blockedに判定。Phase 4ではDB登録とコンポーネント接続を実行。Phase 5は結果レポート（コンポーネント名、カテゴリ、セキュリティレベル、入出力等の一覧表）を出力します。

UI変更を含むプルリクエストに対して、Playwrightで自動的にスクリーンショットを撮影し、ffmpegでGIF動画を生成してPR本文に貼付できます。 開発環境をローカル起動してから、指定のページについてフルページ・画面幅1440px固定でビジュアルをキャプチャし、PR番号付きフォルダに整理保存できます。 記録スクリプト（scripts/record-pr-demo.js）をPRごとに更新することで、その機能に合わせたデモGIFを自由にカスタマイズできます。 GitHub Pages（gh-pages ブランチ）に自動デプロイし、PR reviewerが https://tagty.github.io/taskflow/pr-{PR_NUMBER}/demo.gif のようなURLから即座にビジュアル確認できます。 UIコンポーネント・画面デザインの変更をPRで視覚的に説明したい開発者 プロダクトマネージャーがPR reviewで変更内容を画像・動画で確認したい デザイナーが実装結果のビジュアルをブラウザで検証したい ドキュメント化・ステークホルダーへの説明資料として変更ビジュアルを自動生成したい 3ステップのビジュアル生成・デプロイフロー： 1. スクリーンショット取得：npm run dev で開発サーバを起動、Playwright で http://localhost:3000/ をフルページ・Chromium・1440×900ビューポートで撮影、screenshots/pr-{PR_NUMBER}/.png に保存 2. デモGIF生成：npm run dev 起動後、node scripts/record-pr-demo.js {PR_NUMBER} {PROJECT_ID} で該当PRの機能に合わせたUIインタラクション（クリック・入力・スクロールなど）を記録、ffmpeg で webm→gif 変換（fps=10、パレット最適化）、screenshots/pr-{PR_NUMBER}/demo.gif 生成 3. gh-pages デプロイ：git stash→git checkout gh-pages→スクリーンショット類をコピー→add/commit/push（gh-pages ブランチ）→元ブランチ復帰。結果として https://tagty.github.io/taskflow/pr-{PR_NUMBER}/demo.gif や .../{name}.png でアクセス可能に