製品ブートストラップスキル

目的: 最小限の製品ブリーフィングを、市場競争力があり技術的に健全なリサーチに基づいた豊富な製品管理成果物に変換します。

主な革新: ドメインエキスパートリサーチエージェントがヒアリング前に包括的なリサーチを実施し、ユーザーの負担を17個の質問から通常8〜12個に削減しながら、より高品質で検証された推奨事項を提供します。

プロセス概要

1. 製品ブリーフィングを受け入れる
   ↓
2. ドメインエキスパートリサーチを実施 (新規)
   ├─ Context7: 技術ドキュメント
   ├─ WebSearch: 市場/アーキテクチャ/セキュリティ
   ├─ WebFetch: 詳細リソース
   └─ Domain: 科学/業界リサーチ
   ↓
3. リサーチレポートを統合
   ↓
4. リサーチ情報に基づいた質問を実施 (17個の代わりに8〜12個)
   ↓
5. 理解を確認 (リサーチコンテキスト付き)
   ↓
6. リサーチ充実の成果物を生成 (4つのファイル)
   ↓
7. .context/ をリサーチサマリーで更新
   ↓
8. 引用付き完了サマリーを提供

ステップ1: ブリーフィングを受け入れて分析

入力: ユーザーからの製品ブリーフィング (最小限のものでも可 - 例: 「協調的なドキュメントエディターを構築」)

アクション:

• コアコンセプト、ドメイン、技術ヒントについてブリーフィングを解析
• リサーチキーワードを抽出: 製品タイプ、ドメイン、ユースケース、技術スタックの手掛かり
• リサーチで補完できる欠落情報を特定

例:

ユーザー: 「協調的なドキュメントエディターを構築」
→ リサーチキーワード: 「協調的編集」「ドキュメントエディター」「リアルタイムコラボレーション」
→ 技術領域: フロントエンドフレームワーク、WebSocketライブラリ、リッチテキストエディター
→ ドメイン領域: 市場規模、競合 (Google Docs、Notion)、アーキテクチャパターン

ステップ2: ドメインエキスパートリサーチを実施

重要: ヒアリング前にリサーチを実施して、より適切な質問と成果物の事前入力を可能にします。

2.1 技術ドキュメントリサーチ (Context7)

目的: ベストプラクティスと推奨技術を特定

プロセス:

1. ブリーフィングから3〜5個の関連技術候補を特定
2. 各技術について:

   resolve-library-id(
     query="[技術説明]",
     libraryName="[フレームワーク名]"
   ) → libraryId
   
   query-docs(
     libraryId="[返されたID]",
     query="[特定のユースケース] のベストプラクティス"
   ) → ドキュメント結果
   

3. ライブラリIDと使用されたクエリと共に結果をドキュメント化

制限: Context7クエリ最大3〜5個

2.2 アーキテクチャパターンリサーチ (WebSearch + WebFetch)

目的: このドメインの実証済みアーキテクチャパターンをリサーチ

プロセス:

1. アーキテクチャパターンでWebSearch (5〜8クエリ):
   • 「[ドメイン/ユースケース] アーキテクチャパターン 2026」
   • 「[ドメイン] スケーラビリティベストプラクティス 2026」
   • 「マイクロサービス vs モノリス [ユースケース] 2026」
2. 2〜3個のキーリソースをWebFetch:
   • アーキテクチャホワイトペーパー
   • 類似製品のケーススタディ
   • 実装ガイド

制限: WebSearch 5〜8クエリ、WebFetch 2〜3リソース

2.3 セキュリティ&コンプライアンスリサーチ (WebSearch + WebFetch)

目的: 規制要件とセキュリティベストプラクティスを特定

プロセス:

1. コンプライアンスでWebSearch (5〜8クエリ):
   • 「GDPR コンプライアンス [ドメイン] アプリケーション 2026」
   • 「HIPAA 要件 [ドメイン] 2026」
   • 「SOC2 コンプライアンス SaaSアプリケーション 2026」
   • 「OWASP top 10 [ドメイン] セキュリティ 2026」
2. 公式なコンプライアンスドキュメントをWebFetch

制限: コンプライアンス/セキュリティ検索 5〜8個

2.4 ドメイン知識リサーチ (WebSearch + WebFetch)

目的: 市場、競合、ドメイン固有のインサイトを理解

プロセス:

1. 市場インテリジェンスでWebSearch (8〜10クエリ):
   • 「[製品タイプ] 市場規模 2026」
   • 「[ドメイン] 業界トレンド 2026」
   • 「[ユースケース] 競争環境」
   • 「主要な競合 [製品タイプ]」
2. 2〜4個のリソースをWebFetch:
   • 市場調査レポート
   • 学術論文 (該当する場合)
   • 業界分析

制限: 市場/ドメイン検索 8〜10個、WebFetch 2〜4リソース

2.5 リサーチ統合

出力: 以下を含む構造化リサーチレポート:

## リサーチレポート

### 技術リサーチ (Context7)
- [ライブラリ 1]: [主要な結果]
- [ライブラリ 2]: [主要な結果]
- 推奨: [提案する技術スタック]

### アーキテクチャリサーチ
- パターン推奨: [例: MVP用モノリス、後々マイクロサービス]
- スケーラビリティアプローチ: [見つかったキーパターン]
- ケーススタディ: [類似製品]

### セキュリティ&コンプライアンス
- 必須標準: [GDPR、HIPAA、SOC2など]
- セキュリティ対策: [OWASPコンプライアンス、暗号化など]

### ドメイン知識
- 市場規模: [リサーチから得たTAM]
- 主要な競合: [強み/弱みと共にリスト]
- 業界トレンド: [関連するトレンド]

### リサーチギャップ (ユーザー入力が必要)
- [リサーチで答えられない質問 1]
- [ユーザーの好みが必要な質問 2]
- [検証が必要な質問 3]

ステップ3: リサーチ情報に基づいた質問

戦略:

• 質問をする前にリサーチレポートを確認
• リサーチが明確な答えを提供した質問はスキップ
• リサーチの結果を確認する検証質問をする
• リサーチが決定できないユーザーの好み、制約、目標に焦点を当てる
• 17個の質問から通常8〜12個に削減

質問カテゴリ (完全な質問フレームワークはコマンドファイルを参照):

1. 製品エッセンス (4問) - ドメインリサーチに基づく場合があります
2. 市場コンテキスト (4問) - 市場リサーチからデータがある場合があります
3. 技術的制約 (3問) - リサーチがコンプライアンス要件を特定
4. 実行コンテキスト (3問) - リサーチがタイムライン推定を情報提供
5. 製品スコープ (3問) - リサーチが必須機能を特定

例 (協調的ドキュメントエディター):

リサーチが発見したこと:
- 市場規模: 50億ドルのTAM
- 競合: Google Docs、Notion、Confluence
- 技術スタック: React + WebSocketが推奨
- コンプライアンス: EU顧客にはGDPR対応
- アーキテクチャ: Operational TransformまたはCRDTパターン

スキップされた質問:
✗ 「市場規模は?」 (リサーチが発見: 50億ドル)
✗ 「競合は誰か?」 (リサーチが3つの主要プレイヤーを特定)
✗ 「技術の好みは?」 (リサーチがReact + Socket.ioを提案)

質問された内容:
✓ 「GDPR対応が必要ですか?」 (リサーチ結果を検証)
✓ 「Google Docsとの差別化は?」 (ユーザービジョン)
✓ 「ターゲット規模は?」 (アーキテクチャ選択を情報提供)
✓ 「MVP タイムラインは?」 (ユーザー制約)
✓ 「チームサイズは?」 (ユーザー制約)

結果: 17個の一般的な質問の代わりに8個の的を絞った質問

ステップ4: 理解を確認

リサーチで強化された確認を提示:

製品についての理解を確認させてください:

**製品**: [名前/説明]
**コア問題**: [2〜3文]
**ターゲットユーザー**: [ユーザーペルソナ]
**市場コンテキスト**: [リサーチから得たサイズと競合]
**主要な差別化要因**: [ユニークな価値]
**技術アプローチ**: [Context7リサーチに基づくアーキテクチャ]
**コンプライアンス要件**: [リサーチで特定されたGDPR、HIPAA、SOC2]
**MVPタイムライン**: [タイムライン]
**成功指標**: [2〜4の指標]

**実施されたリサーチ**:
- 技術: [照会されたContext7ライブラリ]
- 市場: [主要な結果]
- セキュリティ: [特定された標準]
- ドメイン: [インサイト]

これは正しいですか? 確認するか、訂正を提供してください。

ステップ5: リサーチ充実の成果物を生成

生成順序 (依存関係駆動):

5.1 product.md (150〜250行)

• 市場調査引用を含む製品ビジョン
• リサーチから得た競争環境
• リサーチから得た業界ベンチマークを含む成功指標

5.2 roadmap.md (200〜250行)

• アーキテクチャリサーチに基づくフェーズ
• 技術リサーチに基づく現実的なタイムライン

5.3 architecture.md (200〜300行)

• Context7ドキュメントに基づく技術スタック
• リサーチから得たアーキテクチャパターン
• コンプライアンスリサーチから得たセキュリティ対策
• 豊富なContext7引用

5.4 adr.md (100〜150行)

• ADR-001: 技術スタック (Context7に基づく)
• ADR-002: アーキテクチャパターン (リサーチで検証)
• ADR-003: データベース選択 (比較リサーチ)
• ADR-004: セキュリティ&コンプライアンス (規制リサーチ)
• すべてのADRはリサーチ引用を含む

進捗インジケーター:

リサーチ充実の成果物を生成中...
✓ product.md を作成 (187行) - 市場調査付き
✓ roadmap.md を生成 (223行) - アーキテクチャリサーチ付き
✓ architecture.md を設計 (298行) - Context7参照付き
✓ adr.md をドキュメント化 (156行) - リサーチで根拠付けされた決定

ステップ6: .context/ を更新

notes.md (< 150行)

製品ブートストラップサマリーを追加:

• 製品概要
• 実施されたリサーチ セクション
• 主要なリサーチ結果
• リサーチソースサマリー
• キードキュメント参照

changelog.md (< 70行)

ブートストラップエントリを追加:

• 決定 (7つの主要な決定)
• 実施されたリサーチ セクション
• リサーチアノテーション付きで生成された成果物
• リサーチに基づく根拠

handoff.md

包括的なハンドオフを作成:

• 生成された製品成果物
• 収集された情報
• 実施されたリサーチ セクション (詳細)
• 重要な決定
• 次のステップ

ステップ7: サマリーを提供

サマリー形式:

## 製品ブートストラップ完了!

### 製品概要
- **名前**: [名前]
- **ビジョン**: [1文]
- **ターゲット**: [ユーザーセグメント]
- **MVPタイムライン**: [タイムライン]

### 生成された成果物
- product.md (X行) - 市場調査引用付き
- roadmap.md (X行) - アーキテクチャリサーチ付き
- architecture.md (X行) - Context7参照付き
- adr.md (X行) - リサーチに基づいた根拠を持つ4つのADR

### 実施されたリサーチ
**Context7**: [X] ライブラリドキュメント
**WebSearch**: [Y] 検索 (市場/アーキテクチャ/セキュリティ)
**WebFetch**: [Z] 詳細リソース

**インパクト**:
- 質問が17個から [実際の数] に削減
- すべての決定がリサーチに基づく
- 完全な引用トレーサビリティ

### 次のステップ
1. 成果物とリサーチ引用を確認
2. ドメイン専門知識に対して結果を検証
3. MVP開発計画を開始

重要なガイドライン

DO:

• ✅ ヒアリング前にリサーチを実施
• ✅ リサーチが確信を持って答えた質問はスキップ
• ✅ すべての成果物にリサーチ引用を含める
• ✅ すべての技術決定にContext7を使用
• ✅ 特定のライブラリID (/org/project形式) を引用
• ✅ .context/ ファイルを500行以下に保つ
• ✅ リサーチソースのサマリーを提供

DON'T:

• ❌ リサーチが一部の質問に答えている場合、17個すべての質問をしない
• ❌ Context7に基づかずに技術を推奨しない
• ❌ 時間を節約するためにリサーチフェーズをスキップ
• ❌ 成果物からリサーチ引用を省略
• ❌ リサーチクエリ制限を超える (トークンが膨張する)
• ❌ リサーチ検証なしで成果物を生成

リサーチクエリ制限 (重要):

• Context7: 最大3〜5ライブラリ
• WebSearch: カテゴリごと (市場、アーキテクチャ、セキュリティ) 5〜8個
• WebFetch: 最大2〜4個の詳細リソース
• これらを強制してトークン膨張とAPI過剰使用を防止

成功基準

実行後:

• ✅ 4つの包括的な製品ファイルが生成される (合計600〜1000行)
• ✅ すべての成果物にリサーチ引用が含まれる
• ✅ 技術決定がContext7ドキュメントに基づく
• ✅ アーキテクチャ決定が業界リサーチで検証される
• ✅ コンプライアンス要件がプロアクティブに特定される
• ✅ リサーチカバレッジに基づいて質問が8〜12個に削減
• ✅ .context/ ファイルがリサーチサマリーで更新される
• ✅ すべての .context/ ファイルが500行以下
• ✅ すべての推奨事項の完全な引用トレーサビリティ

テンプレート

注: このスキルは省略されたテンプレートを使用します。すべてのセクションと例を含む完全なテンプレートについては、以下を参照:

• .claude/commands/bootstrap-product.md (完全なコマンドファイル、約2000行)

完全なコマンドファイルには以下が含まれます:

• 詳細な質問フレームワーク (リサーチアノテーション付きのすべての17質問)
• 完全な成果物テンプレート (product.md、roadmap.md、architecture.md、adr.md)
• リサーチ統合の指示
• 実行例のフロー

---

コマンドバージョン: 明示的な呼び出しには、/bootstrap-product [ブリーフィング] を使用 スキルバージョン: このファイル - 製品計画会話の意味的トリガーで活性化