wireframe-builder

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: 前提の確認

1. ユーザーゴールを確認（この機能で何を達成したいか）
2. 対象ユーザーを確認（誰が使うか）
3. 主要タスクを書き出す（ユーザーがやること）

Phase 2: フロー設計

4. ユーザーフローを作成（Mermaid flowchart）
5. 画面一覧を洗い出す（テーブル形式）
6. 動的プロセス（ウィザード等）があればWireflowとして画面＋フローを統合

Phase 3: ワイヤーフレーム作成

7. 各画面のASCIIワイヤーフレームを作成
   • 重要な要素ほど上・左・目立つ位置に配置
   • ナビゲーション構造を明示
   • PC/SPで異なる場合は両方作成
8. 各画面の注釈を作成（templates/screen-annotation.md参照）

Phase 4: レビュー観点の提示

9. 確認ポイントを提示
   • 要件の過不足
   • 導線の破綻
   • エッジケース（空、エラー、権限）

---

Quality Checklist（自己確認）

• ユーザーゴールと主要タスクが明確
• ユーザーフローで画面遷移が破綻していない
• 各画面の目的とPrimary CTAが明確
• 情報の優先順位がレイアウトに反映されている
• 状態（Empty/Loading/Error/Success）が考慮されている
• 入力項目のバリデーションが明記されている
• エッジケース（権限、0件、上限）が考慮されている
• 色・装飾ではなく構造・導線に集中している

---

Examples

発動する例

• 「ユーザー登録フローのワイヤーフレームを作って」
• 「ダッシュボード画面の構成を設計して」
• 「ECサイトの商品一覧→詳細→カートの画面設計をして」
• 「管理画面のレイアウトを考えて」
• 「このPRDから画面のワイヤーを起こして」
• 「画面の骨組みを整理したい」

発動しない例

• 「画面のデザインを作って」→ モックアップ（ui-mockup-builder）の領域
• 「ボタンの色を決めて」→ ビジュアルデザインの領域
• 「動くプロトタイプを作って」→ プロトタイピングツールの領域
• 「コンポーネントを実装して」→ 実装の領域

---

References

• 詳細ガイド・判断基準：reference.md
• 画面注釈テンプレート：templates/screen-annotation.md