| name | stack-consultation |
| description | 動的リサーチを活用した新プロジェクト向けのインタラクティブな技術スタックコンサルテーション。以下の場合に使用:
- 既存コードベースのない新規プロジェクトの開始
- ユーザーが使用すべき技術スタックを把握していない場合
- 現在のベストプラクティスに基づく推奨が必要な場合
- 最新情報で技術オプションをリサーチ・比較する必要がある場合
- ユーザーが「どのスタックを使うべきか」「選択を手伝って」と言った場合
Trigger phrases: stack consultation, recommend stack, what technology, choose tools, new project stack, tech advice, help me decide
|
| allowed-tools | AskUserQuestion, WebSearch, WebFetch, Read, Write, Bash, Glob, Grep, Task, TodoWrite |
| model | sonnet |
| user-invocable | true |
スタックコンサルテーション
要件ベースのインタビューと WebSearch/WebFetch を活用した動的リサーチを通じて、ユーザーが技術スタックを選択しセットアップするのを支援するインタラクティブなコンサルテーション。
設計原則
- テクノロジーをハードコードしない: 記憶から特定のフレームワークを名指しで推奨しない。常に WebSearch で現在の選択肢を検索する。
- 要件優先: ソリューションをリサーチする前にユーザーのニーズを理解する。
- ドメイン非依存: あらゆるプロジェクトタイプ（Web、モバイル、組込み、ゲーム、データ、デスクトップ、CLI など）をサポート。
- 動的発見: RAG（WebSearch + WebFetch）を使用して現在の技術ランドスケープを収集する。
- 透明なトレードオフ: 仮定ではなくリサーチに基づいた長所・短所を提示する。
ワークフローフェーズ
Phase 1: Requirements Discovery → ユーザーのニーズを理解（カテゴリーではなく）
Phase 2: Constraint Mapping → 制約と好みを特定
Phase 3: Dynamic Research (RAG) → 現在のソリューションを検索
Phase 4: Analysis & Comparison → 要件に対するオプション評価
Phase 5: Collaborative Decision → 調査結果の提示と共同意思決定
Phase 6: Scaffolding → 決定したスタックのセットアップ
Phase 1: 要件発見
目標: ユーザーのニーズを、技術カテゴリーではなくシステムが何をすべきかの観点で理解する。
1.1 コア目的
Question: "構築しようとしているものの主な目的は何ですか？"
Header: "Purpose"
（自由テキスト回答 - 選択肢で制約しない）
ユーザーの回答が曖昧な場合、以下の明確化質問を行う:
- 「誰が、または何がこのシステムを使いますか？」
- 「どのような問題を解決しますか？」
- 「成功とはどのような状態ですか？」
1.2 インタラクションモデル
Question: "ユーザー/システムはこれとどのようにインタラクションしますか？"
Header: "Interaction"
Options:
- "ビジュアルインターフェース経由（画面、グラフィックス）"
- "テキスト/音声コマンド経由"
- "他のソフトウェア経由（API/メッセージ）"
- "物理世界（センサー、アクチュエーター、ハードウェア）"
- "直接的なインタラクションなし（バックグラウンド/バッチ処理）"
1.3 データ特性
Question: "どのような種類のデータを扱いますか？"
Header: "Data"
MultiSelect: true
Options:
- "構造化レコード（ユーザー、注文、在庫）"
- "非構造化コンテンツ（テキスト、ドキュメント、メディア）"
- "リアルタイムストリーム（イベント、センサー、ログ）"
- "バッチ処理が必要な大規模データセット"
1.4 通信パターン
Question: "どのような通信パターンが必要ですか？"
Header: "Comms"
MultiSelect: true
Options:
- "リクエスト-レスポンス（ユーザーが問い合わせ、システムが応答）"
- "リアルタイム双方向（チャット、コラボレーション）"
- "プッシュ通知（アラート、更新）"
- "オフライン対応（ネットワークなしでも動作）"
1.5 デプロイ環境
Question: "これはどこで実行されますか？"
Header: "Deploy"
Options:
- "ユーザーのデバイス（スマートフォン、デスクトップ、ブラウザ）"
- "クラウドサーバー"
- "エッジ/組込みデバイス"
- "ハイブリッド（複数環境）"
- "まだわからない"
Phase 2: 制約マッピング
目標: 技術選択に影響する実務上の制約を特定する。
2.1 チームスキル
Question: "チームが使いこなせるプログラミング言語は何ですか？（あれば）"
Header: "Languages"
（自由テキスト - 選択肢を制約しない）
2.2 既存システム
Question: "統合が必要な既存システムはありますか？"
Header: "Integration"
Options:
- "はい、特定のプラットフォーム/API（後述）"
- "組織の標準に従う必要がある"
- "制約なし、新規プロジェクト"
2.3 リソース制約
Question: "主な制約は何ですか？"
Header: "Constraints"
MultiSelect: true
Options:
- "予算が限られている（無料/低コストのオプションを優先）"
- "タイトなスケジュール（慣れた実績のあるツールを優先）"
- "少人数チーム（シンプルなスタックを優先）"
- "規制/コンプライアンス要件あり"
2.4 スケール予想
Question: "どの程度のスケールを想定していますか？"
Header: "Scale"
Options:
- "個人/小規模チーム利用（100 ユーザー未満）"
- "部門/組織（100-10,000）"
- "パブリックサービス（10,000 以上）"
- "不明/可変"
Phase 3: 動的リサーチ（RAG）
目標: WebSearch と WebFetch を使用して、収集した要件に基づく現在の技術オプションを発見する。
3.1 検索クエリの構築
要件を検索クエリに変換する。記憶から特定のテクノロジー名を検索しない。
クエリ構築パターン
| 要件 | 検索クエリテンプレート |
|---|
| ビジュアルインターフェース + ブラウザ | "best frontend frameworks [year] comparison" |
| API バックエンド | "backend frameworks [year] [language if specified] production" |
| リアルタイム通信 | "real-time communication tools [year] comparison" |
| データストレージ | "database comparison [year] [data type]" |
| デプロイ | "deployment platforms [year] [constraint]" |
年にはシステム時刻を使用（例: CURRENT_YEAR=$(date +%Y)）、モデルの記憶は使わない。
当年の結果が少ない場合（例: 年初）、前年と年なしの「latest/recent」バリアントを追加してクエリを広げる。
クエリ生成例
ユーザーのニーズ: ビジュアルインターフェース、構造化データ、リアルタイム更新、クラウドデプロイ、チームが Python を知っている
CURRENT_YEAR=$(date +%Y)
PREV_YEAR=$((CURRENT_YEAR - 1))
実行するクエリ:
1. "best frontend frameworks ${CURRENT_YEAR} comparison production"
2. "Python backend frameworks ${CURRENT_YEAR} real-time support"
3. "database for real-time applications ${CURRENT_YEAR}"
4. "cloud deployment platforms ${CURRENT_YEAR} Python applications"
フォールバック（結果が少ない場合）:
- "best frontend frameworks ${PREV_YEAR} comparison production"
- "Python backend frameworks ${PREV_YEAR} real-time support"
- "database for real-time applications ${PREV_YEAR}"
- "cloud deployment platforms ${PREV_YEAR} Python applications"
- "best frontend frameworks latest comparison production"
- "Python backend frameworks recent real-time support"
- "database for real-time applications recent comparison"
- "cloud deployment platforms recent Python applications"
3.2 リサーチの実行
必要な各技術カテゴリーについて:
- 構築したクエリで WebSearch を実行
- 検索結果から上位候補を特定（通常 3-5 件）
- 各候補について信頼できるソースを WebFetch で取得:
- 公式ドキュメント（現在のバージョン、機能）
- 最近の比較記事（1 年以内）
- 本番環境の使用レポート
3.3 情報の抽出
各候補テクノロジーについて以下を抽出:
| 属性 | 確認事項 |
|---|
| 現在のバージョン | 最新の安定版リリース |
| 主な用途 | 設計目的 |
| 強み | 文書化されたメリット |
| 弱み | 既知の制限事項 |
| 学習コスト | 新規ユーザーにとっての複雑さ |
| コミュニティの健全性 | 活動状況、サポートの利用可能性 |
| ライセンス/コスト | オープンソースか？料金モデルは？ |
3.4 リサーチ出力
調査結果を構造化されたフォーマットにまとめる:
## リサーチ結果: [カテゴリー]
### 発見した候補
| 名前 | バージョン | 最適な用途 | ライセンス |
|------|-----------|-----------|-----------|
| [A] | [ver] | [用途] | [lic] |
| [B] | [ver] | [用途] | [lic] |
| [C] | [ver] | [用途] | [lic] |
### 詳細分析
#### [候補 A]
- **強み**: [リサーチ結果より]
- **弱み**: [リサーチ結果より]
- **要件との適合性**: [分析]
### 出典
- [タイトル] (日付) - [url]
Phase 4: 分析と比較
目標: 発見したオプションをユーザーの具体的な要件に対して評価する。
4.1 評価フレームワーク
各候補を評価軸に対してスコアリング:
| 軸 | 質問 | 重み |
|---|
| 要件適合性 | 述べられた問題を解決するか？ | 高 |
| 制約との互換性 | チームスキル、予算、スケジュールに合うか？ | 高 |
| 統合性 | 他の選択したコンポーネントと連携するか？ | 中 |
| 成熟度 | 本番環境対応？アクティブなメンテナンス？ | 中 |
| エコシステム | ライブラリ、ツール、ドキュメントの品質？ | 中 |
| 将来性 | 長期的な実現可能性、移行パス？ | 低 |
4.2 トレードオフマトリクス
上位候補について、明示的なトレードオフ比較を作成:
## トレードオフ分析
| 側面 | [オプション A] | [オプション B] | [オプション C] |
|------|--------------|--------------|--------------|
| 要件 1 | 強い | 部分的 | 弱い |
| 要件 2 | 部分的 | 強い | 強い |
| チームスキルの適合 | 強い | 弱い | 部分的 |
| 学習コスト | 低 | 高 | 中 |
| コミュニティ活動 | 高 | 中 | 成長中 |
4.3 推奨の策定
分析に基づいて推奨を策定:
## 推奨
### 第一候補: [テクノロジー]
**理由**: [ユーザーの要件に結びついた具体的な理由]
### 代替案: [テクノロジー]
**検討条件**: [こちらが良い条件]
### 非推奨: [テクノロジー]
**理由**: [要件との具体的な不一致]
Phase 5: 協調的意思決定
目標: 調査結果を提示し、ユーザーと一緒に意思決定する。
5.1 調査結果の提示
ユーザーに以下を示す:
- 要件のサマリー
- 使用したリサーチ方法
- 発見した候補
- トレードオフ分析
- 理由付きの推奨
5.2 意思決定ポイント
Question: "このリサーチに基づいて、どのように進めたいですか？"
Header: "Decision"
Options:
- "推奨案で良さそうです。進めましょう"
- "[特定のテクノロジー]をもっと詳しく調べたい"
- "別のアプローチをリサーチしてもらえますか？"
- "要件を再検討したい"
5.3 必要に応じて反復
ユーザーがさらなるリサーチを望む場合:
- 特定のトピックについて追加の WebSearch を実施
- 特定のテクノロジーについて WebFetch で深掘り
- 要件が変わった場合は再検討
5.4 最終確認
スキャフォールディング前に、完全なスタックを確認:
## 最終スタック決定
| レイヤー | 選択 | 根拠 |
|---------|------|------|
| [レイヤー 1] | [テクノロジー] | [理由] |
| [レイヤー 2] | [テクノロジー] | [理由] |
プロジェクトセットアップに進みますか？
Phase 6: スキャフォールディング
目標: 決定したテクノロジーでプロジェクトをセットアップする。
6.1 セットアップコマンドのリサーチ
記憶からセットアップコマンドを仮定しない。 WebSearch/WebFetch を使用して現在の公式セットアップ手順を調べる:
WebSearch: "[technology name] getting started official documentation [year]"
WebFetch: [official docs URL] → "Extract installation and project setup commands"
6.2 セットアップの実行
公式ドキュメントに記載されたセットアップコマンドを実行する。
6.3 セットアップ後
- バージョン管理の初期化（git init, .gitignore）
- CLAUDE.md の作成: 以下を文書化:
- 根拠付きの決定スタック
- 使用したセットアップコマンド
- 主要なアーキテクチャ決定
- セットアップの検証: 基本コマンドの実行（ビルド、テスト）
6.4 引き継ぎ
## プロジェクトセットアップ完了
### スタック
[バージョン付きテクノロジーのリスト]
### 使用したセットアップコマンド
[実行されたコマンド]
### 次のステップ
- [スタックに基づく最初の推奨アクション]
- [2 番目の推奨アクション]
### 作成されたドキュメント
- CLAUDE.md - 今後のセッション用プロジェクトコンテキスト
- README.md - 人間が読めるプロジェクトドキュメント
Rules (L1 - Hard)
正確で最新の推奨を提供するために不可欠。
- NEVER: リサーチせずにテクノロジーを名指しで推奨しない
- NEVER: トレーニングデータからテクノロジーの機能を仮定しない - 常に WebFetch で検証
- NEVER: Phase 1 でテクノロジー固有の質問をしない（要件が先）
- ALWAYS: スキャフォールディング前に意思決定を確認する（ユーザーの承認が必須）
Defaults (L2 - Soft)
品質の高いコンサルテーションに重要。適切な理由がある場合はオーバーライド可。
- WebSearch を使用して現在のオプションを発見する
- 仮定ではなくリサーチに基づいたトレードオフを提示する
- 公式ドキュメントからセットアップコマンドを確認する
- プロジェクトセットアップ後に CLAUDE.md を作成する
Guidelines (L3)
効果的なスタックコンサルテーションのための推奨事項。
- consider: 各技術カテゴリーに 3-5 件の候補を提示することを検討
- prefer: 複雑な意思決定にはトレードオフマトリクスの作成を推奨
- consider: テクノロジー評価において将来性を考慮
