| name | wireframe-builder |
| description | Web/アプリの画面ワイヤーフレーム（構造・レイアウト・導線）をASCII図とMarkdown注釈で作成するSkill。
「ワイヤーフレームを作って」「画面構成を設計して」「画面のレイアウトを考えて」「UI構造を整理して」「画面の骨組みを作って」
「wireframeを書いて」「画面設計して」「ラフを作って」などの依頼で発動する。
出力はASCIIワイヤーフレーム + 画面注釈（状態・制約・挙動）のMarkdown。モックアップ（見た目重視）やプロトタイプ（動作検証）とは異なる。
|
Wireframe Builder
Web/アプリの画面ワイヤーフレームを、ASCIIアート図 + Markdown注釈で作成するSkill。
Goals
- ユーザー要件から画面の構造・レイアウト・導線を設計する
- ASCII図で視覚的にレイアウトを表現する（色・装飾より構造優先）
- 注釈で仕様（状態、制約、挙動、エッジケース）を明確化する
- 実装前に要件漏れ・矛盾を炙り出せる粒度で出力する
Non-goals
- 色・フォント・画像などのビジュアルデザイン（→ モックアップの領域）
- 動作するプロトタイプの作成
- 実装コードの生成
Inputs（入力の期待形式）
以下のいずれか、または組み合わせ：
- 機能要件：「ユーザーが〇〇できる画面」
- ユーザーフロー：「検索 → 一覧 → 詳細 → 購入」
- 画面リスト：「ログイン画面、ダッシュボード、設定画面」
- 既存画面の改善依頼：「この画面のレイアウトを見直したい」
- PRD/仕様書の一部
入力が曖昧な場合、まずユーザーゴールと主要タスクを確認する。
Outputs（成果物）
1. 画面一覧（Screen Inventory）
| # | 画面名 | 目的 | 主要CTA |
|---|--------|------|---------|
| 1 | ログイン | 認証 | ログインボタン |
| 2 | ダッシュボード | 状況把握 | 新規作成 |
2. ユーザーフロー（必要な場合）
flowchart LR
A[ログイン] --> B[ダッシュボード]
B --> C[詳細]
B --> D[設定]
3. 各画面のワイヤーフレーム（ASCII図 + 注釈）
┌─────────────────────────────────────────┐
│ [Logo] [検索] [👤 User] │ ← Header
├─────────────────────────────────────────┤
│ ┌─────────┐ ┌─────────────────────────┐│
│ │ Nav │ │ Main Content ││
│ │ ・Home │ │ ┌─────────────────────┐ ││
│ │ ・Items │ │ │ Card 1 │ ││
│ │ ・設定 │ │ └─────────────────────┘ ││
│ └─────────┘ │ ┌─────────────────────┐ ││
│ │ │ Card 2 │ ││
│ │ └─────────────────────┘ ││
│ └─────────────────────────┘│
└─────────────────────────────────────────┘
4. 画面注釈（Screen Annotation）
各画面に対して以下を記載：
- Screen name / User goal / Primary CTA
- UI要素（入力・表示・操作）
- States（Empty / Loading / Error / Success）
- Validation / Rules
- Notes / Edge cases
Instructions（手順）
Phase 1: 前提の確認
- ユーザーゴールを確認（この機能で何を達成したいか）
- 対象ユーザーを確認（誰が使うか）
- 主要タスクを書き出す（ユーザーがやること）
Phase 2: フロー設計
- ユーザーフローを作成（Mermaid flowchart）
- 画面一覧を洗い出す（テーブル形式）
- 動的プロセス（ウィザード等）があればWireflowとして画面＋フローを統合
Phase 3: ワイヤーフレーム作成
- 各画面のASCIIワイヤーフレームを作成
- 重要な要素ほど上・左・目立つ位置に配置
- ナビゲーション構造を明示
- PC/SPで異なる場合は両方作成
- 各画面の注釈を作成（templates/screen-annotation.md参照）
Phase 4: レビュー観点の提示
- 確認ポイントを提示
- 要件の過不足
- 導線の破綻
- エッジケース（空、エラー、権限）
Quality Checklist（自己確認）
Examples
発動する例
- 「ユーザー登録フローのワイヤーフレームを作って」
- 「ダッシュボード画面の構成を設計して」
- 「ECサイトの商品一覧→詳細→カートの画面設計をして」
- 「管理画面のレイアウトを考えて」
- 「このPRDから画面のワイヤーを起こして」
- 「画面の骨組みを整理したい」
発動しない例
- 「画面のデザインを作って」→ モックアップ（ui-mockup-builder）の領域
- 「ボタンの色を決めて」→ ビジュアルデザインの領域
- 「動くプロトタイプを作って」→ プロトタイピングツールの領域
- 「コンポーネントを実装して」→ 実装の領域
References
