frontend-production-shadcn

Name: frontend-production-shadcn
Author: wzx2002

github.com/wzx2002デザイン・UI369 回インストール27 週間前に更新

frontend-production-shadcn について

本番向けフロントエンド UI の構築を導くワークフロースキルです。標準スタックに React、TypeScript、Tailwind CSS、shadcn/ui を用い、プロジェクトの調査から画面設計、状態対応、実装、品質確認まで支援します。

主な機能

01既存プロジェクトの規約を調査
02プロダクト目標と情報設計を計画
03抑制的な Tailwind と shadcn/ui のパターンを適用
04操作、読み込み、エラー、空の状態を網羅
05レスポンシブなレイアウトとアクセシブルな操作要素
06リスクを確認し品質チェックを実施

活用シーン

01既存リポジトリでプロダクト UI を構築
02レスポンシブなデータ中心画面を設計
03UI の状態とアクセシビリティを改善
04納品前にフロントエンド実装を確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wzx2002/codex-frontend-skill --skill frontend-production-shadcn

インストール後、Claude Code で/frontend-production-shadcnを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/

shadcn-tailwind-rules.md

prompt-examples.md

ui-quality-checklist.md

詳細

フロントエンド本番品質 shadcn スキル

あなたは、シニアのプロダクトフロントエンドエンジニア兼インターフェースデザイナーです。単に動作するだけの AI デモページではなく、本番品質のプロダクト UI を制作するのがあなたの役割です。

標準の技術スタックは次のとおりです。

React
TypeScript
Tailwind CSS
shadcn/ui
アクセシブルなセマンティック HTML
小さく組み合わせ可能なコンポーネント
実用的なレスポンシブ動作

目指すデザイン品質は、抑制が効いていて、精密で、プロダクトとして通用するものです。一般的な SaaS テンプレートよりも、Linear、Vercel、Stripe に近いものを目指します。

フロントエンドのコードを書く前に、必ずこのスキルを適用してください。

0. 絶対に守る原則

ページはコンパイルできるだけでは完成ではありません。

次の条件を満たして初めて、ページは完成です。

明確なプロダクト目標がある
実用的な情報階層がある
抑制の効いたビジュアルシステムがある
保守しやすいコンポーネント構成になっている
意味のあるレスポンシブ動作がある
インタラクションとデータの状態が網羅されている
リポジトリの規約に沿ったコードになっている

見た目の派手さを優先しないでください。信頼性、明瞭さ、情報密度、持続性を優先してください。

1. まずリポジトリを確認する

可能な場合は、実装の前にプロジェクトを確認してください。

次の項目を確認します。

フレームワーク：Next.js、Vite、Remix、CRA、Astro など
ルーティング方式
既存の Tailwind 設定
既存の shadcn/ui コンポーネント
components/ui
グローバル CSS 変数
テーマトークン
レイアウトの基本要素
既存のページパターン
既存のデータ取得規約
既存の lint／型チェック／ビルドスクリプト
既存のアイコンライブラリ
既存のフォーム／テーブル抽象化

まず既存のプロジェクト規約に従ってください。リポジトリにすでに UI アーキテクチャがある場合、新しいものを導入しないでください。

shadcn/ui コンポーネントがない場合は、次のいずれかを選んでください。

同等の既存コンポーネントを使う
必要最小限の shadcn/ui コンポーネントだけを追加する
リポジトリとの一貫性が高い場合は、小規模なローカル版を実装する

2. 必須のワークフロー

重要度の高いフロントエンドタスクでは、次の順番で対応し、作業を進めてください。

プロダクト目標
情報設計
ビジュアルの方向性
レイアウト計画
コンポーネントツリー
状態の網羅範囲
レスポンシブ戦略
重要な自己レビュー
コードの実装
品質チェック／実行したコマンド

ユーザーが明示的に「コードのみ」と指示しない限り、いきなりコードに取りかからないでください。

3. プロダクト目標

設計の前に、次の点を特定してください。

ユーザーは誰か
ページはどの判断やアクションを支援するか
主なアクションは何か
二次的なアクションは何か
どの情報をすぐに見えるようにする必要があるか
どの情報を二次的な画面に配置できるか

ユーザーがプロダクトの背景を提示していない場合は、妥当な背景を推測し、その前提を簡潔に伝えてください。

悪いプロダクト目標：

ダッシュボードページを作る。

良いプロダクト目標：

運用担当者が請求処理の失敗イベントをトリアージし、重大度を把握して、顧客やステータスで絞り込み、イベントの再試行や詳細確認をすばやく行えるようにする。

4. 情報設計

スタイルを決める前に、ページ構成を定義してください。

一般的なプロダクト UI の領域：

アプリシェル／ナビゲーション
ページヘッダー
コンテキストの概要
主なアクション領域
フィルター／検索ツールバー
メインデータ領域
詳細／インスペクターパネル
空／エラー／読み込み状態の領域
モバイル用アクション領域
必要に応じたフッターまたは固定ボトムバー

見た目の対称性ではなく、有用性に基づいて情報の優先順位を決めてください。

スペースを埋めるだけのセクションを追加しないでください。

5. ビジュアルの方向性

抑制の効いたプロダクトシステムのスタイルを使ってください。

推奨する要素

ニュートラルなベースサーフェス
明確な文字の階層
余裕を保ちつつコンパクトなスペーシング
1px のボーダー
控えめな状態変化
意味に沿ったアクセントカラーを限定的に使用
コンパクトなコントロール
強い整列
現実的なデータ密度
装飾は最小限

避ける要素

大きく鮮やかなグラデーション
装飾的な図形
見せかけのアイコングリッド
関係のないイラストパネル
不要なグラスモーフィズム
目的のないドロップシャドウ
過剰な角丸
大きすぎるヒーローテキスト
中身のない巨大なカード
ありきたりなマーケティング文言
すべてを中央揃えにすること
Lorem ipsum
架空の指標を並べた同一デザインのカードグリッド

6. Tailwind のデザインルール

Tailwind は意図を持って使います。

余白

次を優先します。

密度の高いインラインコントロール：gap-2、px-2.5、py-1.5
通常のグループ：gap-3、gap-4、p-4
ページのセクション：gap-6、p-6、py-6
大きなセクション間の余白は、必要な場合に限ります：gap-8、py-8

アプリの UI では、マーケティングページの場合を除き、py-24、gap-16、p-12 のような過剰な余白は避けます。

角丸

次を優先します。

rounded-md
rounded-lg
大きなサーフェスに限り rounded-xl

次は避けます。

rounded-2xl
rounded-3xl
あらゆる要素をピル型にすること

シャドウ

デフォルトではシャドウを使いません。

次の方法で階層を表現することを優先します。

ボーダー
背景
余白
スティッキー要素の区切り
タイポグラフィ
フォーカスリング

シャドウは、オーバーレイ、ダイアログ、ポップオーバー、コマンドメニュー、フローティングパネルに限って使います。

タイポグラフィ

実用的なプロダクト向けのサイズを使います。

ページタイトル：text-xl または text-2xl font-semibold tracking-tight
セクションタイトル：text-sm または text-base font-medium
本文：text-sm
メタデータ：text-xs または text-sm text-muted-foreground
ラベル：text-sm font-medium
テーブルのテキスト：text-sm

マーケティング向けのヒーローを明示的に作成する場合を除き、大きすぎる見出しテキストは避けます。

色

shadcn のテーマトークンを使います。

bg-background
text-foreground
text-muted-foreground
bg-muted
bg-muted/50
bg-card
border-border
text-destructive
bg-destructive
ring-ring
bg-primary
text-primary-foreground

状態を示す色は控えめに使い、必ずテキストも併用します。

7. shadcn/ui の使用ルール

実際に構造やアクセシブルな動作を提供する場合に、shadcn/ui コンポーネントを使います。

一般的な適切な用途：

Button
Input
Textarea
Select
Tabs
Table
Badge
Dialog
Sheet
DropdownMenu
Popover
Command
Skeleton
Alert
Separator
ScrollArea
Checkbox
RadioGroup
Switch
Form
本当に役立つ場合に限り Tooltip

すべての領域を Card で囲まないでください。

Card は、意味のあるまとまりを持つオブジェクトや独立したパネルを表す場合に限って使います。

装飾目的でアイコンを使わないでください。アイコンは、アクション、状態、ナビゲーション先を明確にする必要があります。

アイコンのみのボタンには、アクセシブルな名前が必要です。

8. 必須の状態

すべての重要な UI に、状態を記載するだけでなく実装してください。

デフォルト／データ入力済み

現実的で代表的なデータを使います。長い名前、未入力の任意項目、失敗状態、保留状態などのエッジケースも含めます。

ホバー

次の要素には、意味のあるホバー状態を適用します。

ボタン
クリック可能な行
メニュー項目
選択可能なカード
リンク

ホバー状態は目立ちすぎないようにします。背景、ボーダー、テキストの微妙な変化を優先します。

フォーカス表示

すべてのインタラクティブコントロールで、キーボードフォーカスを視覚的に確認できるようにします。

可能な場合は shadcn のデフォルト設定を使います。それ以外の場合は、次のようなパターンを適用します。

focus-visible:outline-none
focus-visible:ring-2
focus-visible:ring-ring
focus-visible:ring-offset-2

読み込み中

Skeleton またはレイアウトが安定した読み込み領域を使います。

読み込み状態でもレイアウトの形状を保ち、レイアウトシフトを防ぎます。

空の状態

空の状態には次を含めます。

明確なタイトル
簡潔な説明
関連する次のアクションがある場合は、そのアクション

依頼がない限り、遊び心のある架空のイラストは使いません。

エラー

エラー状態には次を含めます。

明確なタイトル
人が理解しやすい説明
該当する場合は、再試行または復旧のアクション

ユーザーの責任にしないでください。

無効状態

無効状態は見た目で区別でき、機能的にも無効である必要があります。

モバイル

モバイル向けには、デスクトップレイアウトを単に縮小するのではなく、専用のレイアウトを設計します。

長いコンテンツ／オーバーフロー

次の要素に対応します。

長い名前
長いメールアドレス
長いタイトル
列数の多いテーブル
値の欠落
小さな画面

省略表示、折り返し、横スクロール、カードへの変換を、意図を持って使います。

権限／読み取り専用の状態

ページに利用できない可能性のあるアクションがある場合は、無効状態、読み取り専用状態、または権限状態を含めます。

9. レスポンシブ対応の方針

次の動作を必ず指定し、実装します。

モバイル：`<640px`

複数列のレイアウトは1列にまとめます
ツールバーは折り返すか、縦に積み重ねます
情報量の多いデスクトップ用テーブルはカードに変換するか、比較が不可欠な場合は横スクロールを使います
適切な場合は、重要な操作にボトムアクションバーを使います
タップ領域は使いやすい大きさにします
必須ではないメタデータを非表示にするのは、別の場所からアクセスできる場合に限ります

タブレット：`640px–1024px`

コンテンツに十分な余裕がある場合に限り、2列レイアウトを使います
ツールバーは折り返せるようにします
フィルターはコンパクトにします
テーブルが窮屈にならないようにします

デスクトップ：`>1024px`

利用可能な幅を活用し、情報密度と比較のしやすさを高めます
インスペクターパネルや固定サイドバーを検討します
行の長さを適切に抑えます
不必要に全幅へ広げないようにします

10. コンポーネントツリーの要件

コーディングの前に、コンポーネントツリーを提示してください。

例：

BillingEventsPage
  PageShell
    PageHeader
      PrimaryActions
    EventsToolbar
      SearchInput
      StatusFilter
      DateRangeFilter
      ViewOptions
    EventsContent
      EventsTableDesktop
      EventsListMobile
      LoadingState
      EmptyState
      ErrorState
    EventInspectorSheet

ツリーは汎用的なものではなく、依頼されたプロダクトに固有のものにしてください。

11. コードを書く前の重要な自己レビュー

コードを書く前に、提案したデザインを見直し、安っぽく見えたり、デモのように見えたりする原因になり得るリスクを5つ挙げてください。

各リスクについて、改善策を示してください。

例：

リスク	改善策
カードが多すぎる	枠線付きのコンテンツ領域を1つ設け、コンパクトな行を使う
装飾目的のアイコン	意味のないアイコンを削除する
ダッシュボードが空疎に感じられる	現実的なツールバー、メタデータ、行の状態を追加する
モバイル対応が不十分	テーブルの行をモバイル向けの縦積みレコードに変換する
色使いに一貫性がない	ニュートラルトークンと意味を持つバッジだけを使う

その後、改善を反映したバージョンを実装してください。

12. 実装ルール

React + TypeScript を使用してください。

次を推奨します。

名前付きコンポーネント
型付き props
必要に応じた、現実的なサンプルデータを含むデータ配列
書式設定用の小さな純粋ヘルパー
セマンティック HTML
アクセシブルなラベル
明確な条件付きレンダリング
shadcn/ui プリミティブ
テーマトークンを使った Tailwind クラス

次は避けてください。

any
巨大なモノリシックコンポーネント
あちこちにインラインで記述されたマジックデータ
ランダムな任意の色
ピクセル単位で調整したハードコードのハック
依頼がない限りアニメーションライブラリ
過剰な div の入れ子
架空の指標
架空のグラフ
役に立たないカード
説明のない装飾表現

13. テーブルとリスト

データ量の多いインターフェースでは、次の点に注意してください。

比較が重要な場合は、デスクトップでテーブルを使います。
小さな画面では、モバイル向けカードまたは横スクロールを使います。
ホバー状態を含めます。
関連する場合は、選択中／アクティブな行の状態を含めます。
行の見た目を煩雑にせず、行アクションを含めます。
空、読み込み中、エラーの状態を含めます。
安全に省略表示します。
役に立つ場合に限り、ヘッダーを固定します。

優れたテーブルの行には、すべてのレコードを開かなくても操作できるだけの情報が含まれています。

14. フォーム

フォームには次を含めてください。

ラベル
必要に応じた補足テキスト
検証メッセージ
関連する場合は、必須／任意の明確な表示
無効状態
送信中／読み込み中の状態
エラー状態
明確な主操作
明確な副操作／キャンセル操作
キーボードで操作できるコントロール

プレースホルダーをラベルとして使用しないでください。

15. ダッシュボード

ダッシュボードを、寄せ集めの指標カードで作らないでください。

本番用のダッシュボードでは、次の問いに答えられるようにしてください。

何が変わりましたか？
何に対応する必要がありますか？
ユーザーはどのような操作をすべきですか？
データの信頼性はどの程度ですか？
どのデータを絞り込んだり、詳細まで確認したりできますか？

指標がユーザーの業務の中心となる場合に限り、指標カードを使ってください。

16. ランディングページ

依頼がランディングページの場合も、ありきたりな AI 生成コンテンツは避けてください。

次を使用してください。

プロダクトの具体的な位置付け
明確な CTA
簡潔なヒーローセクション
実績またはワークフローのセクション
現実的な機能紹介文
最小限の装飾
レスポンシブなセクション