アイデアから設計へは何をしますか？

自然な協調的対話を通じて、アイデアを完全に形成された設計と仕様に変換します。

まず現在のプロジェクトコンテキストを理解し、アイデアを洗練するために質問を一度に1つずつ行います。何を構築するのかを理解したら、設計を提示し、ユーザーの承認を得ます。

アンチパターン: 「これは設計が必要ないほど単純だ」

すべてのプロジェクトはこのプロセスを経ます。TODOリスト、単一機能のユーティリティ、設定変更 — すべてです。「単純な」プロジェクトこそ、暗黙の前提が最も多くの無駄な作業を引き起こします。設計は短くても（本当に単純なプロジェクトでは数文）かまいませんが、必ず提示し、承認を得なければなりません。

チェックリスト

以下の各項目に対してタスクを作成し、順番に完了する必要があります。

プロジェクトコンテキストの探索 — ファイル、ドキュメント、最近のコミットを確認する
質問を明確にする — 一度に1つずつ、目的/制約/成功基準を理解する
2～3のアプローチを提案する — トレードオフと推奨事項を含める
設計を提示する — 複雑さに応じてセクションの規模を調整し、各セクションごとにユーザーの承認を得る
設計ドキュメントを作成する — docs/superpowers/specs/YYYY-MM-DD-<トピック>-design.mdに保存し、コミットする
仕様の自己レビュー — プレースホルダー、矛盾、曖昧さ、スコープをインラインで素早く確認する
ユーザーが作成済み仕様をレビュー — 次に進む前に、ユーザーに仕様ファイルのレビューを依頼する
実装への移行 — writing-plansスキルを呼び出して実装計画を作成する

プロセスフロー

flowchart TD
    A[プロジェクトコンテキストの探索] --> B[質問を明確にする]
    B --> C[2～3のアプローチを提案]
    C --> D[設計セクションの提示]
    D --> E{ユーザーが設計を承認?}
    E -- no, 修正 --> D
    E -- yes --> F[設計ドキュメントを作成]
    F --> G[仕様の自己レビュー<br/>インライン修正]
    G --> H{ユーザーが仕様をレビュー?}
    H -- 変更要求 --> F
    H -- 承認 --> I[writing-plansスキルを呼び出し]

最終状態はwriting-plansの呼び出しです。 いかなる実装スキルも呼び出さないでください。この後に呼び出す唯一のスキルはwriting-plansです。

プロセス

アイデアの理解:

まず現在のプロジェクト状態を確認する（ファイル、ドキュメント、最近のコミット）
詳細な質問をする前に、スコープを評価する：リクエストが複数の独立したサブシステムを説明している場合（例：「チャット、ファイルストレージ、課金、分析機能を持つプラットフォームを構築する」）、すぐにそれを指摘する。最初に分解する必要があるプロジェクトの詳細を洗練するために質問に時間を費やしてはいけない。
プロジェクトが単一の仕様に対して大きすぎる場合は、ユーザーがサブプロジェクトに分解するのを支援する：独立した部分は何か、それらはどのように関連するか、どの順序で構築すべきか？その後、最初のサブプロジェクトを通常のフローで設計する。各サブプロジェクトは、独自の仕様→計画→実装サイクルを取得する。
適切にスコープされたプロジェクトの場合、アイデアを洗練するために一度に1つの質問をする
可能な場合は選択式の質問を優先するが、自由記述でも構わない
メッセージごとに質問は1つだけ — トピックをさらに探求する必要がある場合は、複数の質問に分割する
理解に集中する：目的、制約、成功基準

アプローチの探索:

トレードオフを含む2～3の異なるアプローチを提案する
会話形式でオプションを提示し、推奨事項とその理由を示す
推奨するオプションを最初に提示し、その理由を説明する

設計の提示:

何を構築するのか理解できたと思ったら、設計を提示する
各セクションの規模を複雑さに応じて調整する：単純なら数文、ニュアンスがあるなら最大200～300語
各セクションの後で、これまでのところ正しいかどうかを尋ねる
カバーする内容：アーキテクチャ、コンポーネント、データフロー、エラーハンドリング、テスト
何かが理解できない場合は、戻って明確にする準備をする

分離と明確さのための設計:

システムを、それぞれが1つの明確な目的を持ち、明確に定義されたインターフェースを介して通信し、独立して理解およびテストできる、より小さな単位に分割する
各単位について、何をするのか、どのように使用するのか、何に依存しているのかを答えられるようにする
内部を読まなくても単位が何をするかを理解できるか？内部を変更しても消費者を壊さないか？そうでなければ、境界を見直す必要がある。
より小さく、適切に境界が定義された単位は、あなたにとっても扱いやすい。一度にコンテキストに保持できるコードについてより適切に推論でき、ファイルが焦点を絞っている場合、編集の信頼性が向上する。ファイルが大きくなりすぎた場合、それは多くの場合、そのファイルがやりすぎているシグナルである。

既存のコードベースでの作業:

変更を提案する前に、現在の構造を探索する。既存のパターンに従う。
既存のコードに作業に影響を与える問題がある場合（例：大きくなりすぎたファイル、不明確な境界、もつれた責任）、設計の一部として対象を絞った改善を含める — 優れた開発者が作業するコードを改善する方法と同様に。
無関係なリファクタリングを提案しない。現在の目標に役立つことに集中し続ける。

設計後

ドキュメント:

検証済みの設計（仕様）を docs/superpowers/specs/YYYY-MM-DD-<トピック>-design.md に書き込む
- （仕様の保存場所に関するユーザー設定がある場合は、このデフォルトを上書きする）
設計ドキュメントをgitにコミットする

仕様の自己レビュー: 仕様ドキュメントを作成した後、新鮮な目でそれを見直す。

プレースホルダースキャン: 「TBD」、「TODO」、不完全なセクション、または曖昧な要件はないか？修正する。
内部一貫性: セクション間で矛盾はないか？アーキテクチャは機能の説明と一致しているか？
スコープチェック: 単一の実装計画に十分焦点が絞られているか、それとも分解が必要か？
曖昧さチェック: 要件が2つの異なる方法で解釈される可能性はないか？もしあれば、1つを選んで明示的にする。

問題があればインラインで修正する。再レビューの必要はない — 修正して次に進む。

ユーザーレビューゲート: 仕様レビューループが通過した後、次に進む前にユーザーに作成済みの仕様をレビューしてもらう。

「仕様を作成し、<パス>にコミットしました。実装計画の作成を開始する前に、変更したい点があればレビューしてお知らせください。」

ユーザーの応答を待つ。変更が要求された場合、それらを加えて仕様レビューループを再実行する。ユーザーが承認した場合のみ次に進む。

実装:

writing-plansスキルを呼び出して、詳細な実装計画を作成する
他のスキルは呼び出さない。writing-plansが次のステップである。

主要原則

一度に1つの質問 — 複数の質問で圧倒しない
選択式を優先 — 可能な場合、自由記述よりも答えやすい
YAGNIを厳格に — すべての設計から不要な機能を削除する
代替案を探索 — 決定する前に常に2～3のアプローチを提案する
段階的な検証 — 設計を提示し、次に進む前に承認を得る
柔軟に対応 — 何かが理解できない場合は戻って明確にする

アップストリームスキルから削除されたもの

元のbrainstormingスキル（obra/superpowers）には「ビジュアルコンパニオン」機能が含まれていました：ブレインストーミング中にブラウザタブでモックアップを表示するためのNode.jsブラウザサーバー（scripts/server.cjs、scripts/start-server.sh、scripts/stop-server.sh）。SkillSpectorは、stop-server.shでのツールパラメータ悪用のためにスキルをブロックしました。

この移植版はビジュアルコンパニオンを完全に削除しています。コアとなる方法論（協調的設計対話、ハードゲート、仕様の自己レビュー、ユーザーレビューゲート、writing-plansへの移行）は、スクリプト、シェル、外部サーバーを一切使用しない純粋なプロセスガイダンスです。構造上、安全です。

設計の会話中にモックアップや図を表示する必要がある場合は、バンドルされたサーバーの代わりに、エージェントのネイティブツール（ブラウザMCPツール、画像生成、またはチャット内のインラインMermaid/ASCII図）を使用してください。

アイデアから設計へ