design-brief

このスキルでは、段階的な対話を通じてデザインブリーフを作成します。必要のないステップは省略できます。

プロンプトの例

• 「オンボーディングフローのブリーフを作成してください」
• 「設定ページを作り始める前に、計画を立てたいです」
• 「マーケティング用ランディングページの方向性を決めるのを手伝ってください」
• 「これについてブリーフを作成してください：プロジェクトの健全性指標を表示するダッシュボード」

プロセス

1. 何を作りたいのか、誰が使うのか、すでに決まっている制約やアイデアがあれば、詳しく説明するようユーザーに尋ねます。

2. 既存のコードベースを調べ、現在の状態を把握します。特に、次の項目をそれぞれ確認します。

   • CSS 変数／トークン：tokens.css、variables.css、theme.cssという名前のファイル、またはカスタムプロパティを含む:root宣言
   • Tailwind の設定：tailwind.config.jsまたはtailwind.config.tsを確認し、theme.extendにカスタム値があるか調べます
   • UI フレームワークのテーマ：Material UI のcreateTheme、Chakra のextendTheme、shadcn のglobals.cssとcomponents.json
   • コンポーネントディレクトリ：components/、ui/、shared/、または再利用可能な UI パーツを含むフォルダ
   • Storybook：コンポーネントライブラリのドキュメントを示す.storybook/ディレクトリまたは*.stories.*ファイル
   • デザイントークンファイル：JSON 形式のトークンファイル（Style Dictionary 形式、Figma のトークンエクスポート）
   • package.json の UI 依存関係：tailwindcss、@mui/material、@chakra-ui/react、@radix-ui、lucide-react、framer-motion など
   • フォントの読み込み：HTML 内の Google Fonts リンク、@font-face宣言、CSS／設定ファイル内のフォントインポート
   • 既存のページ／レイアウト：確立されたパターンがわかるルートファイル、レイアウトコンポーネント、ページテンプレート
   • コンポーネントがある場合は、それらを出発点となる語彙として扱います。ブリーフでは置き換えるのではなく、拡張するようにします。

3. 共通認識が得られるまで、デザインのあらゆる側面についてユーザーに徹底的に質問します。デザインの各分岐をたどり、判断間の依存関係を一つずつ解決します。質問ごとに、推奨する回答も提示します。

   最低限、次の点を確認します。

   • 主なユーザーは誰で、どのような JTBD を抱え、何を達成しようとしていますか？
   • このインターフェースの成功とは、どのような状態ですか？
   • どのような感情的なトーンにしますか？（落ち着いた、緊急感のある、遊び心のある、権威ある、温かみのある、臨床的な）
   • どの既存の製品、サイト、スタイルに似た印象を持たせますか？どのような印象は避けるべきですか？
   • 絶対に守るべき制約は何ですか？（デバイス、アクセシビリティ要件、パフォーマンス予算、ブランドガイドライン）
   • このインターフェースにはどのようなコンテンツを含めますか？プレースホルダーと実際のコンテンツはそれぞれどれですか？

4. 全体像を把握したら、以下のテンプレートを使ってブリーフを作成します。

ファイル出力

ブリーフを.design/<feature-slug>/DESIGN_BRIEF.mdに保存します。<feature-slug>には、設計対象の機能またはページに由来する、短く小文字でハイフン区切りの名前を指定します（例：onboarding-flow、settings-page、project-dashboard）。

このフォルダ構成により、異なる機能についてデザインフローを複数回実行しても、以前の作業が上書きされません。以降のすべてのスキル（information-architecture、design-tokens、brief-to-tasks、design-review）は、同じサブフォルダを読み書きします。

例：

.design/
├── onboarding-flow/
│   └── DESIGN_BRIEF.md
└── settings-page/
    └── DESIGN_BRIEF.md

ブリーフのテンプレート

# Design Brief: [Feature/Page Name]

## Problem

What problem is the user facing, described from their perspective. Not technical. Not business metrics. The human friction.

## Solution

What this interface does to solve that problem, described as an experience, not a feature list.

## Experience Principles

Three principles maximum that guide every design decision. Each principle should resolve a tension.
Example: "Progressive disclosure over upfront complexity" or "Confidence over speed."

1. [Principle] -- [What this means in practice]
2. [Principle] -- [What this means in practice]
3. [Principle] -- [What this means in practice]

## Aesthetic Direction

- **Philosophy**: [Named philosophy or described vibe. See /frontend-design skill for reference.]
- **Tone**: [Emotional register]
- **Reference points**: [Existing products, sites, or styles this should feel like]
- **Anti-references**: [What this should NOT feel like]

## Existing Patterns

Components, tokens, and conventions already in the codebase that this design must respect or extend.

- Typography: [what is currently used]
- Colors: [current palette/variables]
- Spacing: [current scale]
- Components: [existing components that will be reused or extended]

## Component Inventory

A list of the UI components this feature requires. For each, note whether it exists already, needs modification, or is new.

| Component | Status                | Notes    |
| --------- | --------------------- | -------- |
| [name]    | Exists / Modify / New | [detail] |

## Key Interactions

The critical interaction patterns. Describe what the user does and what the interface does in response. Focus on state changes, transitions, and feedback.

## Responsive Behavior

How the layout adapts across breakpoints. Note any components that change behavior (not just size) on mobile.

## Accessibility Requirements

Minimum requirements for this interface. Include contrast ratios, keyboard navigation, screen reader considerations, and focus management.

## Out of Scope

Things this brief explicitly does not cover. Be specific. This prevents scope creep during build.