feature-plan

实施计划

概述

用于帮助创建实施计划文档的结构化命令，可确定计划结构、安排开发阶段顺序，并按照既定的规划模式生成可执行任务。

按照既定的功能开发流程创建实施计划文档。可用的完整上下文：

必读文档：

• 功能开发指南：@~/.local/share/dotfiles/ai/guides/feature-development-process.md
• 愿景文档：@vision.md
• 需求文档：@requirements.md
• 技术规范：@spec.md

注意：如果项目在 @project/guides/feature-development-process.md 中有该指南的本地副本，可改为参考该副本，以了解项目特定的修改。

可用的其他上下文：

• 完整代码库：检查现有实现模式和架构
• 实施指南：查看 backend/docs/guides/ 和 frontend/docs/guides/，了解既定方法
• 测试指南：参考 backend/docs/guides/testing/backend-testing-guide.md，了解测试策略

方法：利用所有可用上下文，制定切实可行、顺序清晰且整合开发阶段的实施计划。

重要：首先创建一个 TODO 列表，用于跟踪计划制定的 3 个阶段。将第一阶段标记为 “in_progress”，其余阶段标记为 “pending”。

实施计划结构

实施计划包括：

• 开发阶段及其顺序（何时开展以及先后次序）
• 针对独特／新颖部分的详细代码块（使用你所用语言的规范，附上完整文档）
• 对既定代码模式的引用（仅说明差异）
• 每个阶段中的细粒度复选框任务
• 对愿景、需求（使用 REQ-2.1.1、US-1.1.2 等 ID）和技术规范文档的交叉引用

重要：

• 不要在计划文档中包含任何工作量、小时数或时间估算
• 清单中的任务本身即为完成标准，无需另设成功标准部分
• 代码细节策略：
  • 独特／新颖／复杂代码：使用你所用语言的规范，完整写明代码并附上完整文档，开发者应能在计划阶段审查、理解并迭代
  • 既定模式：只引用现有实现并说明差异，不要添加样板代码
  • 如果确实需要包含代码，应写得全面、详细并附上完整文档
  • 目标：支持在计划阶段迭代新颖代码，同时完全跳过冗余的样板代码

流程：依次完成以下 3 个阶段

阶段 1：确定计划结构

首先分析技术规范，确定如何组织规划文档：

复杂度分析：

1. 查看技术规范，了解实施范围
2. 检查代码库中类似功能的现有实现，了解其模式
3. 评估团队参与情况（仅后端、仅前端、全栈、设计工作）
4. 确定最佳计划结构

结构建议——给出方案并说明理由：

• 单个 plan.md：适用于重点明确的功能或单一领域的工作（仅后端、仅前端等）（预计少于 500 行）
• 按领域拆分：针对复杂的全栈功能，使用 plan-backend.md + plan-frontend.md + plan-design.md
• 单独的 tasks.md：仅适用于需要复杂协调的情况（多名开发者、交接场景）

提问：“根据对规范的分析，我建议采用[结构]。这符合你的偏好吗？”

阶段 2：设计实施方案

确定实施方案和阶段结构：

规划活动：

• 分析实施范围，确定高层次的阶段划分
• 识别独特之处与成熟模式——区分创新内容和样板代码
• 识别阶段依赖关系和排序要求
• 确定代码放置方案（涉及哪些文件、目录结构，以及如何遵循现有模式）
• 评估复杂性因素和需要详细说明的技术挑战
• 在计划中参考现有模式，尽量减少样板代码——注明开发者可以遵循的现有实现

信息收集：

• 针对以下内容提出具体问题：
  • 现有模式未涵盖的独特实现方案
  • 对此功能的测试深度偏好
  • 任何特定的实施约束或偏好

顺序验证：

• 展示拟议的实施顺序，包括高层次的阶段划分和理由
• 确认实施顺序：“这个顺序合理吗？我是否遗漏了依赖关系？”
• 在继续生成文档之前，验证阶段依赖关系和前置条件
• 明确获得对实施方案和顺序的批准

阶段 3：生成计划文档

根据阶段 2 的规划，创建实际的计划文档：

• 生成 plan.md 或 plan-[domain].md 文件，具体形式由阶段 1 确定
• 按照阶段 2 设计的方案和结构编写实施阶段
• 添加目录，并使用系统化的章节编号（1.1、1.2、2.1、2.2 等）
• 在每个实施阶段中添加可执行的复选框任务（这些任务就是完成标准）
• 采用有选择的详细程度：
  • 对于独特/创新的代码：提供完整、详细的实现，并按照所用语言的规范编写完整文档
  • 对于成熟模式：引用现有实现，并仅说明不同之处
  • 如果包含代码，确保其足够完整，便于在计划层面进行审查和迭代
• 为每个阶段添加理由和交叉引用，说明其实现的规范章节和要求（使用 spec.md#1.2 这样的规范引用，以及 REQ-2.1.1、US-1.1.2 这样的需求 ID）
• 使用清晰、实用的语言，重点说明实施顺序
• 更新 discussion-summary.md：
  • 检查功能目录中是否存在 discussion-summary.md
  • 如果存在：添加一个“计划阶段”部分，包含：
    • 实施方案讨论
    • 顺序决策及其理由
    • 规划期间做出的任何调整
    • 更新关键决策日志，记录计划决策（接续编号）
    • 更新技术上下文，列出新引用的文件
  • 如果不存在：创建该文件，并包含完整结构以及前序阶段的占位内容

指南

• 上下文优先：规划前，务必先分析现有计划和实现模式
• 有选择地详略：
  • 新颖／复杂代码：使用框架约定，提供完整、详细且附有完整文档的代码，以便在计划阶段进行审查和迭代
  • 成熟模式：引用现有实现，仅说明差异，不要重复样板代码
  • 包含代码时，应详尽到足以让开发者在计划中理解并重构
• 引用模式：存在类似代码时，应说明“遵循 X 的模式，但调整 Y”，而不是重复样板代码
• 必须提供计划概览：文档开头应简要概述要构建的内容、关键组件以及按要点列出的排序逻辑
• 将先决条件设为第 1 阶段：将外部设置、手动配置和环境要求作为第一个实现阶段，即使这些步骤只是确认事项也不例外
• 任务应可执行：使用复选框列出可执行任务和实现步骤
• 集成式开发：每个阶段都应包含代码实现，以及适当的验证和数据（不要将这些拆分为独立活动）
• 代码与验证方式：
  • 实现阶段应重点关注新颖／复杂代码，并提供完整细节；标准代码则引用现有模式
  • 包含代码时，应依据框架标准提供详尽的完整文档，以便在计划阶段审查
  • 包含测试：新颖逻辑需提供完整细节；标准模式则根据测试框架引用相应模式
  • 如果没有正式的测试模式，应包含冒烟测试、临时脚本或手动验证
  • 创建新数据模型的阶段应包含真实的示例数据，供开发者使用
• 测试结构模式：根据新颖程度选择详略
  • 标准 CRUD／简单模式：仅引用现有测试模式（“遵循 X 的测试模式”）
  • 新颖／复杂测试逻辑：提供完整的测试结构，包括完整的测试块，以及符合测试框架要求的实现细节
  • 包含测试时，应详尽到足以在计划阶段审查和迭代
  • 目标：充分审查独特的测试场景，跳过标准样板代码
• 代码文档：新颖代码应提供完整文档，标准模式则省略
  • 标准 CRUD／简单模式：开发者可遵循现有示例，无需包含
  • 新颖／复杂代码：依据所用语言的文档标准，提供完整文档，包括所有参数、返回值、示例、类型信息和详细说明
  • 包含文档时，应确保其详尽完整，以便在计划阶段充分理解
  • 使用所用语言的文档格式（例如 JSDoc、文档字符串、YARD 等）
  • 目标：为独特代码提供完整文档，不包含任何标准样板
• 增量验证：对于复杂集成和手动测试繁琐的端到端工作流，应包含验证步骤
• 尽早提供示例数据：除非模型间的依赖关系不允许，否则应在开发早期阶段为新的后端数据库模型提供真实的示例数据
• 必须说明理由：每个实现阶段都必须能追溯到规范中的相应章节
• 遵循模式：实现方案应基于代码库中成熟的模式
• 必须包含文档：每份实现计划都应将生成文档／指南作为最后一个阶段
• 仅关注实现：不要包含开发理念、风险缓解策略或质量保证策略章节——开发者可参考愿景、需求、规范和指南了解背景
• 完成每个阶段后，更新 TODO 列表
• 重点说明实现阶段的时间安排和顺序
• 引用实现指南和类似功能
• 交叉引用所有先前文档，获取业务和技术背景

开始流程

1. 立即创建 3 阶段 TODO 列表
2. 询问用户：“你正在处理哪个功能目录？请提供完整路径（例如，project/features/FT033-feature-name）”
3. 询问用户：“请为你的愿景、需求和规范文档添加标签 @vision.md @requirements.md @spec.md”
4. 验证目录是否存在，并确认你将在何处创建计划文档
5. 查看所有先前的文档，了解完整的功能上下文
6. 开始第 1 阶段，分析计划结构并提出建议
7. 聚焦于建议，并在继续之前等待确认