実装計画の作成

主要指令

あなたの目標は、${input:PlanPurpose} のための新しい実装計画ファイルを作成することです。出力は機械可読で、決定論的であり、他の AI システムまたは人間による自律実行のための構造化されている必要があります。

実行コンテキスト

このプロンプトは AI 間通信と自動処理のために設計されています。すべての指示は文字通りに解釈され、人間の解釈や説明なしに体系的に実行される必要があります。

コア要件

• AI エージェントまたは人間によって完全に実行可能な実装計画を生成する
• ゼロの曖昧性を伴う決定論的言語を使用する
• すべてのコンテンツを自動解析と実行のために構造化する
• 理解のための外部依存関係なしの完全な自己完結性を確保する

計画構造要件

計画は、実行可能なタスクを含む個別のアトミックなフェーズで構成される必要があります。各フェーズは、明示的に宣言されない限り、フェーズ間の依存関係なしに AI エージェントまたは人間によって独立して処理可能である必要があります。

フェーズアーキテクチャ

• 各フェーズは測定可能な完了基準を持つ必要があります
• フェーズ内のタスクは、依存関係が指定されない限り、並行して実行可能である必要があります
• すべてのタスク説明には、特定のファイルパス、関数名、および正確な実装の詳細を含める必要があります
• タスクは人間の解釈または意思決定を必要としない必要があります

AI 最適化実装標準

• 解釈が不要なゼロの曖昧性を伴う明示的で曖昧でない言語を使用する
• すべてのコンテンツを機械可読形式（テーブル、リスト、構造化データ）として構造化する
• 該当する場合、特定のファイルパス、行番号、および正確なコード参照を含める
• すべての変数、定数、および構成値を明示的に定義する
• 各タスク説明内で完全なコンテキストを提供する
• すべての識別子に標準化されたプレフィックス（REQ-、TASK-など）を使用する
• 自動的に検証できる検証基準を含める

出力ファイル仕様

• 実装計画ファイルを /plan/ ディレクトリに保存する
• 命名規則：[purpose]-[component]-[version].md
• Purpose プレフィックス：upgrade|refactor|feature|data|infrastructure|process|architecture|design
• 例：upgrade-system-command-4.md、feature-auth-module-1.md
• ファイルは適切なフロントマター構造を持つ有効な Markdown である必要があります

必須テンプレート構造

すべての実装計画は、以下のテンプレートに厳密に準拠する必要があります。各セクションは必須であり、具体的で実行可能なコンテンツで満たされる必要があります。AI エージェントは実行前にテンプレート準拠を検証する必要があります。

テンプレート検証ルール

• すべてのフロントマターフィールドが存在し、正しくフォーマットされている必要があります
• すべてのセクションヘッダーが完全に一致している必要があります（大文字小文字を区別）
• すべての識別子プレフィックスは指定された形式に従う必要があります
• テーブルはすべての必須列を含む必要があります
• プレースホルダーテキストは最終出力に残っていない必要があります

ステータス

実装計画のステータスはフロントマターで明確に定義される必要があり、計画の現在の状態を反映する必要があります。ステータスは以下の中の 1 つである必要があります（括弧内は status_color）：Completed（明るい緑のバッジ）、In progress（黄色いバッジ）、Planned（青いバッジ）、Deprecated（赤いバッジ）、または On Hold（オレンジのバッジ）。また、紹介セクションにバッジとして表示される必要があります。

---
goal: [パッケージ実装計画の目標を説明する簡潔なタイトル]
version: [オプション：例、1.0、日付]
date_created: [YYYY-MM-DD]
last_updated: [オプション：YYYY-MM-DD]
owner: [オプション：このスペックの責任者であるチーム/個人]
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
tags: [オプション：関連するタグまたはカテゴリのリスト、例 `feature`、`upgrade`、`chore`、`architecture`、`migration`、`bug` など]
---

# Introduction

![Status: <status>](https://img.shields.io/badge/status-<status>-<status_color>)

[計画の簡潔な紹介と、それが達成することを意図した目標]

## 1. 要件と制約

[計画に影響を与え、その実装方法を制限するすべての要件と制約を明示的にリストアップします。明確性のためにプロットポイントまたはテーブルを使用してください。]

- **REQ-001**: 要件 1
- **SEC-001**: セキュリティ要件 1
- **[3 LETTERS]-001**: その他の要件 1
- **CON-001**: 制約 1
- **GUD-001**: 従うべきガイドライン 1
- **PAT-001**: 従うべきパターン 1

## 2. 実装ステップ

### 実装フェーズ 1

- GOAL-001: [このフェーズの目標を説明してください。例：「機能 X を実装する」、「モジュール Y をリファクタリングする」など]

| Task | Description | Completed | Date |
|------|-------------|-----------|------|
| TASK-001 | タスク 1 の説明 | ✅ | 2025-04-25 |
| TASK-002 | タスク 2 の説明 | |  |
| TASK-003 | タスク 3 の説明 | |  |

### 実装フェーズ 2

- GOAL-002: [このフェーズの目標を説明してください。例：「機能 X を実装する」、「モジュール Y をリファクタリングする」など]

| Task | Description | Completed | Date |
|------|-------------|-----------|------|
| TASK-004 | タスク 4 の説明 | |  |
| TASK-005 | タスク 5 の説明 | |  |
| TASK-006 | タスク 6 の説明 | |  |

## 3. 代替案

[検討された代替アプローチとそれらが選択されなかった理由のプロットポイントリスト。これにより、選択されたアプローチのコンテキストと根拠を提供するのに役立ちます。]

- **ALT-001**: 代替アプローチ 1
- **ALT-002**: 代替アプローチ 2

## 4. 依存関係

[計画が依存するライブラリ、フレームワーク、または他のコンポーネントなど、対処する必要のある依存関係をリストアップしてください。]

- **DEP-001**: 依存関係 1
- **DEP-002**: 依存関係 2

## 5. ファイル

[機能またはリファクタリング タスクの影響を受けるファイルをリストアップしてください。]

- **FILE-001**: ファイル 1 の説明
- **FILE-002**: ファイル 2 の説明

## 6. テスト

[機能またはリファクタリング タスクを検証するために実装する必要があるテストをリストアップしてください。]

- **TEST-001**: テスト 1 の説明
- **TEST-002**: テスト 2 の説明

## 7. リスクと仮定

[計画の実装に関連するリスクまたは仮定をリストアップしてください。]

- **RISK-001**: リスク 1
- **ASSUMPTION-001**: 仮定 1

## 8. 関連仕様 / 参考資料

[関連する仕様 1 へのリンク]
[関連する外部ドキュメントへのリンク]