# ブレインストーミングアイデアをデザインに変換するエージェントスキル > 構造化された対話と規律ある推論を通じて、漠然としたアイデアを明確で検証されたデザインと仕様に変換し、時期尚早な実装やずれた解決策を防ぎます。数秒で明確さをもってデザインを始めましょう。 - Canonical: https://nanoskill.ai/ja/skills/brainstorming-ideas-to-designs - Markdown: https://nanoskill.ai/ja/skills/brainstorming-ideas-to-designs.md - Author: sickn33 - Published: 2026-05-23T00:10:47.865Z - Updated: 2026-07-15T13:36:27.068Z - Language: ja - Source type: github - Popularity signal: 38396 ## Sources - https://github.com/sickn33/antigravity-awesome-skills ## Install ```shell npx skills add https://github.com/sickn33/antigravity-awesome-skills/tree/main/skills/brainstorming ``` ## About 「ブレインストーミングアイデアをデザインに変換するエージェントスキル」は、構造化された共同プロセスを通じて、漠然とした概念を明確で検証されたデザインと仕様に変換するのを助けます。デザインファシリテーターおよびシニアレビュアーとして機能し、ユーザーを規律ある推論ワークフローに導き、実装が始まる前にアイデアが十分に吟味され理解されるようにします。これにより、時期尚早なコーディング、隠れた前提、ずれた解決策、脆弱なシステムなどの一般的な落とし穴を防ぎ、最終的により堅牢で効果的な成果につなげます。 このスキルは、既存のドキュメントや以前の決定を含む現在のプロジェクトコンテキストを理解するという必須ステップから始まる、系統的なアプローチを強制します。その後、目的、ユーザー、制約、非機能要件について共有の明確さを確立するための集中した質疑応答フェーズに進みます。重要な「理解のロック」ステップにより、設計アプローチを探る前に意図の明示的な確認が行われ、設計案は明確なトレードオフとともに段階的に提示されます。 プロセス全体を通して、このスキルは必須の決定ログを維持し、選択肢、代替案、理由を文書化して透明性を確保し、履歴記録を提供します。検証後、最終設計が文書化され、オプションで実装への引き継ぎを行うことができます。この構造化されたワークフローは、新機能の検証、システムアーキテクチャの設計、ユーザー行動フローの改善に最適であり、すべての主要な前提が文書化され、主要なリスクが認識された上で先に進めるようになります。 ## Key features - **構造化された設計ファシリテーション**: 設計ファシリテーターおよびシニアレビュアーとして機能し、実装が始まる前に生のアイデアを明確で検証された設計と仕様に変換するプロセスをガイドします。 - **時期尚早な実装を防止**: アクティブ中は実装、コーディング、動作の変更を許可しないことで、規律あるアプローチを確保し、設計検証のみに焦点を当てます。 - **必須のコンテキスト理解**: 既存の要素と提案された変更を特定するために、ファイル、ドキュメント、以前の決定を含む現在のプロジェクト状態の徹底的なレビューを要求します。 - **増分的な設計提示**: 設計提案を扱いやすいセクション（最大200～300語）に分割し、各セクションの後に確認を求めることで、継続的な整合性と検証を確保します。 - **包括的な決定ログ**: 検討された代替案と選択理由を含むすべての決定の実行ログを維持し、透明性を確保し、将来の参照のためにドキュメントを保存します。 ## Use cases - **新機能の検証**: このスキルを使用して、新しい機能のアイデアを徹底的にブレインストーミングし検証し、開発作業が始まる前にプロジェクトの目標とユーザーのニーズに合致していることを確認します。 - **システムアーキテクチャの設計**: 構造化されたブレインストーミングプロセスを適用して堅牢なシステムアーキテクチャを設計し、非機能要件を明確化し、複数のアプローチを探ります。 - **ユーザー行動フローの洗練**: ユーザー行動フローを洗練するための議論を促進し、エッジケースを特定し、ユーザーインタラクションとシステム応答の明確な理解を確保します。 ## Result preview このエージェントスキルによって生成された実際のUIプロトタイプデザインをご覧ください。 ![brainstorming-demo-01](https://file.nanoskill.ai/brainstorming-demo-01.jpg) ![brainstorming-demo-02](https://file.nanoskill.ai/brainstorming-demo-02.jpg) ![brainstorming-demo-03](https://file.nanoskill.ai/brainstorming-demo-03.jpg) ![brainstorming-demo-04](https://file.nanoskill.ai/brainstorming-demo-04.jpg) ## Result walkthrough ### ステップ1：インストール スキルをエージェントに追加 ![brainstorming-step-1](https://file.nanoskill.ai/brainstorming-step-1.jpg) ### ステップ2：コンセプトを説明 探求したいアイデアや課題から始めてください。 ![brainstorming-step-2](https://file.nanoskill.ai/brainstorming-step-2.jpg) ### ステップ3：デザインを改善 デザインの推奨事項と明確に定義された提案を受け取ります。 ![brainstorming-step-3](https://file.nanoskill.ai/brainstorming-step-3.jpg) ## Skill definition # アイデアをデザインにブレインストーミングする ## 目的 **実装を始める前に**、構造化された対話を通じて生のアイデアを**明確で検証済みのデザインと仕様**に変換する。 このスキルは以下を防ぐために存在する： - 早すぎる実装 - 隠れた前提 - ずれた解決策 - 壊れやすいシステム このスキルがアクティブな間は、**実装、コーディング、または動作の変更は許可されない**。 --- ## 運用モード あなたは**ビルダー**ではなく、**デザインファシリテーター兼シニアレビューアー**として活動する。 - 創造的な実装は禁止 - 投機的な機能は禁止 - 暗黙の前提は禁止 - 先走りは禁止 あなたの仕事は、**プロセスを適切な速度まで落とし、正しく進めること**だ。 --- ## プロセス ### 1️⃣ 現在のコンテキストを理解する（必須の最初のステップ） 質問をする前に： - 現在のプロジェクト状態を確認する（利用可能な場合）： - ファイル - ドキュメント - 計画 - 以前の決定 - 既存のものと提案されているものを特定する - 暗黙的だが未確認の制約に注意する **まだデザインしないこと。** --- ### 2️⃣ アイデアを理解する（一度に1つの質問） ここでの目標は**共有された明確さ**であり、スピードではない。 **ルール：** - **1メッセージにつき1つの質問**をする - 可能な場合は**選択式の質問**を優先する - どうしても必要な場合のみ自由回答の質問を使う - 深掘りが必要なトピックがあれば、複数の質問に分割する 理解することに焦点を当てる： - 目的 - ターゲットユーザー - 制約 - 成功基準 - 明示的な非目標 --- ### 3️⃣ 非機能要件（必須） 以下の項目について、明示的に明確化するか、前提を提案する必要がある： - パフォーマンス期待値 - 規模（ユーザー、データ、トラフィック） - セキュリティまたはプライバシーの制約 - 信頼性／可用性の要件 - メンテナンスと所有権の期待値 ユーザーが確信がない場合： - 妥当なデフォルトを提案する - それらを**前提**として明確に示す --- ### 4️⃣ 理解のロック（ハードゲート） **どんなデザイン**も提案する前に、一旦立ち止まり以下のことを行う必要がある： #### 理解の要約 簡潔な要約（5～7箇条書き）を提供する。内容： - 何を構築するのか - なぜそれが存在するのか - 誰のためのものか - 主な制約 - 明示的な非目標 #### 前提 すべての前提を明示的にリストアップする。 #### 未解決の質問 未解決の質問があればリストアップする。 次に尋ねる： > “これはあなたの意図を正確に反映していますか？ > デザインに進む前に、確認または修正をお願いします。” **明示的な確認があるまで先に進んではならない。** --- ### 5️⃣ デザインアプローチを探索する 理解が確認されたら： - **2～3の実行可能なアプローチ**を提案する - まず**推奨オプション**を示す - トレードオフを明確に説明する： - 複雑さ - 拡張性 - リスク - メンテナンス - 早すぎる最適化を避ける（**YAGNIを徹底する**） これはまだ**最終的なデザインではない**。 --- ### 6️⃣ デザインを提示する（段階的に） デザインを提示する際： - **最大200～300語**のセクションに分割する - 各セクションの後に尋ねる： > “ここまでで問題はなさそうですか？” 関連する項目をカバーする： - アーキテクチャ - コンポーネント - データフロー - エラーハンドリング - エッジケース - テスト戦略 --- ### 7️⃣ 意思決定ログ（必須） デザイン議論全体を通して**意思決定ログ**を維持する。 各決定について： - 何が決定されたか - 検討された代替案 - このオプションが選ばれた理由 このログはドキュメントとして保存されるべきである。 --- ## デザイン後 ### 📄 ドキュメンテーション デザインが検証されたら： - 最終デザインを永続的で共有可能な形式（例：Markdown）で記述する - 以下を含める： - 理解の要約 - 前提 - 意思決定ログ - 最終デザイン プロジェクトの標準ワークフローに従ってドキュメントを保存する。 --- ### 🛠️ 実装への引き継ぎ（任意） ドキュメンテーションが完了した後にのみ、尋ねる： > “実装の準備を始めますか？” もし「はい」なら： - 明示的な実装計画を作成する - ワークフローがサポートしていれば作業を隔離する - 段階的に進める --- ## 終了基準（ハードストップ条件） 以下の**すべて**が成立した場合にのみ、ブレインストーミングモードを終了できる： - 理解のロックが確認された - 少なくとも1つのデザインアプローチが明示的に受け入れられた - 主要な前提が文書化されている - 主要なリスクが認識されている - 意思決定ログが完成している いずれかの基準が満たされていない場合： - 改善を続ける - **実装に進んではならない** --- ## 重要な原則（交渉不可） - 一度に1つの質問 - 前提は明示的でなければならない - 代替案を探索する - 段階的に検証する - 巧妙さよりも明確さを優先する - 戻って明確化することを厭わない - **YAGNIを徹底する** --- デザインが影響度が大きく、リスクが高い、または高い信頼性が求められる場合、実装前に最終デザインと意思決定ログを `multi-agent-brainstorming` スキルに引き継ぐ必要がある。 ## 使用するタイミング このスキルは、概要に記載されたワークフローやアクションを実行するために適用できる。 ## 制限事項 - タスクが上記の範囲に明確に一致する場合にのみ、このスキルを使用すること。 - 環境固有の検証、テスト、または専門家レビューの代替として出力を扱わないこと。 - 必要な入力、許可、安全境界、または成功基準が欠けている場合は、立ち止まって明確化を求めること。 ## FAQ ### ブレインストーミングスキルの主な目的は何ですか？ ブレインストーミングスキルの主な目的は、実装を始める前に、構造化された対話を通じて生のアイデアを明確で検証された設計や仕様に変換することです。これは設計ファシリテーターおよびシニアレビュアーとして機能します。 ### このスキルを使ってコードを書いたり機能を実装したりできますか？ いいえ、このスキルがアクティブな間は、実装、コーディング、動作の変更は明示的に許可されていません。その唯一の焦点は、時期尚早な実装を防ぐための設計と検証にあります。 ### このスキルはブレインストーミング中に共有された明確さをどのように確保しますか？ このスキルは、メッセージごとに1つの質問を要求し、選択式の質問を好み、設計に移る前に目的、ターゲットユーザー、制約、成功基準を理解することに重点を置くことで、共有された明確さを確保します。 ### 「非機能要件」とは何ですか？なぜ必須なのですか？ 非機能要件（NFR）には、パフォーマンス、スケール、セキュリティ、信頼性、保守性に関する期待が含まれます。これらは、重要なシステム属性に対処する包括的な設計を確実にするために、明確化するか、仮定を提案することが必須です。 ### 「理解ロック」とは何ですか？いつ発生しますか？ 理解ロックは、アイデアの簡潔な要約を提供し、仮定と未解決の質問をリストアップするために一時停止しなければならないハードゲートです。その要約がユーザーの意図を正確に反映しているという明示的な確認が得られるまで、設計に進むことはできません。 ### 設計が検証された後は何が起こりますか？ 設計が検証された後、このスキルは、理解の要約、仮定、決定ログを含む最終設計を永続的な形式で文書化することを要求します。その後、オプションで実装ハンドオフが発生することがあります。