Back to Details

create-implementation-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Implementation Plan

创建实施计划

Primary Directive

核心指令

Your goal is to create a new implementation plan file for 
${input:PlanPurpose}
. Your output must be machine-readable, deterministic, and structured for autonomous execution by other AI systems or humans.
你的目标是为
${input:PlanPurpose}
创建一份新的实施计划文件。输出内容必须具备机器可读性、确定性，且结构需适配其他AI系统或人类的自主执行需求。

Execution Context

执行上下文

This prompt is designed for AI-to-AI communication and automated processing. All instructions must be interpreted literally and executed systematically without human interpretation or clarification.
本提示词专为AI与AI之间的通信及自动化处理设计。所有指令必须按字面意思解读，系统地执行，无需人工解读或澄清。

Core Requirements

核心要求

  • Generate implementation plans that are fully executable by AI agents or humans
  • Use deterministic language with zero ambiguity
  • Structure all content for automated parsing and execution
  • Ensure complete self-containment with no external dependencies for understanding
  • 生成可由AI Agent或人类完全执行的实施计划
  • 使用无歧义的确定性语言
  • 所有内容需结构化，便于自动解析和执行
  • 确保内容完全自包含，理解过程无需依赖外部资源

Plan Structure Requirements

计划结构要求

Plans must consist of discrete, atomic phases containing executable tasks. Each phase must be independently processable by AI agents or humans without cross-phase dependencies unless explicitly declared.
计划必须由包含可执行任务的独立、原子化阶段组成。除非明确声明，否则每个阶段必须可由AI Agent或人类独立处理，不存在跨阶段依赖。

Phase Architecture

阶段架构

  • Each phase must have measurable completion criteria
  • Tasks within phases must be executable in parallel unless dependencies are specified
  • All task descriptions must include specific file paths, function names, and exact implementation details
  • No task should require human interpretation or decision-making
  • 每个阶段必须具备可衡量的完成标准
  • 除非指定依赖关系，否则阶段内的任务可并行执行
  • 所有任务描述必须包含具体文件路径、函数名称和确切实现细节
  • 任何任务都不应需要人工解读或决策

AI-Optimized Implementation Standards

AI优化的实施标准

  • Use explicit, unambiguous language with zero interpretation required
  • Structure all content as machine-parseable formats (tables, lists, structured data)
  • Include specific file paths, line numbers, and exact code references where applicable
  • Define all variables, constants, and configuration values explicitly
  • Provide complete context within each task description
  • Use standardized prefixes for all identifiers (REQ-, TASK-, etc.)
  • Include validation criteria that can be automatically verified
  • 使用明确、无歧义的语言，无需任何解读
  • 将所有内容组织为可机器解析的格式（表格、列表、结构化数据）
  • 适用时包含具体文件路径、行号和确切代码引用
  • 明确定义所有变量、常量和配置值
  • 在每个任务描述中提供完整上下文
  • 为所有标识符使用标准化前缀（REQ-、TASK-等）
  • 包含可自动验证的验证标准

Output File Specifications

输出文件规范

  • Save implementation plan files in 
    /plan/
    directory
  • Use naming convention: 
    [purpose]-[component]-[version].md
  • Purpose prefixes: 
    upgrade|refactor|feature|data|infrastructure|process|architecture|design
  • Example: 
    upgrade-system-command-4.md
    , 
    feature-auth-module-1.md
  • File must be valid Markdown with proper front matter structure
  • 将实施计划文件保存至
    /plan/
    目录
  • 使用命名约定：
    [purpose]-[component]-[version].md
  • 用途前缀：
    upgrade|refactor|feature|data|infrastructure|process|architecture|design
  • 示例：
    upgrade-system-command-4.md
    , 
    feature-auth-module-1.md
  • 文件必须是符合规范的Markdown，具备正确的前置元数据结构

Mandatory Template Structure

强制模板结构

All implementation plans must strictly adhere to the following template. Each section is required and must be populated with specific, actionable content. AI agents must validate template compliance before execution.
所有实施计划必须严格遵循以下模板。每个章节为必填项，且需填充具体、可操作的内容。AI Agent在执行前必须验证模板合规性。

Template Validation Rules

模板验证规则

  • All front matter fields must be present and properly formatted
  • All section headers must match exactly (case-sensitive)
  • All identifier prefixes must follow the specified format
  • Tables must include all required columns
  • No placeholder text may remain in the final output
  • 所有前置元数据字段必须存在且格式正确
  • 所有章节标题必须完全匹配（区分大小写）
  • 所有标识符前缀必须遵循指定格式
  • 表格必须包含所有必填列
  • 最终输出中不得保留占位文本

Status

状态

The status of the implementation plan must be clearly defined in the front matter and must reflect the current state of the plan. The status can be one of the following (status_color in brackets): 
Completed
(bright green badge), 
In progress
(yellow badge), 
Planned
(blue badge), 
Deprecated
(red badge), or 
On Hold
(orange badge). It should also be displayed as a badge in the introduction section.
md
---
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]
---
实施计划的状态必须在前置元数据中明确定义，且需反映计划的当前状态。状态可选以下之一（括号内为状态颜色）：
Completed
（亮绿色徽章）、
In progress
（黄色徽章）、
Planned
（蓝色徽章）、
Deprecated
（红色徽章）或
On Hold
（橙色徽章）。同时需在引言部分以徽章形式展示。
md
---
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

Introduction

Status: <status>
[A short concise introduction to the plan and the goal it is intended to achieve.]
Status: <status>
[A short concise introduction to the plan and the goal it is intended to achieve.]

1. Requirements & Constraints

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
[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

2. Implementation Steps

Implementation Phase 1

Implementation Phase 1

  • GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
TaskDescriptionCompletedDate
TASK-001Description of task 1✅2025-04-25
TASK-002Description of task 2
TASK-003Description of task 3
  • GOAL-001: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
TaskDescriptionCompletedDate
TASK-001Description of task 1✅2025-04-25
TASK-002Description of task 2
TASK-003Description of task 3

Implementation Phase 2

Implementation Phase 2

  • GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
TaskDescriptionCompletedDate
TASK-004Description of task 4
TASK-005Description of task 5
TASK-006Description of task 6
  • GOAL-002: [Describe the goal of this phase, e.g., "Implement feature X", "Refactor module Y", etc.]
TaskDescriptionCompletedDate
TASK-004Description of task 4
TASK-005Description of task 5
TASK-006Description of task 6

3. Alternatives

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
[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

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
[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

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
[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

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
[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

7. Risks & Assumptions

[List any risks or assumptions related to the implementation of the plan.]
  • RISK-001: Risk 1
  • ASSUMPTION-001: Assumption 1
[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

8. Related Specifications / Further Reading

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