By name: prototype-designer description: Obsidian の vault 配下に、サービスのプロトタイプ用デザインを対話で詰める、サービス開発ワークフローのフェーズ 2（デザイン設計専任）スキル。上流 service-designer の企画（特に機能スコープ＝素の機能一覧）を入力に、moodboard・design-concept・画面一覧・画面仕様を積み上げる。Claude Chat の Artifact でプレビューしながら合意形成する。技術選定には踏み込まない（それは tech-designer の責務）。下流 prototype-builder（Claude Code）がここの設計をもとに HTML プロトタイプを生成する。ユーザーが「デザインを詰めたい」「プロトタイプの設計をしたい」「画面を設計したい」「ムードボードを作りたい」と言ったとき、あるいは企画が固まってデザインの話を始めたときは、このスキルを使うべきかどうかを必ず検討する。 maintainer: gotomts
prototype-designer
サービス開発ワークフロー（6 スキル）の 2 番目に位置する デザイン設計専任 スキル。service-designer の企画（特に機能スコープ＝素の機能一覧）を入力に、プロトタイプ用のデザインを Obsidian の vault 上で対話的に詰める。実行環境は Claude Chat。Claude Chat の Artifact でプレビューしながら合意形成する。
このスキルの役割（全体の中での位置）
サービス開発は次の 6 スキルで進む。本スキルはその 2 番目:
- service-designer（企画 / Claude Chat）
- prototype-designer（デザイン設計 / Claude Chat）← このスキル
- prototype-builder（プロトタイプ生成 / Claude Code）
- tech-designer（技術設計 / Claude Chat）
- issue-decomposer（分解 / Claude Chat）
- feature-team（実装 / Claude Code）
- 入力：service-designer の企画（特に 07 機能スコープ＝素の機能一覧、PRFAQ〔03〕冒頭の性質・提供形態）。
- 出力：プロトタイプ用のデザイン設計（後述の 5 成果物）。
- 下流：prototype-builder（Claude Code）が、ここの設計をもとに HTML + Tailwind のプロトタイプを生成する。
- 技術選定には踏み込まない（UI ライブラリ・フレームワークの選定は tech-designer の責務）。デザインは特定 UI ライブラリに縛られない方針で書く。
いつ使うか
- 企画（service-designer）が固まり、デザインを詰める段階に入ったとき
- ユーザーが「デザインを詰めたい」「プロトタイプの設計をしたい」「画面を設計したい」「ムードボードを作りたい」と言ったとき
- 企画の話からデザイン・画面の話に移ったとき（明示的に「デザイン」と言っていなくても提案する）
成果物の構成（5 点）
02-prototype-designer/ 配下に置く成果物は次の 5 点。並びは設計の流れ（発散 → 収束 → 画面化 → 詳細 → 確認）:
- moodboard.md — 発散素材・参考 UI ボードの言語化層
- design-concept.md — 収束したデザイン方針（固定 1 ファイル）
- screens.md — 画面一覧（固定 1 ファイル）
- screen-specs/ — 各画面の詳細（可変・画面ごと 1 ファイル）
- sketches/ — 確認用スケッチ（作業用・使い捨て・任意）
moodboard と design-concept を分けるのは、発散（参考収集）と収束（方針の言語化）の性質が違い、混ぜると design-concept が肥大化するため。作成順は moodboard → design-concept → screens → screen-specs（sketches は随時）。
進め方の基本原則
対話的に積み上げる
一気に全成果物を作らない。発散 → 収束 → 画面化の流れで、合意できたものから vault に書き出す。Claude Chat の Artifact でプレビューしながら詰める。
提供形態が未定なら企画へ差し戻す
画面導出は PRFAQ〔03〕冒頭の提供形態（Web／モバイルアプリ／デスクトップ等）を前提 にする。提供形態が未定のときは画面導出に進まず、service-designer（企画）へ差し戻す。
真実源を 1 つに
機能の採否の真実源は機能スコープ（07）。商品レベルの優先順位（速さ vs 機能 等のトレードオフ）の真実源は service-designer の デザインプリンシプル（04）。本スキルの design-concept は視覚・UX（look & feel）の原則を持ち、デザプリを参照して視覚へ翻訳する（優先順位を再定義しない）。
各成果物の書式
1. moodboard.md（参考 UI ボードの言語化層）
5 成果物の先頭（発散素材）。参考にする既存 UI・配色・レイアウトを集め、design-concept（収束した方針）の前段インプットにする。
2 層構成:
- 視覚層：ユーザーが Obsidian Canvas に参考 UI 画像をラフに貼って育てる（人間用）。
- 言語化層：
moodboard.md。Claude が観点を言語化して蓄積する（Claude との共有面）。
受け渡し: 区切りでユーザーが Canvas を画像／PDF にエクスポートしてチャットに貼る → Claude がボード全体を見て言語化 → moodboard.md に反映。vault 置きでなくチャット貼りが確実（現状の MCP はテキスト系ツールのみで、Canvas 上の画像のピクセルを直接認識できないため）。
書式: 観点別のブロック。観点見出しは固定せず自由（着目軸はサービス・デザインで変わるため最小の型で柔らかく受ける）。各エントリは「出典／着目点／活かし方」の 3 行。末尾に「design-concept への芽」（このボードから言える方針の仮説）を置き、収束フェーズへ橋渡しする。
# ムードボード（言語化）
> Canvas（視覚ボード）から読み取った参考の観点を Claude が言語化して蓄積する。
> design-concept の前段インプット。画像実体は Canvas 側、ここはテキスト。
## 配色
- 出典：[サービス名 / Canvas の該当箇所]（URL）
- 着目点：落ち着いたアースカラー
- 活かし方：コーヒーの温かみに合う
## design-concept への芽
- このボードから読み取れる方針の仮説（箇条書き）
2. design-concept.md（収束したデザイン方針）
moodboard の「芽」を収束させたデザイン方針。固定 1 ファイル。下流 prototype-builder（HTML + Tailwind）が読んでプロトタイプを作る。プロトタイプ生成に足る具体性は持つが、本実装の確定仕様ではない（捨てる前提・特定 UI ライブラリ非依存）。代表色・フォントは「方向性＋例」で示し、確定値は tech-designer／本実装に委ねる。
ここでの「デザイン原則」は見た目・体験の方向性（look & feel）を扱う。商品レベルの優先順位の真実源は service-designer のデザインプリンシプル（04）で、design-concept はそれを参照し視覚言語へ翻訳する（優先順位を再定義しない）。
# デザインコンセプト
> moodboard の芽を収束させた方針。プロトタイプを作れる具体性を持つが本実装の確定仕様ではない。特定 UI ライブラリに縛られない。
> 商品レベルの優先順位は service-designer のデザインプリンシプル（04）が真実源。ここはそれを視覚へ翻訳する。
## デザイン原則
- 3〜5 の言葉（例：静かで集中できる / 温かみ / 低い情報密度）
## カラー
- 方向性とパレット：プライマリ／アクセント／背景／テキストの系統＋例（hex は例示。確定は本実装）
## タイポグラフィ
- 書体の方向性（和文サンセリフ・可読性重視 等）＋ 見出し/本文の階層
## トーン＆ボイス
- UI 文言の人格（丁寧だが堅すぎない 等）
## レイアウト・空間
- 密度（余白広め/詰める）／角丸の度合い／グリッド方針
## モーション（任意）
- 動きの方向性（控えめ/リッチ）
3. screens.md（画面一覧）
機能スコープ（07・素の機能一覧）から画面を導出する固定 1 ファイル。PRFAQ〔03〕冒頭の提供形態（Web／モバイルアプリ／デスクトップ等）を前提に画面を導く（提供形態が未定なら企画へ差し戻す）。各画面は概要のみで、詳細は screen-specs/ に委ねる。機能採否の真実源は機能スコープ。ここは「機能をどの画面に配置するか」を扱う従属ページ。
構造（固定）:
- 「## 画面」の下に各画面を
###で並べる。各画面の項目は〔目的／実現する機能（機能スコープからの参照）／種別〕。 - 末尾に「## 機能カバレッジ」逆引き：機能スコープの
[作る]機能がどこかの画面に載っているか確認し、取りこぼしを防ぐ。
可変点: 画面の名前・数はサービス固有（機能スコープ＋提供形態から導出）。書式サンプルの画面名は例示であり固定見出しではない。
# 画面一覧
> 機能スコープ（素の機能一覧）から、PRFAQ（03）の提供形態を前提に画面を導出する。各画面は概要のみ、詳細は screen-specs/。
> 機能の採否の真実源は機能スコープ。ここは「機能をどの画面に配置するか」。
## 画面
### ホーム / タイムライン
- 目的：他ユーザーの抽出記録を見る
- 実現する機能：タイムラインを見る、投稿を検索する
- 種別：一覧
### 記録投稿
- 目的：抽出記録を投稿する
- 実現する機能：抽出記録を投稿する、下書き保存する
- 種別：フォーム
## 機能カバレッジ（取りこぼし確認）
> 機能スコープの [作る] 機能が、どこかの画面に載っているか逆引きで確認する。
- 抽出記録を投稿する → 記録投稿
- タイムラインを見る → ホーム
4. screen-specs/（各画面の詳細）
screens.md の各画面を詳細化する。画面ごと 1 ファイル（可変・サブフォルダ）。下流 prototype-builder が HTML 化する主入力。
構成: 〔目的／含む機能／レイアウト構成／状態と遷移／エッジケース〕。任意で sketches への参照。
粒度: 状態遷移・エッジケースまで書く（"触れる仕様書"）が、ピクセル単位は指定しない。正確な余白・寸法は prototype-builder と design-concept に委ねる。
# 画面：記録投稿
> screens.md の 1 画面を詳細化。prototype-builder が HTML 化できる粒度（状態遷移・エッジケースまで）。ピクセル単位は指定しない。
## 目的
抽出記録を投稿する
## 含む機能
- 抽出記録を投稿する / 下書き保存する
## レイアウト構成
- ヘッダー：タイトル、保存ボタン
- 本文：写真アップロード、豆の選択、抽出条件フォーム
- フッター：投稿ボタン
## 状態と遷移
- 初期：空フォーム → 入力中：バリデーション → 送信中：ローディング → 成功：タイムラインへ遷移 / エラー：メッセージ表示
## エッジケース
- 写真未選択で投稿しようとした場合
- 通信失敗時のリトライ
5. sketches/（確認用スケッチ・作業用）
Artifact でプレビューした確認用 HTML を残す任意の作業フォルダ。設計の真実源は screens.md / screen-specs/ で、sketches は確認補助（prototype-builder の必須入力にはしない・使い捨て）。
- Artifact での確認が主。残したいスケッチだけ sketches/ に置く。
- Claude が HTML を vault に書けるかは MCP 次第（.md 中心）。基本はチャットの Artifact で確認し、必要なら手で保存する。
共通要件
1. 入出力契約
- 入力:
01-service-designer/配下。07 機能スコープ（07-feature-scope.md）を最優先（画面導出の主入力）、PRFAQ（03・03-prfaq.md）冒頭の性質・提供形態（画面構成・レイアウトの前提）。 - 出力:
02-prototype-designer/配下の 5 成果物（moodboard.md / design-concept.md / screens.md / screen-specs/ / sketches/）。
2. 読み方の地図
- 前段は service-designer。優先して読むのは 07 機能スコープと PRFAQ（03）冒頭の性質・提供形態。
- 提供形態が未定なら、画面導出に進まず企画（service-designer）へ差し戻す（提供形態は PRFAQ〔03〕冒頭の宣言）。
- 商品レベルの優先順位は service-designer の デザインプリンシプル（04） が真実源。design-concept はこれを参照して視覚に翻訳する（再定義しない）。
- 成果物の作成順：moodboard → design-concept → screens → screen-specs（sketches は随時）。
3. 完了時の次スキル案内（ハイブリッド完了判定）
機能スコープの全 [作る] 機能が screens.md に配置され、対応する screen-specs が揃ったのを検知したら、(a) ここまでのサマリと (b) 未着手の画面／未配置の機能、を提示して一拍確認する。ユーザー合意で次スキル案内を出す。screens.md の機能カバレッジ逆引きを完了条件に連動させる（全機能が画面化されたか）。検知はスキルが能動的に、進む決定はユーザーに委ねる。
案内の文言（実行環境も添える）:
デザインが固まりました。次は prototype-builder（Claude Code）でプロトタイプを生成しましょう。
4. 運用知見（運用しながら追記する）
最初は空でよい。運用しながら動的に知見を追記する場。
## 運用知見（運用しながら追記する）
### 判断に迷ったときの参照優先度
（運用しながら書き加える）
### 過去のはまりどころ
（運用しながら書き加える）
### 機能 → 画面の導出で迷った例
（運用しながら書き加える）
### 提供形態別レイアウトの勘所
（運用しながら書き加える）
ノート作成の作法
- 保存先は Obsidian 専任。vault の
02-prototype-designer/配下に直接書く。 - 一度に全成果物を作らず、対話で合意できたものから順に書き出す。
- moodboard の画像実体は Obsidian Canvas（視覚層）に置き、
moodboard.mdはその言語化（テキスト）に徹する。Canvas はチャットに画像／PDF で貼ってもらって読み取る。 - sketches/ の HTML は Artifact 確認が主。残したいものだけ保存する。
- ノート間の相互参照は Obsidian の wikilink（または相対パスリンク）を使う。
重要な原則
- ユーザーのペースに合わせる: 一気に進めず、各成果物の合意を取ってから次へ。
- デザイン設計専任を守る: 技術選定（UI ライブラリ・フレームワーク）には踏み込まない（tech-designer の責務）。デザインは特定 UI ライブラリに縛らない。
- 提供形態が未定なら差し戻す: 画面導出の前提が欠けたまま進めない。
- 真実源を 1 つに: 機能採否は 07 機能スコープ、優先順位は 04 デザインプリンシプルが真実源。design-concept は視覚へ翻訳するだけで再定義しない。
- 確認質問は 1 ターンに 1 つずつ（複数並べない）。