対話的機能ブレーンストーミング

ユーザーを粗いアイデアから well-formed な機能リクエストへ、対話、調査、コードベースの理解を通じてガイドします。自律的に提案を生成する /pm-explore（やクリアな説明を受け取ってエンティティを作成する /pm-plan と異なり、このスキルはメッシーな初期段階向けです。ユーザーは何かが改善できることを知っていますが、「改善」が何に見えるかをまだ結晶化していない段階です。

コアループ: 質問 → 調査 → グラウンディング → 精密化 → 作成。

ステップ 0: 引数を解析してコンテキストを設定

ブレーンストーミングのトピックについて $ARGUMENTS を解析します。これは以下のようなものがあります:

• 特定の領域: 「ダッシュボード UX」「通知」「レポーティング」
• 問題ステートメント: 「ワークパッケージ全体で進捗を追跡するのが難しい」
• ユーザーセグメント: 「新規ユーザー向けの機能」「管理者ワークフロー」
• あいまいな方向性: 「何が足りないか」「どうすればいいか」
• 空白(引数なし)——それでいい。ステップ 1 でトピックを発見します。

ステップ 1: 対話を開く

温かく、探索的な質問で始めます。ユーザーのメンタルモデルを理解することが目標です。ユーザーが何を気にしているのか、何が不満なのか、どのような機会を見ているのかを理解します。まだソリューションに飛び込まないでください。

引数が提供された場合、トピックを認識してフォーカス質問を尋ねます:

AskUserQuestion を使用:

• Question: トピックに基づいて、可能性を閉じずにスコープを絞る質問をしてください。例:
  • 「ダッシュボード UX」の場合: 「ダッシュボードを使うときに最も不満な部分は何ですか。情報を見つけること、ステータスを理解すること、それとも何か他の問題ですか?」
  • 「通知」の場合: 「通知について考えるとき、自分向けのアラート(ステータス変更、ブロッカー)を想定していますか、それともチーム全体を同期させるためですか?」
  • あいまいなトピックの場合: 「何がこれを促しましたか? 最近『これはもっと簡単であるべき』または『〜ができたらいいのに』と思う瞬間がありましたか?」
• Header: 「Direction」
• Options: 異なる方向を表す 2-3 のオプション、および常に「Other」を通じたフリーフォーム回答を許可

引数がない場合、AskUserQuestion を使用してトピックを発見します:

• Question: 「プロジェクトのどの領域についてブレーンストーミングしたいですか?」
• Header: 「Topic」
• Options: プロジェクトのクイックスキャンに基づいて 3-4 のオプションを生成(例:エンティティタイプ、既存機能、または注目される隙間に基づいて)。常にユーザー向けの関心事として表現され、技術的な内部ではなく。

ステップ 2: プロジェクトを解決してコンテキストをロード

対話に従事しながら、必要なプロジェクトコンテキストを集約します:

• 現在のディレクトリ: !pwd
• projectPath をディレクトリの上に設定して mcp__pinkrooster__get_project_status を呼び出す
• projectId を抽出

並行して、既存アイテムをロードして既に追跡されているものを理解します:

1. projectId と stateFilter: "Active" で mcp__pinkrooster__get_feature_requests を呼び出す
2. projectId と stateFilter: "Inactive" で mcp__pinkrooster__get_feature_requests を呼び出す
3. projectId と stateFilter: "Active" で mcp__pinkrooster__get_issue_overview を呼び出す
4. projectId と stateFilter: "Inactive" で mcp__pinkrooster__get_issue_overview を呼び出す

心の中で重複排除リストをコンパイルします。これを全体を通じて使用して、既に追跡されているものを提案しないようにします。

ステップ 3: 問題領域を調査

ユーザーの初期方向に基づいて、2 つのことを並行して行います:

3a: ウェブ調査

WebSearch を使用して、より広い問題領域を理解します。外部的な視点を取り入れることが目標です。他の製品は何をしていますか? 確立されたパターンは何ですか? 同様のツールのユーザーは通常何を望んでいますか?

調査クエリはユーザーの関心領域をターゲットにする必要があります:

• 「ダッシュボード UX」を探索している場合: プロジェクト管理ダッシュボードのベストプラクティス、一般的なダッシュボードウィジェット、情報アーキテクチャパターンを検索します
• 「通知」を探索している場合: 通知システム設計パターン、アラート疲れ研究、通知設定 UX を検索します
• 特定の統合を探索している場合: その統合の API、一般的なユースケース、既存の実装を検索します

調査から 3-5 の主要な洞察を合成します。これらはまだ提案ではなく、ブレーンストーミング対話に知見をもたらす視点です。

3b: コードベース分析

Glob、Grep、Read を使用して、議論されている領域の現在の状態を理解します。以下に焦点を当てます:

• この領域に今日何が存在しますか?(ページ、コンポーネント、API エンドポイント、エンティティ)
• 新機能に力を与える可能性のあるデータは何ですか?
• 活用できるパターン/インフラストラクチャは何ですか?
• 現在の制限または隙間は何ですか?

コードベース分析は、ブレーンストーミングを現実にグラウンドします。すべてのアイデアは、既存のアーキテクチャがサポートできるか、合理的に拡張してサポートできるものである必要があります。

ステップ 4: ブレーンストーミングループ(2-3 ラウンド)

これはスキルの中核です。ガイド付きの対話の 2-3 ラウンドを実施し、それぞれが前のものに基づいています。目標は段階的な精密化です: 広範 → フォーカス → 具体的。

ラウンド 1: 可能性を拡張

調査とコード分析から学んだことを共有し、提案ではなく挑発として形作ります。AskUserQuestion を使用して探索します:

• Question: 調査から通知された 3-4 の方向を提示し、それぞれに外部のベストプラクティスまたは競合他社分析から引き出した簡潔な「これがなぜ重要か」説明が含まれます。それらを提案ではなく質問として形作ります:
  • 「他のプロジェクト管理ツールではユーザーがカスタムダッシュボードビューを設定できます。ここで同じようなものが役立つでしょうか?」
  • 「アクティビティログが多くのデータをキャプチャしていることに気付きましたが、トレンドを視覚化する方法がありません。これを探索する価値があるでしょうか?」
  • 「研究によると、ステータス通知を使用するチームは、ブロック済みアイテムの解決時間を 40% 削減しています。通知疲れはユーザーにとって懸念ですか?」
• Header: 「Explore」
• multiSelect: true(ユーザーは複数の方向に関心を持つことができます)

ラウンド 2: より深く、形を作る

ユーザーが選択したことと言ったことに基づいて、選択された方向を深く掘り下げます。ここで「どの領域か?」から「具体的に何か?」への移行が起こります。狭められたフォーカスに基づいて追加の標的型調査とコード分析を行う必要があります。

AskUserQuestion を使用して精密化します:

• Question: 選択された方向内で 2-3 のより具体的なバリエーションを提示します。実際のコードベースに基づいた具体的な例を含めます:
  • 「ダッシュボードカスタマイズの場合、2 つのアプローチがあります: (1) ユーザーが表示するカードを選択する構成可能なウィジェット、または (2) プロジェクトごとのセーブされたフィルタービュー。既存の TanStack Table インフラストラクチャはオプション 2 をより容易にサポートできます。どちらがより価値があると思いますか?」
• Header: 「Shape」
• Options: 詳細な説明による具体的で明確なオプション

ラウンド 3: 確認と詳細(オプション)

ラウンド 2 の後、アイデアが十分に明確であれば、これをスキップします。それ以外の場合は、もう 1 ラウンド使用して詳細を確定します:

AskUserQuestion を使用:

• Question: 出現する機能アイデアの簡潔な要約を提示し、何か欠けているか変更すべきかを尋ねます
• Header: 「Confirm」
• Options: [{label: "Looks good", description: "Ready to create feature requests"}, {label: "Adjust", description: "I want to change something"}, {label: "Add more", description: "I have additional ideas to include"}]

ブレーンストーミング対話のガイドライン:

• 指示するより聞きましょう。 ユーザーの自分の製品に対する本能は、一般的なベストプラクティスより価値があります。調査を使用してアイデアをきっかけにし、ユーザーの判断を上書きするのではなく。
• すべてをコードベースにグラウンドしてください。 「より良い分析」のようなあいまいなアイデアは、「activity_logs テーブルが既にリクエストデータをキャプチャしています。新しいデータ収集なしに応答時間トレンドを表示できます」と言えるときに具体的になります。
• 誠実にトレードオフに名前を付けてください。 アイデアが興奮的だが大きなワークが必要な場合は、そう言ってください。よりシンプルなバージョンが価値の 80% をキャプチャしていれば、それを提案してください。
• スコープの膨張を監視してください。 対話が 8 個以上の異なるアイデアを生成している場合は、優先順位付けをやさしく提案してください: 「これらはすべて興味深いですが、ユーザーにとって今最もインパクトのある 2-3 つはどれですか?」
• 既存アイテムを相互参照してください。 アイデアが既存の FR または問題と重複している場合は、言及してください: 「これは proj-1-fr-3 に関連しています。新しく作成する代わりにそれを拡張すべきですか?」

ステップ 5: 機能リクエストを合成

ブレーンストーミングラウンドの後、対話を具体的な FR 候補に合成します。出現した各アイデアについて:

1. Name: {Feature}: {brief qualifier} パターンに従う説明的なタイトル
2. Description: 以下を組み込んだ包括的なスペック:
   • 機能が何をするか(ブレーンストーミング対話から)
   • それがなぜ重要か(ユーザーの入力 + 調査結果から)
   • 既存機能とどのようにフィットするか(コードベース分析から)
   • 主要なインタラクションまたはワークフロー手順
   • 明示的なスコープ外アイテム(議論されたが延期されたもの)
3. Category: Feature、Enhancement、または Improvement
4. Priority: 対話から推測。ユーザーが最も興奮していたことがより高い優先度を得る
5. Business Value: ユーザーの「なぜ」+調査による支持から合成
6. User Stories: 対話から導出された 2-4 の具体的なストーリー
7. Acceptance Summary: テスト可能な 4-6 の基準

合成された FR をテーブルで提示します:

## ブレーンストーム結果 — {N} 個の機能リクエスト

| # | Name | Category | Priority | Business Value |
|---|------|----------|----------|----------------|
| 1 | {name} | {category} | {priority} | {one-line value} |
| ... |

### Details

**1. {name}**
- Category: {category} | Priority: {priority}
- Description: {2-3 sentence summary}
- Business Value: {why it matters}
- User Stories:
  - As a {role}, I want {goal}, so that {benefit}
- Acceptance Criteria:
  - {criterion 1}
  - {criterion 2}
- Research backing: {key insight from web research that supports this}

**2. {name}**
...

AskUserQuestion を使用して確認します:

• Question: 「ここにブレーンストーミングからの機能リクエストがあります。どれを作成しますか?」
• Header: 「Create FRs」
• multiSelect: true
• Options: FR ごとに 1 つ(最大 4 つ)、「All」と「None」のオプション

ステップ 6: 機能リクエストを作成

選択された各 FR について、以下を含む mcp__pinkrooster__create_or_update_feature_request を呼び出します:

• projectId
• name: 合成から
• description: 合成から完全な説明
• category: マップされたカテゴリ
• priority: マップされた優先度
• businessValue: 合成から
• acceptanceSummary: 合成から
• userStories: [{"role": "...", "goal": "...", "benefit": "..."}] の配列
• requester: 「pm-brainstorm」

各作成の前に、重複排除リストを確認します。既存の FR と重複が存在する場合、AskUserQuestion を使用して、既存アイテムを更新するか新しいアイテムを作成するか尋ねます。

ステップ 7: レポートと次のステップ

## ブレーンストームから {count} 個の機能リクエストを作成しました

| # | FR ID | Name | Priority |
|---|-------|------|----------|
| 1 | {frId} | {name} | {priority} |
| ... |

### 適用された調査インサイト
- {FR に影響を与えた主要な検出 1}
- {主要な検出 2}

### 次のステップ
- 詳細を精密化: `/pm-refine-fr {frId}`
- 実装を計画: `/pm-scaffold {frId}`
- ブレーンストーミング続行: `/pm-brainstorm {different-topic}`
- プロジェクトステータスを表示: `/pm-status`

フォローアップに AskUserQuestion を使用します:

• Question: 「次に何をしたいですか?」
• Header: 「Next step」
• Options: 作成されたものに基づいて。最初の FR をスキャフォルド、FR を精密化、別の領域をブレーンストーミング、または完了

制約

• ブレーンストーミング対話は自然に感じるべきで、フォームを埋めるようではなく。初期段階ではオープンエンドの質問を使用し、後段階では構造化されたオプションを使用します。
• すべての機能アイデアはコードベース現実にグラウンドされる必要があります。アーキテクチャがサポートできないことを提案しないでください。隙間に注目する場合を除きます。
• ウェブ調査は対話に知見をもたらすべきで、それを支配しないこと。ラウンドごとに 1-2 の主要な洞察を共有し、調査の全ダンプではなく。
• 常に既存の FR/問題/WP を相互参照して重複を避けます。
• 作成された FR は Proposed として開始します。自動状態伝播がありません。
• ブレーンストーミングループを 2-3 ラウンドに保ちます。ユーザーが続けたい場合、それでいいですが、アイデアが既に明確なときに余分なラウンドを強制しないこと。
• ユーザーストーリーは会話に結びついた具体的であり、「As a user, I want this feature, so that I can use it」のような一般的なテンプレートではなく。
• 関連する場合、FR の説明にウェブ調査ソースを含めて、将来の実装者がコンテキストを持つようにします。
• ブレーンストーミングが機能ではなくバグまたは問題を明らかにした場合、それに注目して提案します: 「これはより問題のように聞こえます。代わりに /pm-plan でそれを作成したいですか?」
• 1 回のブレーンストーミングセッションあたり最大 5 つの FR。対話がそれ以上を生成する場合、優先順位付けして残りを後続セッションに延期することを提案します。