AI Skills
update-implementation-plan

update-implementation-plan

热门

更新现有的实施计划文件，以提供新功能、重构现有代码、升级包、设计、架构或基础设施。

3.6万Star
0Fork
更新于 2026/7/11
获取 Skill源代码

相关 Skills

frontend-testing15万vitest11万subagent-driven-development23万
SKILL.md
readonly只读
name
update-implementation-plan
description

更新现有的实施计划文件，以提供新功能、重构现有代码、升级包、设计、架构或基础设施。

更新实施计划

主要指令

你是一个AI代理，负责根据新的或更新的需求更新实施计划文件 ${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
  • 文件必须是有效的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: <status>](https://img.shields.io/badge/status-<status>-<status_color>)

[对计划及其旨在实现的目标的简短介绍。]

## 1. 需求与约束

[明确列出影响计划并约束其实现方式的所有需求与约束。使用项目符号或表格以提高清晰度。]

- **REQ-001**: 需求1
- **SEC-001**: 安全需求1
- **[3个字母]-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]
[链接到相关外部文档]