idea-superpowers-suite

Idea Superpowers Suite

このスキルは、アイデア開発のための Superpowers 風の包括的なワークフローです。

以下の各段階を連携させます。

• プロダクトやデザインの検討には idea-to-design-doc
• Full モードでの任意の UI 方針や画像生成コンセプトには idea-to-ui-design-brief
• 実装にすぐ取りかかれる計画の作成には idea-to-implementation-doc

単発のプロンプトではなく、再利用可能なシステムのような、より大規模な複数段階のワークフローをユーザーが求めている場合に、このスキルを使用します。

目的

大まかなアイデアを、体系化された一連の成果物にまとめます。

1. アイデアの記録 — ユーザーの大まかなコンセプトをもとに、ローカルのアイデアメモを作成または更新します。
2. 明確化のためのヒアリング — 大まかな計画、理念、目指す体験、制約を記録します。
3. デザインドキュメント — アイデアを掘り下げ、プロダクト、UX、技術に関する包括的なデザインドキュメントを作成します。
4. 任意の UI デザインブリーフ — Full モードのみ。画面、レイアウト、ビジュアル方針、状態、任意の画像生成コンセプト用プロンプトを定義します。
5. リサーチ — 類似するプロダクトを比較し、参考にする点や避ける点を特定します。
6. 実装仕様 — デザインを実践的な開発戦略に落とし込みます。
7. ビルドへの引き継ぎ — タスク、プロンプト、テスト、受け入れ基準、Superpowers への引き継ぎ方法を含む Markdown ファイルを 1 つ作成します。
8. 仕様レビュー — 実行に進める状態かどうかを判断します。

デザイン理念

このワークフローでは、以下を実現します。

• 素早く記録する。
• 深く掘り下げて明確化する。
• 開発前にリサーチする。
• プロダクトの検討とエンジニアリングの検討を分ける。
• UI の品質が重要な場合は、UI の方針と実装の詳細を分ける。
• 各段階をそれぞれ独立した Markdown 成果物として保存する。
• ユーザーがスピードを求める場合に、各段階を省略でき、柔軟に対応できるようにする。

UI ブリーフは任意です。インターフェースが中心となるプロジェクトの品質向上に役立ちますが、Lite モードを複雑にしたり、既存のデザインドキュメントから実装ドキュメントへの流れを妨げたりしてはいけません。

モードの選択

ユーザーが明示的に選択していない限り、開始時に 2 つのモードから選びます。

• Lite モード — スケッチ、小規模なユーティリティ、初期段階のアイデア、すばやく記録したいアイデア向けです。
• Full モード — 後に AI コーディングエージェントや Superpowers が開発する可能性のある、本格的なアプリやプロダクトのアイデア向けです。

アイデアが曖昧または探索段階の場合は、Lite モードをデフォルトにします。ユーザーがプロダクト仕様、実装計画、ビルドへの引き継ぎ、リサーチ、UI やモックアップの方針、エージェント向けの成果物を求めている場合は、Full モードをデフォルトにします。

デフォルトのファイル構成

まずローカルの Markdown ファイルを使用します。ユーザーが後から Obsidian へのエクスポートを希望した場合は、別の手順として扱います。

Lite モードの構成

ideas/<idea-slug>.md
ideas/index.md

必要に応じて、リクエストがあった場合のみ：

ideas/<idea-slug>.implementation.md
ideas/<idea-slug>.build-prompt.md
ideas/<idea-slug>.ui-brief.md

UI 段階を含む Full モードの構成

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-ui-design-brief.md
  03-implementation-spec.md
  04-agent-build-handoff.md
  05-spec-review.md

UI 段階を省略する場合の Full モードの代替構成

UI 段階を省略する場合は、従来のシンプルな番号付けを維持します。

ideas/<idea-slug>/
  README.md
  00-idea-capture.md
  01-design-doc.md
  02-implementation-spec.md
  03-agent-build-handoff.md
  04-spec-review.md

パッケージですでに確立されている番号付けを使用してください。README の成果物一覧との一貫性を保ってください。

ワークフローの段階

段階 1：記録

ユーザーがアイデアを持っていると伝えたら、以下を含む作業メモを作成します。

• タイトル
• 短い要約
• 大まかな問題提起
• 初期の箇条書き
• モード：Lite または Full

必要に応じて名前を尋ねますが、仮のタイトルを付けて先に進み、後から調整することを優先します。

ステージ 2：インタビュー

一度に一つずつ質問します。より効果的な質問をするには、references/interview-question-bank.md を使用します。

Lite モードでは、アイデアを明確に捉えるのに必要なことだけを質問し、その後、草案を作成します。

Full モードでは、以下を網羅します：

• 対象ユーザーと課題；
• アプリに期待する機能；
• 望ましい動作とプロダクト体験；
• 対象範囲と対象外；
• 主な画面やセクション；
• 一目で確認できるようにする情報；
• ユーザーが操作する場所；
• 必要になるまで表示しなくてよい詳細；
• 望ましいビジュアルの方向性：ミニマル、遊び心のあるもの、プロフェッショナル、情報密度の高いもの、ダッシュボード風、落ち着いたもの、コマンドセンター風など；
• 必要に応じて、空、読み込み中、エラー、成功、初回起動、権限の各状態；
• データ、連携、プラットフォーム上の制約；
• データの保存場所とホスティングの希望；
• 対象プラットフォーム：Web、デスクトップ、モバイル Web、iOS、Android など；
• 構成：単一アプリか、デスクトップアプリ＋ホスト型 Web アプリ＋API＋ワーカーなどの複数要素か；
• 認証、シークレット、API キー、公開／非公開の共有、クライアント／サーバーの境界；
• 単に機能するだけでなく、素晴らしいと感じられるために必要なこと。

ユーザーが技術的な制約を明示していない限り、早い段階で技術スタックの決定を促さないでください。技術的な計画を始める際は、まず実用的なデフォルトを提案し、その後、ユーザーが受け入れるか変更するかを確認します。

ステージ 3：設計ドキュメント

プロダクトの方向性と、計画を立てるのに十分な技術的概要をまとめた 01-design-doc.md を作成します。

推奨セクション：

• 一行の要約；
• 課題／目的；
• プロダクトの理念；
• 対象ユーザー；
• 中核となるコンセプト；
• 望ましい動作；
• 主な機能；
• レイアウト／情報設計；
• UX に関する注記；
• 技術的な概要；
• データ／連携／プラットフォームの要件；
• ホスティング／データの保存場所／デプロイの希望；
• 対象プラットフォーム；
• 推奨する技術的なデフォルトと、受け入れた／変更した決定事項；
• 対象外；
• 未解決の質問；
• 次のステップ。

ステージ 4：任意の UI デザインブリーフ

このステージは、デフォルトでは Full モードのみです。ユーザーが UI、モックアップ、画像生成、またはビジュアルデザインの方向性を明示的に求めない限り、Lite モードには追加しないでください。

このステージを実施する際は、idea-to-ui-design-brief を読み込みます。

インターフェースの品質が重要な場合は、02-ui-design-brief.md を作成します。以下を定義します：

• UI の目的；
• プロダクトの雰囲気とデザイン原則；
• 主要な画面／サーフェス；
• 画面ごとの注記；
• レイアウトと情報設計；
• コンポーネント一覧；
• 主要なユーザーフロー；
• デザインする状態：空、読み込み中、エラー、成功、初回起動、権限；
• ビジュアルの方向性；
• アクセシビリティとレスポンシブ対応；
• コンテンツ／文言に関する注記；
• 任意の画像生成コンセプト；
• 選択した方向性；
• 実装への引き継ぎに関する注記。

任意の画像生成パス

画像生成はコンセプトの検討であり、実装の正式な情報源ではありません。

以下の場合に使用します：

• ユーザーが UI の案を求めている；
• ビジュアルの好みが曖昧；
• ダッシュボード／アプリ／ランディングページについて、コードを書く前にビジュアルを検討する必要がある；
• 2～3 種類の方向性を比較すると役立つ。

デフォルトのコンセプト：

1. 保守的 — 見慣れていてリスクが低く、実装しやすいもの。
2. 高適合 — プロダクトブリーフを最も適切に解釈したもの。
3. 変化球 — より独自性があり、好みを探るのに役立つもの。

画像生成が利用できない、またはスキップされた場合は、プロンプトを記述し、テキストのみで続行します。画像を生成した場合は、ビジョン機能または手動レビューを使用し、画像を文章による要件、コンポーネントに関する注記、受け入れ基準に落とし込みます。Superpowers に画像をそのまま模倣させないでください。

ステージ 5：調査

具体的なアイデアに関連する類似プロダクトを調べ、以下を記録します：

• すでに存在するもの；
• 一般的なもの／コモディティ化しているもの；
• 異なる点；
• 避けるべきこと；
• アイデアがどこに位置づけられるか。

実用的な範囲に留め、対象を絞ってください。調査は仕様を強化するためのものであり、終わりのない市場レポートにするものではありません。

ステージ 6：実装の検討

UI ブリーフがある場合は 03-implementation-spec.md に、ない場合は 02-implementation-spec.md にアイデアを落とし込みます。

以下を含めます。

• 主要なシステム構成要素；
• データ要件；
• 推奨するデータベース／ストレージの選択とその理由；
• ホスティング／デプロイ先；
• 対象プラットフォームの決定事項；
• アプリの構成に関する決定事項；
• UI ブリーフがある場合は、フロントエンドの構成と UI デザインブリーフへの準拠方法；
• バックエンド／サービスの要件；
• 推奨する技術スタックのデフォルト；
• セキュリティ／シークレットのモデル；
• 統合ポイント；
• ワークフロー／マイルストーン；
• リスクとトレードオフ；
• 実行可能なビルドタスク；
• テストと検証の計画；
• 受け入れ基準／完了の定義；
• 開発者または AI コーディングエージェントが実行できるビルド手順。

技術的な選択には「推奨してから確認する」方法を使います。

1. プロダクトの制約から妥当なデフォルトを推測します。
2. 簡潔な推奨事項の表を提示します。
3. 項目を受け入れるか、変更するかをユーザーに尋ねます。
4. 受け入れられたデフォルトと明示的な変更を記録します。
5. 判断に迷う場合は、デフォルトを前提として進めます。

ステージ 7：最終エージェント向けビルド引き継ぎ

templates/idea-package-readme-template.md を使って README.md を作成または更新します。

最終的な引き継ぎファイルを次のように作成します。

• UI ブリーフがある場合は 04-agent-build-handoff.md；
• UI ブリーフを省略した場合は 03-agent-build-handoff.md。

引き継ぎを作成する際は、正式な引き継ぎテンプレートがそこにあるため、idea-to-implementation-doc を読み込みます。

引き継ぎには以下を含めます。

• ミッション；
• プロダクトビジョン；
• 妥協できない要件；
• UI／デザインの方向性、または明示的な UI に関する前提；
• 対象外の項目；
• 技術アーキテクチャ；
• 実装フェーズ；
• ビルドタスク；
• テスト要件；
• 検証コマンド／チェック項目；
• 受け入れ基準；
• 完了の定義チェックリスト；
• ビルドエージェント向けプロンプト；
• Superpowers への明示的な引き継ぎ指示。

ステージ 8：仕様レビュー／準備状況の判定

以下を作成します。

• UI ブリーフがある場合は 05-spec-review.md；
• UI ブリーフを省略した場合は 04-spec-review.md。

以下を確認します。

• プロダクトの目標は明確か；
• UI／デザインの期待事項は、新しいエージェントがありきたりな成果物を避けられる程度に明確か；
• 要件はテスト可能か；
• 未解決のプロダクト上の決定事項は残っているか；
• 未解決の技術的な決定事項は残っているか；
• 受け入れ基準は具体的か；
• 完了の定義は明確か；
• 新しいエージェントは、明らかな質問をせずにこのファイルから構築できるか；
• テストと検証の要件は含まれているか；
• 非目標によってスコープの拡大を防げるか。

判定：

• PASS — Superpowers に渡せる状態です。
• PASS WITH CHANGES — ほぼ準備できています。先に記載された問題を修正してください。
• FAIL — 曖昧すぎるか、不完全です。

ステージ 9：レビュー／計画レビュー

ユーザーが批評を希望する場合は、成果物を個別にレビューします。

• デザインドキュメントはプロダクトに焦点を当てている；
• UI ブリーフには、不要なコードを指定することなく、具体的な画面／スタイル／状態の指針が示されている；
• 実装ドキュメントはビルドに焦点を当てている；
• 最終的な引き継ぎはエージェントがすぐに使える状態になっている；
• 仕様レビューでは不足点が正直に示されている；
• パッケージの概要が、各ドキュメントの内容をすべて重複していない。

進行ルールとオーバーライドフレーズ

Lite モードのルール

• すばやく要点をまとめます。調査、UI ブリーフ、実装計画を無理に行いません。
• ユーザーが追加を希望しない限り、下書きの前に確認する質問は最大 3～5 個までにします。
• ユーザーが Full モードに切り替えるか、UI／モックアップの方向性を具体的に依頼しない限り、02-ui-design-brief.md、実装仕様書、ビルド引き継ぎ、仕様レビューは作成しません。
• ユーザーがそのアイデアはメモにすぎないと言った場合は、メモのままにします。

Full モードのルール

• ターゲットユーザー、問題、主要な動作を十分に要約できるようになるまで、キャプチャから設計へ進まないでください。
• 未解決のプロダクトや UI に関する疑問によって、アーキテクチャ、MVP の範囲、または主要なインターフェースが変わる可能性がある場合は、設計から実装へ進まないでください。
• 実装フェーズ、テスト要件、受け入れ基準、完了の定義が揃うまで、最終的なビルド引き継ぎ資料を作成しないでください。
• 検証チェックが不足している、主要なプロダクトや技術上の決定が未解決である、またはインターフェースが中心となるアプリの UI に関する期待が曖昧すぎる場合は、仕様レビューを PASS にしないでください。
• UI のステージをスキップする場合は、作業を止めずに UI の前提を引き継いでください。

ユーザーによる上書きフレーズ

ユーザーは次の正確なフレーズを使って、先へ進むよう指示できます。

GREENLIGHT NEXT STAGE

ユーザーがこのフレーズを使ったら、次のステージへ進んでください。リスクを簡潔に伝え、未解決の項目を未解決の質問／前提のもとに記録してから続行します。ただし、安全でない操作や認証情報の露出は許可されません。

運用ルール

• ワークフローはモジュール式に保ってください。
• ステージごとに別のファイルを使用することを優先してください。
• 進捗は Markdown で保存してください。
• ユーザーがプロダクト、アーキテクチャ、または UI に関する決定を確認したら、作業中のアイデアメモを更新してください。
• 再利用可能なスキルの内容は公開しても安全なものにし、非公開のプロダクト計画や認証情報を含めないでください。
• ユーザーが「止めて」「もう十分」「今はこれで十分」「完了」「下書きを作って」「まとめて」と言ったら、質問をやめてすぐに草案を作成してください。
• ユーザーがより手軽な体験を望む場合は、Lite モードを使用してください。
• ステージがスキップされた場合は、前のワークフローを継続し、前提を記録してください。

特化型スキルとの関係

• ユーザーが設計ステージだけを希望する場合は、idea-to-design-doc を使用してください。
• ユーザーが UI の方向性、生成された UI コンセプト、画面ごとのモックアップに関するメモ、またはビルド後の UI 再設計を希望する場合は、idea-to-ui-design-brief を使用してください。
• ユーザーが実装計画だけを希望する場合は、idea-to-implementation-doc を使用してください。
• ユーザーがシステム全体を希望する場合は、idea-superpowers-suite を使用してください。

Superpowers との関係

アイデアワークフローは、プロダクト／仕様策定のフロントエンドパイプラインです。Superpowers は実行規律のパイプラインです。

想定される引き継ぎ：

1. idea-superpowers-suite がアイデアをまとめ、明確化のための質問をします。
2. idea-to-design-doc が設計／仕様書を作成します。
3. idea-to-ui-design-brief が必要に応じて、UI の方向性と画像生成用のコンセプトプロンプトを作成します。
4. idea-to-implementation-doc がビルド可能な状態の Markdown 引き継ぎ資料を作成します。
5. Superpowers が検証、計画、実装、テスト、レビュー、確認を行います。

アイデアワークフローは、Superpowers の実行を置き換えるのではなく、高品質な入力情報を作成する必要があります。

参考ファイル

• references/interview-question-bank.md — Lite および Full のインタビューで再利用できる質問集です。
• references/example-cli-tool-build-handoff.md — 小規模な開発者向け CLI ツール用の汎用的な最終引き継ぎ資料の例です。
• references/example-saas-web-app-build-handoff.md — 小規模な SaaS／Web アプリ用の汎用的な最終引き継ぎ資料の例です。
• references/example-automation-script-build-handoff.md — 実用的な自動化ワークフロー用の汎用的な最終引き継ぎ資料の例です。

テンプレート

• idea-to-implementation-doc/templates/agent-build-handoff-template.md — 最終的なエージェント／Superpowers ビルド引き継ぎ資料に必須の構成です。
• templates/idea-package-readme-template.md — Full モードのアイデアフォルダー用 README／ステータスインデックスです。

よくある落とし穴

1. UI ステージを必須にすること。デフォルトでは任意で、Full モードのみが対象です。
2. 生成画像を唯一の信頼できる情報源にすること。画像を文章による UI 要件に置き換えてください。
3. 既存パッケージの番号付けに一貫性がなくなるよう変更すること。既定の番号付けを維持し、README の一覧を更新してください。
4. Lite モードに詰め込みすぎること。ユーザーが UI または Full モードを求めない限り、Lite は手軽なままにしてください。
5. 汎用的で中身のない UI を作ること。プロダクトに固有の画面、状態、操作を使ってください。
6. 範囲に影響するプロダクトや UI の決定が明確になる前に、コードへ進むこと。

検証チェックリスト

• モードが正しく選択または推定されています。
• ライトモードは、明示的にアップグレードされない限り、軽量な状態に保たれています。
• フルモードの成果物はステージごとに分けられています。
• UI ブリーフは、有用またはリクエストされた場合にのみ存在し、そうでない場合は UI に関する前提が引き継がれています。
• 任意の画像生成プロンプトは、実装上の事実ではなくコンセプトとして扱われています。
• README の成果物一覧は、実際のファイル名と番号に一致しています。
• 最終引き継ぎには、UI の方針または明示的な UI に関する前提が含まれています。
• 仕様レビューでは、未解決のプロダクト、UI、技術上の課題が正直に報告されています。