create-technical-spike

テクニカルスパイクドキュメントの作成

開発を進める前に答える必要がある重要な疑問を調査するための、タイムボックス化されたテクニカルスパイクドキュメントを作成します。各スパイクは、明確な成果物とタイムラインを伴う特定の技術的決定に焦点を当てます。

ドキュメント構造

${input:FolderPath|docs/spikes} ディレクトリに個別のファイルを作成します。各ファイルには [category]-[short-description]-spike.md というパターンで名前を付けます（例: api-copilot-integration-spike.md、performance-realtime-audio-spike.md）。

---
title: "${input:SpikeTitle}"
category: "${input:Category|Technical}"
status: "🔴 Not Started"
priority: "${input:Priority|High}"
timebox: "${input:Timebox|1 week}"
created: [YYYY-MM-DD]
updated: [YYYY-MM-DD]
owner: "${input:Owner}"
tags: ["technical-spike", "${input:Category|technical}", "research"]
---

# ${input:SpikeTitle}

## Summary

**Spike Objective:** [Clear, specific question or decision that needs resolution]

**Why This Matters:** [Impact on development/architecture decisions]

**Timebox:** [How much time allocated to this spike]

**Decision Deadline:** [When this must be resolved to avoid blocking development]

## Research Question(s)

**Primary Question:** [Main technical question that needs answering]

**Secondary Questions:**

- [Related question 1]
- [Related question 2]
- [Related question 3]

## Investigation Plan

### Research Tasks

- [ ] [Specific research task 1]
- [ ] [Specific research task 2]
- [ ] [Specific research task 3]
- [ ] [Create proof of concept/prototype]
- [ ] [Document findings and recommendations]

### Success Criteria

**This spike is complete when:**

- [ ] [Specific criteria 1]
- [ ] [Specific criteria 2]
- [ ] [Clear recommendation documented]
- [ ] [Proof of concept completed (if applicable)]

## Technical Context

**Related Components:** [List system components affected by this decision]

**Dependencies:** [What other spikes or decisions depend on resolving this]

**Constraints:** [Known limitations or requirements that affect the solution]

## Research Findings

### Investigation Results

[Document research findings, test results, and evidence gathered]

### Prototype/Testing Notes

[Results from any prototypes, spikes, or technical experiments]

### External Resources

- [Link to relevant documentation]
- [Link to API references]
- [Link to community discussions]
- [Link to examples/tutorials]

## Decision

### Recommendation

[Clear recommendation based on research findings]

### Rationale

[Why this approach was chosen over alternatives]

### Implementation Notes

[Key considerations for implementation]

### Follow-up Actions

- [ ] [Action item 1]
- [ ] [Action item 2]
- [ ] [Update architecture documents]
- [ ] [Create implementation tasks]

## Status History

| Date   | Status         | Notes                      |
| ------ | -------------- | -------------------------- |
| [Date] | 🔴 Not Started | Spike created and scoped   |
| [Date] | 🟡 In Progress | Research commenced         |
| [Date] | 🟢 Complete    | [Resolution summary]       |

---

_Last updated: [Date] by [Name]_

テクニカルスパイクのカテゴリ

API 統合

• サードパーティ API の機能と制限
• 統合パターンと認証
• レート制限とパフォーマンス特性

アーキテクチャと設計

• システムアーキテクチャの決定
• デザインパターンの適用可否
• コンポーネント間の連携モデル

パフォーマンスとスケーラビリティ

• パフォーマンス要件と制約
• スケーラビリティのボトルネックと解決策
• リソース使用率のパターン

プラットフォームとインフラストラクチャ

• プラットフォームの機能と制限
• インフラストラクチャの要件
• デプロイとホスティングの考慮事項

セキュリティとコンプライアンス

• セキュリティ要件と実装
• コンプライアンス上の制約
• 認証と認可のアプローチ

ユーザーエクスペリエンス

• ユーザー操作のパターン
• アクセシビリティ要件
• インターフェース設計の決定

ファイル命名規則

カテゴリと具体的な未解決事項を示す、説明的なケバブケースの名前を使用します。

API／統合の例:

• api-copilot-chat-integration-spike.md
• api-azure-speech-realtime-spike.md
• api-vscode-extension-capabilities-spike.md

パフォーマンスの例:

• performance-audio-processing-latency-spike.md
• performance-extension-host-limitations-spike.md
• performance-webrtc-reliability-spike.md

アーキテクチャの例:

• architecture-voice-pipeline-design-spike.md
• architecture-state-management-spike.md
• architecture-error-handling-strategy-spike.md

AI エージェント向けのベストプラクティス

1. スパイクごとに 1 つの疑問: 各ドキュメントは 1 つの技術的決定または調査課題に焦点を当てます

2. タイムボックス化された調査: 各スパイクに具体的な制限時間と成果物を定義します

3. 証拠に基づく決定: 完了とマークする前に、具体的な証拠（テスト、プロトタイプ、ドキュメント）を必須とします

4. 明確な推奨事項: 実装に向けた具体的な推奨事項とその根拠を記載します

5. 依存関係の追跡: スパイク同士の関係やプロジェクトの決定への影響を特定します

6. 成果重視: すべてのスパイクは、実行可能な決定または推奨事項に結実しなければなりません

調査戦略

フェーズ 1: 情報収集

1. search/fetch ツールを使用して既存のドキュメントを検索する
2. コードベースを分析して既存のパターンと制約を把握する
3. 外部リソース（API、ライブラリ、例）を調査する

フェーズ 2: 検証とテスト

1. 特定の仮説を検証するための焦点を絞ったプロトタイプを作成する
2. 前提を検証するための的を絞った実験を実行する
3. 裏付けとなる証拠とともにテスト結果を記録する

フェーズ 3: 決定とドキュメント化

1. 調査結果を統合して明確な推奨事項にする
2. 開発チーム向けの実装ガイダンスを記載する
3. 実装に向けたフォローアップタスクを作成する

ツールの使用

• search/searchResults: 既存のソリューションとドキュメントを調査する
• fetch/githubRepo: 外部の API、ライブラリ、例を分析する
• codebase: 既存システムの制約とパターンを理解する
• runTasks: プロトタイプと検証テストを実行する
• editFiles: 調査の進捗と結果を更新する
• vscodeAPI: VS Code 拡張機能の機能と制限をテストする

重要な技術的決定を解決し、開発の進行を妨げる要因を取り除く、タイムボックス化された調査に焦点を当てます。