创建实施计划

主要指令

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

执行上下文

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

核心要求

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

计划结构要求

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

阶段架构

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

AI 优化实施标准

• 使用明确、无歧义的语言，无需任何解释
• 将所有内容结构化为机器可解析的格式（表格、列表、结构化数据）
• 在适用时包含具体的文件路径、行号和确切的代码引用
• 明确定义所有变量、常量和配置值
• 在每个任务描述中提供完整的上下文
• 对所有标识符使用标准化前缀（REQ-、TASK- 等）
• 包含可自动验证的验证标准

输出文件规范

• 将实施计划文件保存在 /plan/ 目录中
• 使用命名约定：[目的]-[组件]-[版本].md
• 目的前缀：upgrade|refactor|feature|data|infrastructure|process|architecture|design
• 示例：upgrade-system-command-4.md，feature-auth-module-1.md
• 文件必须是有效的 Markdown，并具有正确的前置元数据结构

强制性模板结构

所有实施计划必须严格遵守以下模板。每个部分都是必需的，并且必须填充具体、可操作的内容。AI 代理必须在执行前验证模板合规性。

模板验证规则

• 所有前置元数据字段必须存在且格式正确
• 所有章节标题必须完全匹配（区分大小写）
• 所有标识符前缀必须遵循指定的格式
• 表格必须包含所有必需的列
• 最终输出中不得保留任何占位符文本

状态

实施计划的状态必须在前置元数据中明确定义，并且必须反映计划的当前状态。状态可以是以下之一（方括号内为状态颜色）：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>](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]
[链接到相关外部文档]