create-implementation-plan

创建实施计划

主要指令

你的目标是为 ${input:PlanPurpose} 创建一个新的实施计划文件。你的输出必须是机器可读、确定性的，并结构化以便其他 AI 系统或人类自主执行。

执行上下文

此提示词专为 AI 与 AI 之间的通信和自动化处理而设计。所有指令必须按字面解释，并系统性地执行，无需人工解释或澄清。

核心要求

• 生成可由 AI Agent 或人类完全执行的实施计划
• 使用零歧义的确定性语言
• 将所有内容结构化，以便自动解析和执行
• 确保完全自包含，理解时无需任何外部依赖

计划结构要求

计划必须由包含可执行任务的离散、原子阶段组成。每个阶段必须可由 AI Agent 或人类独立处理，除非明确声明，否则不得存在跨阶段依赖。

阶段架构

• 每个阶段必须具有可衡量的完成标准
• 除非指定依赖关系，阶段内的任务必须可并行执行
• 所有任务描述必须包含具体的文件路径、函数名称和确切的实现细节
• 任何任务都不应需要人工解释或决策

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 Agent 必须在执行前验证模板合规性。

模板验证规则

• 所有前言字段必须存在且格式正确
• 所有章节标题必须完全匹配（区分大小写）
• 所有标识符前缀必须遵循指定格式
• 表格必须包含所有必需的列
• 最终输出中不得残留任何占位符文本
• 标识符必须唯一声明。 每个标识符（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**: ... 的项目符号行中的加粗前缀。此后，同一标识符可以在计划的其他位置作为引用出现任意次数（例如 TASK 正文引用某个 REQ，一个 TASK 引用另一个 TASK，Dependencies 部分指向已在上游声明的某个 DEP，等等）。引用是预期行为，不算冲突。

标识符唯一性检查

在最终确定计划之前运行这些检查。检查 (1) 和 (2) 针对声明，必须返回零行。检查 (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

前提条件：一个兼容 POSIX 的 shell（sh / bash），并带有 grep、sed、sort 和 uniq。在没有这些工具的 Windows 上，请使用等效的平台原生命令，并保留相同的声明与引用逻辑。

如果检查 (1) 或 (2) 返回任何行，请重新编号重复项，使每个标识符都只被声明一次，然后重新运行检查，直到两者都为空。

状态

实现计划的状态必须在 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]