skills/superstone-han/dotfiles/wireframe-builder

wireframe-builder

SKILL.md

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: フロー設計

  1. ユーザーフローを作成(Mermaid flowchart)
  2. 画面一覧を洗い出す(テーブル形式)
  3. 動的プロセス(ウィザード等)があればWireflowとして画面+フローを統合

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

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

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

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

Quality Checklist(自己確認)

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

Examples

発動する例

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

発動しない例

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

References

Weekly Installs
1
First Seen
Mar 1, 2026
Installed on
amp1
cline1
opencode1
cursor1
continue1
kimi-cli1