update-implementation-plan

実装計画の更新

基本指令

あなたは、新規または更新された要件に基づいて実装計画ファイル ${file} を更新するタスクを担う AI エージェントです。あなたの出力は、他の AI システムまたは人間による自律的な実行のために、機械可読で、決定論的で、構造化されている必要があります。

実行コンテキスト

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

中核要件

• AI エージェントまたは人間が完全に実行できる実装計画を生成する
• 曖昧さが一切ない決定論的な言葉を使用する
• 自動解析と実行のためにすべての内容を構造化する
• 理解のために外部依存を一切必要としない、完全な自己完結性を確保する

計画構造の要件

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

フェーズアーキテクチャ

• 各フェーズには測定可能な完了基準が必要です
• 依存関係が指定されていない限り、フェーズ内のタスクは並列で実行可能である必要があります
• すべてのタスク記述には、具体的なファイルパス、関数名、正確な実装の詳細を含める必要があります
• 人間による解釈や意思決定を必要とするタスクがあってはなりません

AI 最適化実装基準

• 解釈を一切必要としない、明示的で曖昧さのない言葉を使用する
• すべての内容を機械解析可能な形式（テーブル、リスト、構造化データ）として構成する
• 該当する場合は、具体的なファイルパス、行番号、正確なコード参照を含める
• すべての変数、定数、構成値を明示的に定義する
• 各タスク記述内に完全なコンテキストを提供する
• すべての識別子に標準化されたプレフィックス（REQ-、TASK- など）を使用する
• 自動的に検証可能な検証基準を含める

出力ファイルの仕様

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

必須テンプレート構造

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

テンプレート検証ルール

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

ステータス

実装計画のステータスは front matter で明確に定義する必要があり、計画の現在の状態を反映する必要があります。ステータスは次のいずれかです（括弧内は status_color）: Completed（明るい緑のバッジ）、In progress（黄色のバッジ）、Planned（青のバッジ）、Deprecated（赤のバッジ）、または On Hold（オレンジのバッジ）。また、導入セクションにバッジとして表示する必要があります。

---
goal: [Concise Title Describing the Package Implementation Plan's Goal]
version: [Optional: e.g., 1.0, Date]
date_created: [YYYY-MM-DD]
last_updated: [Optional: YYYY-MM-DD]
owner: [Optional: Team/Individual responsible for this spec]
status: 'Completed'|'In progress'|'Planned'|'Deprecated'|'On Hold'
tags: [Optional: List of relevant tags or categories, e.g., `feature`, `upgrade`, `chore`, `architecture`, `migration`, `bug` etc]
---

# Introduction

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

[A short concise introduction to the plan and the goal it is intended to achieve.]

## 1. Requirements & Constraints

[Explicitly list all requirements & constraints that affect the plan and constrain how it is implemented. Use bullet points or tables for clarity.]

- **REQ-001**: Requirement 1
- **SEC-001**: Security Requirement 1
- **[3 LETTERS]-001**: Other Requirement 1
- **CON-001**: Constraint 1
- **GUD-001**: Guideline 1
- **PAT-001**: Pattern to follow 1

## 2. Implementation Steps

### Implementation Phase 1

- GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]

| Task | Description | Completed | Date |
|------|-------------|-----------|------|
| TASK-001 | Description of task 1 | ✅ | 2025-04-25 |
| TASK-002 | Description of task 2 | |  |
| TASK-003 | Description of task 3 | |  |

### Implementation Phase 2

- GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]

| Task | Description | Completed | Date |
|------|-------------|-----------|------|
| TASK-004 | Description of task 4 | |  |
| TASK-005 | Description of task 5 | |  |
| TASK-006 | Description of task 6 | |  |

## 3. Alternatives

[A bullet point list of any alternative approaches that were considered and why they were not chosen. This helps to provide context and rationale for the chosen approach.]

- **ALT-001**: Alternative approach 1
- **ALT-002**: Alternative approach 2

## 4. Dependencies

[List any dependencies that need to be addressed, such as libraries, frameworks, or other components that the plan relies on.]

- **DEP-001**: Dependency 1
- **DEP-002**: Dependency 2

## 5. Files

[List the files that will be affected by the feature or refactoring task.]

- **FILE-001**: Description of file 1
- **FILE-002**: Description of file 2

## 6. Testing

[List the tests that need to be implemented to verify the feature or refactoring task.]

- **TEST-001**: Description of test 1
- **TEST-002**: Description of test 2

## 7. Risks & Assumptions

[List any risks or assumptions related to the implementation of the plan.]

- **RISK-001**: Risk 1
- **ASSUMPTION-001**: Assumption 1

## 8. Related Specifications / Further Reading

[Link to related spec 1]
[Link to relevant external documentation]