idea-to-design-doc について
Idea to Design Doc Workflow は、初期のプロダクト構想を構造化した設計ドキュメントと関連ノートにまとめるスキルです。まず意図やユーザー体験を聞き、構想が明確になってから技術方針を扱います。
主な機能
- 01一問ずつ進めるガイド付きインタビュー
- 02ライトとフルの記録モード
- 03アイデア索引と個別の Markdown ノート
- 04プロダクトを先に整理する質問順
- 05実装予定案の技術案と未解決事項の記録
活用シーン
- 01初期のアプリ構想を具体化
- 02長期参照できる設計ドキュメントを準備
- 03複数のアイデアを関連ノートとして整理
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/idea-to-design-docを入力して読み込まれたか確認します。
詳細
アイデアから設計ドキュメントへのワークフロー
ユーザーが次のように言った場合に、このスキルを使用します。
- 「アプリのアイデアがあります」
- 「このプロダクトを具体化するのを手伝ってください」
- 「この考えを設計ドキュメントにまとめてください」
- 「アイデアの一覧を作り、それぞれにノートへのリンクを付けてください」
目標
大まかなアイデアを、次の内容を含む構造化された設計ドキュメントにまとめます。
- アイデアのマスター索引
- アイデアごとの Markdown ノート
- ユーザーが
stop、that's enough、またはdoneと言った時点で終了する、ガイド付きインタビュー - アプリを理解するために必要な、プロダクトのアイデア、理念、想定する体験、実用的な技術的な形
このワークフローでは、まずプロダクトについて考えることから始め、コンセプトや理念が明確になってから技術的な側面に進みます。設計ドキュメントには、ユーザーが望むことと、後続の構築計画を支えるのに十分な技術的な方向性を記録します。
重要な制約
- バックエンド、フレームワーク、データベース設計、コードアーキテクチャについて、早い段階で話を進めすぎないでください。
- まず、プロダクトの意図、振る舞い、対象ユーザー、レイアウト、機能、UX、理念を把握します。
- その後、設計ドキュメントを作成する際に、関連する技術的な側面として、プラットフォームに関する前提、主要なシステムコンポーネント、データ要件、統合、制約、想定されるアーキテクチャ上の検討事項を含めます。
- Full モードや、実装を前提とするアイデアでは、妥当な技術的なデフォルト案をまず提案し、そのうえでユーザーに承認または変更してもらいます。データベース／ストレージ、ホスティング／デプロイ、バックエンド／ランタイム、フロントエンド／UI、認証、対象プラットフォーム、その他の技術的な要素を扱うのは、プロダクトの方向性が明確になってからにしてください。
- 可能な場合は、一度に1つの質問をしてください。
- ユーザーの回答が短い場合は、より範囲を絞った質問で掘り下げてください。
- ユーザーが停止を求めたら、ここまでの情報をもとに、ただちにノートを作成してください。
デフォルトの保存先構成
Obsidian の保管庫に直接保存するのではなく、まずローカルにファイルを保存します。
推奨されるローカルフォルダー構成：
./ideas/Ideas Index.md./ideas/<idea-title>.md
ユーザーが後から Obsidian へのエクスポートを希望した場合は、別個のエクスポート手順として扱います。
Lite モードと Full モード
すばやくアイデアを記録する場合は、役に立つノートを作るのに必要な分だけ質問する Lite モードを使用します。長期的に参照できる設計ドキュメントや、後の実装担当者への引き継ぎをユーザーが希望する場合は、Full モードを使用します。
ユーザーは、完全一致のフレーズ GREENLIGHT NEXT STAGE を使って、次の段階へ進められます。このフレーズが使われた場合は、質問をやめ、現在の情報で草案を作成し、不足している情報を 未解決の質問 に記録します。
インタビューの流れ
ユーザーの回答に合わせて調整しながら、次の順番で質問します。より効果的な質問には、idea-superpowers-suite/references/interview-question-bank.md を使用します。
- 仮タイトル
- 「このアイデアを、ひとまず何と呼びましょうか？」
- 課題／目的
- 「どのような課題を解決しますか？ または、何のためのものですか？」
- 対象ユーザー
- 「誰を対象にしていますか？」
- 主な振る舞い
- 「誰かが使ったとき、どのように動作すべきですか？」
- 主なユーザーフロー
- 「ユーザーが最初から最後までできるべき、主なことは何ですか？」
- 主な機能
- 「必須の機能は何ですか？」
- レイアウト／構成
- 「主な部分をどのように配置またはグループ化すべきですか？」
- データの保存場所／ホスティングの希望
- 「データはローカルに保存しますか、セルフホスト可能にしますか、Cloudflare／AWS／その他のクラウドに保存しますか、それとも未定ですか？」
- 対象プラットフォーム
- 「Web のみを対象にしますか？ それとも、Windows アプリ、Mac アプリ、クロスプラットフォームのデスクトップアプリ、モバイルアプリ、レスポンシブ対応のモバイル Web も対象にしますか？」
- 推奨する技術的なデフォルト案
- 「このアイデアに基づき、次の技術的なデフォルト案をおすすめします：<短い技術スタックの概要>。この案を採用しますか？ それとも一部を変更しますか？」
- 好み／雰囲気
- 「シンプル、遊び心がある、真面目、速い、落ち着いた雰囲気など、どのような印象にしたいですか？」
- 対象外のこと
- 「これは何をしないべきですか？」
- 成功の基準
- 「このアイデアを次の段階に進めてもよいと判断する基準は何ですか？」
インタビュー形式
次のようなプロンプトを使います。
- 「その部分について、もう少し詳しく教えてください。」
- 「その次はどうなりますか？」
- 「例を挙げてもらえますか？」
- 「それは必須ですか、それともあればよいものですか？」
- 「シンプルなものにしたいですか、それとも機能を充実させたいですか？」
ユーザーが迷っている場合は、自由回答を迫るのではなく、気軽に選べる選択肢を提示します。
- 「リストアプリ、概要ページ、それとも単一の目的に集中するツールに近いものにしたいですか？」
- 「ユーザーにはすべてを一度に見せますか、それともセクションを一つずつ進めてもらいますか？」
停止条件
ユーザーが次のいずれかを言った場合は、インタビューを終了してすぐに下書きを作成します。
- stop
- that's enough
- enough for now
- done
- draft it
- write it up
- GREENLIGHT NEXT STAGE
出力形式
下書きを作成する際は、次の構成で Markdown のメモを作成します。
# <Idea Title>
## One-line summary
## Problem / purpose
## Product philosophy
## Target user
## Core concept
## Desired behavior
## Key features
## Layout / information architecture
## UX / product notes
## Technical shape
## Data / integrations / platform needs
## Hosting / data location
## Platform targets
## Recommended technical defaults
## Non-goals
## Open questions
## Next steps
マスターインデックスの形式
Ideas Index.md は、アイデアのメモをシンプルな箇条書きでまとめます。
# Ideas Index
- [[Idea Title]] — short one-line summary
- [[Another Idea]] — short one-line summary
インデックスファイルが存在する場合は、順序（アルファベット順または新しい順）を一貫させたうえで、新しいアイデアを追加します。
推奨される応答方法
インタビュー中：
- 親しみやすく、簡潔に話します。
- 質問を一つして、ユーザーの回答を待ちます。
- プロダクトやデザインについての検討に焦点を絞ります。
ユーザーが終了を伝えたとき：
- アイデアを明確に要約します。
- 不確定な点は 未解決の質問 にまとめます。
- メモをローカルに保存します。
- ローカルのインデックスを追加・更新します。
- ローカルに保存したメモのパスをユーザーに伝えます。
品質基準
良い結果は、後からアイデアを振り返ったときに、次の点をすぐに理解できるものです。
- 何を実現するものか
- 誰を対象としているか
- どのように動作するべきか
- 何を最も重視するか
- 意図的に対象外としているものは何か