create-implementation-plan

実装計画の作成

主要な指示

あなたの目標は、${input:PlanPurpose} 用の新しい実装計画ファイルを作成することです。出力は、他の 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
• ファイルは、適切なフロントマター構造を持つ有効な Markdown でなければなりません

必須テンプレート構造

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

テンプレート検証ルール

• すべてのフロントマターフィールドが存在し、適切にフォーマットされている必要があります
• すべてのセクションヘッダーは完全に一致する必要があります（大文字と小文字を区別）
• すべての識別子プレフィックスは、指定された形式に従う必要があります
• テーブルには、必要なすべての列を含める必要があります
• 最終出力にプレースホルダーテキストが残っていてはなりません
• 識別子は一意に宣言する必要があります。 すべての識別子（REQ-NNN、SEC-NNN、CON-NNN、GUD-NNN、PAT-NNN、GOAL-NNN、TASK-NNN、ALT-NNN、DEP-NNN、FILE-NNN、TEST-NNN、RISK-NNN、ASSUMPTION-NNN）は、ちょうど一度だけ宣言する必要があります。宣言とは、識別子が行を導入する箇所を指します。すなわち、TASK/GOAL テーブル行の先頭セル、または - **REQ-001**: ... のような箇条書き行の太字プレフィックスです。同じ識別子はその後、計画内の他の場所で参照として何度でも出現できます（REQ を引用する TASK 本文、あるいはある TASK が別の TASK を引用する場合、上流で既に宣言された DEP を指す Dependencies セクションなど）。参照は想定されるものであり、衝突ではありません。

識別子の一意性チェック

計画を確定する前に、これらのチェックを実行してください。チェック (1) と (2) は宣言を対象としており、0 行を返す必要があります。チェック (3) は広範な情報収集のためのスキャンです。有効な参照も検出されるため、ゲートとしてではなく、把握のために使用してください。

# Set PLAN_FILE to the plan being validated.
PLAN_FILE="/plan/<purpose>-<component>-<version>.md"

# 1) Duplicate TASK / GOAL declarations in table rows.
grep -oE '\| (TASK|GOAL)-[0-9]+ \|' "$PLAN_FILE" \
  | sed -E 's/.*((TASK|GOAL)-[0-9]+).*/\1/' \
  | sort | uniq -d

# 2) Duplicate declaration IDs in bullet-style spec lines.
grep -oE '^- \*\*(REQ|SEC|CON|GUD|RISK|ASSUMPTION|TASK|GOAL|FILE|TEST|PAT|ALT|DEP)-[0-9]+\*\*:' "$PLAN_FILE" \
  | sed -E 's/^- \*\*([A-Z]+-[0-9]+)\*\*:.*/\1/' \
  | sort | uniq -d

# 3) Broad duplicate scan (diagnostic only; may include valid references).
grep -oE '(REQ|SEC|CON|GUD|RISK|ASSUMPTION|TASK|GOAL|FILE|TEST|PAT|ALT|DEP)-[0-9]+' "$PLAN_FILE" \
  | sort | uniq -d

前提条件: grep、sed、sort、uniq を備えた POSIX 互換のシェル（sh / bash）。これらのツールがない Windows では、同等のプラットフォームネイティブのコマンドを使用し、同じ宣言対参照のロジックを維持してください。

チェック (1) または (2) が行を返した場合は、各識別子が正確に 1 回だけ宣言されるように重複を採番し直し、両方が空になるまでチェックを再実行してください。

ステータス

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