実装計画の更新

主要指令

既存の実装計画ファイル ${file} を、新規または更新された要件に基づいて更新するタスクを担当する AI エージェントです。出力はマシンリーダブルで、決定論的であり、他の 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 エージェントは実行前にテンプレート準拠を検証する必要があります。

テンプレート検証ルール

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

ステータス

実装計画のステータスはフロントマターで明確に定義され、計画の現在の状態を反映している必要があります。ステータスは以下のいずれかである必要があります（括弧内は 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` など]
---

# 導入

![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-001 | タスク 1 の説明 | ✅ | 2025-04-25 |
| TASK-002 | タスク 2 の説明 | |  |
| TASK-003 | タスク 3 の説明 | |  |

### 実装フェーズ 2

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

| タスク | 説明 | 完了 | 日付 |
|--------|------|------|------|
| 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]
[関連する外部ドキュメント]