Back to Details

feature-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Implementation Plan

实施计划

Overview

概述

Structured command to help create implementation plan documents by determining plan structure, sequencing development phases, and generating actionable tasks following our established planning patterns.
You are helping create implementation plan documents following our established feature development process. You have comprehensive context available:
Required Reading:
  • Feature development guide: @~/.local/share/dotfiles/ai/guides/feature-development-process.md
  • Vision document: @vision.md
  • Requirements document: @requirements.md
  • Technical specification: @spec.md
Note: If the project has a local copy of the guide at @project/guides/feature-development-process.md, you may reference that instead for project-specific modifications.
Additional Context Available:
  • Full Codebase: Examine existing implementation patterns and architecture
  • Implementation Guides: Review backend/docs/guides/ and frontend/docs/guides/ for established approaches
  • Testing Guide: Reference backend/docs/guides/testing/backend-testing-guide.md for testing strategy
Approach: Use all available context to create practical implementation plans with clear sequencing and integrated development phases.
IMPORTANT: Start by creating a TODO list to track the 3 phases of plan creation. Mark the first phase as "in_progress" and others as "pending".
这是一个结构化指令，可帮助你按照既定规划模式，通过确定计划结构、规划开发阶段顺序和生成可执行任务来创建实施计划文档。
你需要遵循我们既定的功能开发流程来创建实施计划文档，以下是可供你使用的全面上下文信息：
必读文档:
  • 功能开发指南: @~/.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获取测试策略
实施方法: 利用所有可用上下文信息，创建包含清晰执行顺序和完整开发阶段的实用实施计划。
重要提示: 首先创建一个待办事项列表来跟踪计划创建的3个阶段。将第一个阶段标记为"in_progress"，其余阶段标记为"pending"。

Implementation Plan Structure

实施计划结构

Our implementation plans include:
  • Development phases and sequencing (the WHEN and ORDER)
  • Detailed code blocks for unique/novel aspects (with full documentation using your language's standards)
  • Pattern references for established code (noting only what's different)
  • Granular checkbox tasks within each phase
  • Cross-references to vision, requirements (using IDs like REQ-2.1.1, US-1.1.2), and spec documents
IMPORTANT:
  • Do NOT include any effort sizing estimates, hours, or time estimates in the plan documents
  • The checklist tasks themselves serve as the completion criteria - no separate success criteria sections needed
  • Code Detail Strategy:
    • Unique/Novel/Complex code: Spell out FULLY with complete documentation using your language's conventions - developers should be able to review, understand, and iterate at the plan level
    • Established patterns: Just reference existing implementations and note what's different - no boilerplate code
    • When you DO include code, make it thorough and detailed with full documentation
    • Goal: Enable plan-level iteration for novel code, skip redundant boilerplate entirely
我们的实施计划包含以下内容:
  • 开发阶段与执行顺序（时间安排和先后顺序）
  • 针对独特/创新功能的详细代码块（遵循所用语言的标准进行完整文档化）
  • 既有代码的模式参考（仅标注差异部分）
  • 每个阶段内的细粒度复选框任务
  • 与愿景文档、需求文档（使用REQ-2.1.1、US-1.1.2等ID）和规格文档的交叉引用
重要提示:
  • 请勿在计划文档中包含任何工作量估算、耗时或时间预估内容
  • 复选框任务本身即为完成标准，无需单独设置成功标准章节
  • 代码细节策略:
    • 独特/创新/复杂代码: 完整编写代码并遵循所用语言的规范进行全面文档化，确保开发人员可在计划层面进行评审、理解和迭代
    • 既有模式: 仅参考现有实现并标注差异部分，无需重复样板代码
    • 当你确实需要包含代码时，请确保内容详尽且文档完整
    • 目标: 支持对创新代码进行计划层面的迭代，完全跳过冗余的样板代码

Process: Work Through These 3 Phases Sequentially

流程: 按顺序完成以下3个阶段

Phase 1: Determine Plan Structure

阶段1: 确定计划结构

First, analyze the technical specification and determine how to organize the planning documents:
Complexity Analysis:
  1. Review the technical spec to understand implementation scope
  2. Examine existing similar features in the codebase for patterns
  3. Assess team involvement (backend-only, frontend-only, full-stack, design work)
  4. Determine optimal plan structure
Structure Recommendation - Suggest approach with rationale:
  • Single plan.md: For focused features or single-domain work (backend-only, frontend-only, etc.) (estimated <500 lines)
  • Split by domain: plan-backend.md + plan-frontend.md + plan-design.md for complex full-stack features
  • Separate tasks.md: Only for complex coordination (multiple developers, handoff scenarios)
Ask: "Based on your spec analysis, I recommend [structure]. Does this match your preferences?"
首先，分析技术规格文档，确定规划文档的组织方式:
复杂度分析:
  1. 审阅技术规格文档以了解实施范围
  2. 查看代码库中现有类似功能的实现模式
  3. 评估团队参与范围（仅后端、仅前端、全栈、设计工作）
  4. 确定最优的计划结构
结构建议 - 提出方案并说明理由:
  • 单一plan.md文档: 适用于聚焦型功能或单一领域工作（仅后端、仅前端等）（预估篇幅<500行）
  • 按领域拆分: 对于复杂的全栈功能，拆分为plan-backend.md + plan-frontend.md + plan-design.md
  • 独立tasks.md文档: 仅适用于需要复杂协作的场景（多名开发人员参与、存在工作交接等）
询问: "根据对规格文档的分析，我推荐采用[结构方案]。这符合你的预期吗?"

Phase 2: Design Implementation Approach

阶段2: 设计实施方案

Determine implementation approach and phase structure:
Planning Activities:
  • Analyze implementation scope and determine high-level phase breakdown
  • Identify what's unique vs established patterns - differentiate novel aspects from boilerplate
  • Identify phase dependencies and sequencing requirements
  • Determine code placement approach (which files, directory structure, following existing patterns)
  • Assess complexity factors and technical challenges requiring detailed explanation
  • Reference existing patterns to minimize boilerplate in plan - note existing implementations developers can follow
Information Gathering:
  • Ask specific questions about:
    • Unique implementation approaches not covered by existing patterns
    • Testing depth preferences for this feature
    • Any specific implementation constraints or preferences
Sequencing Validation:
  • Present proposed implementation sequence with high-level phase breakdown and rationale
  • Ask for sequencing confirmation: "Does this order make sense? Are there dependencies I missed?"
  • Validate phase dependencies and prerequisites before proceeding to document generation
  • Get explicit approval of the implementation approach and sequencing
确定实施方法和阶段结构:
规划活动:
  • 分析实施范围并确定高层级的阶段划分
  • 区分独特功能与既有模式 - 划分创新内容与样板代码
  • 识别阶段依赖关系和顺序要求
  • 确定代码放置方案（对应文件、目录结构，遵循现有模式）
  • 评估复杂度因素和需要详细说明的技术挑战
  • 参考既有模式以减少计划中的样板代码 - 标注开发人员可参考的现有实现
信息收集:
  • 询问以下具体问题:
    • 现有模式未覆盖的独特实现方案
    • 该功能的测试深度偏好
    • 任何特定的实施约束或偏好
顺序验证:
  • 提出建议的实施顺序，包含高层级阶段划分和理由
  • 询问顺序确认: "这个顺序是否合理? 我有没有遗漏任何依赖关系?"
  • 在生成文档前验证阶段依赖关系和前置条件
  • 获得实施方法和顺序的明确批准

Phase 3: Generate Plan Documents

阶段3: 生成计划文档

Create the actual plan documents based on Phase 2 planning:
  • Generate plan.md or plan-[domain].md files as determined in Phase 1
  • Write implementation phases using the approach and structure designed in Phase 2
  • Include table of contents with systematic section numbering (1.1, 1.2, 2.1, 2.2, etc.)
  • Add actionable checkbox tasks within each implementation phase (these tasks ARE the completion criteria)
  • Apply selective detail approach:
    • For unique/novel code: Include FULL, detailed implementations with complete documentation using your language's standards
    • For established patterns: Reference existing implementations and note only what's different
    • When code IS included, make it complete enough for plan-level review and iteration
  • Include justification and cross-references for each phase explaining which spec sections and requirements it implements (use spec references like spec.md#1.2 and requirement IDs like REQ-2.1.1, US-1.1.2)
  • Use clear, practical language focused on implementation sequencing
  • Update discussion-summary.md:
    • Check if discussion-summary.md exists in the feature directory
    • If exists: Add a "Plan Phase" section with:
      • Implementation approach discussions
      • Sequencing decisions and rationale
      • Any pivots made during planning
      • Update Key Decisions Log with plan decisions (continuing numbering)
      • Update Technical Context with newly referenced files
    • If not exists: Create it with full structure including earlier phase placeholders
根据阶段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
    • 若存在: 添加“计划阶段”章节，包含:
      • 实施方案讨论内容
      • 顺序决策及理由
      • 规划过程中的任何调整
      • 在关键决策日志中添加计划相关决策（延续现有编号）
      • 在技术上下文部分更新新增的参考文件
    • 若不存在: 创建完整结构的文档，包含前期阶段的占位符

Guidelines

指南

  • Context First: Always analyze existing plans and implementation patterns before planning
  • Selective Detail Strategy:
    • Novel/Complex Code: Include FULL, detailed code with complete documentation using your framework's conventions - enable plan-level review and iteration
    • Established Patterns: Reference existing implementations, note differences only - no boilerplate repetition
    • When code IS included, make it thorough enough for developers to understand and refactor in the plan itself
  • Pattern References: When similar code exists, say "Follow pattern from X, but adjust Y" instead of repeating boilerplate
  • Plan Overview Required: Start documents with concise overview (what we're building, key components, sequencing logic as bullets)
  • Prerequisites as Phase 1: Include external setup, manual configurations, and environment requirements as the first implementation phase - even if they're confirmatory steps
  • Actionable Tasks: Use checkboxes for actionable tasks and implementation steps
  • Integrated Development: Each phase includes code implementation with appropriate validation and data (not separate activities)
  • Code + Validation Approach:
    • Implementation phases focus on novel/complex code with full details; reference existing patterns for standard code
    • When code IS included: make it thorough with complete documentation using your framework's standards for plan-level review
    • Include tests: full details for novel logic, references for standard patterns appropriate to your testing framework
    • Include smoke tests, throwaway scripts, or manual validation when formal testing patterns don't exist
    • Phases creating new data models should include realistic sample data for developer use
  • Test Structure Pattern: Selective detail based on novelty
    • Standard CRUD/simple patterns: Just reference existing test patterns ("Follow test pattern from X")
    • Novel/complex testing logic: Include FULL test structure with complete test blocks and implementation details appropriate to your testing framework
    • When tests ARE included, make them detailed enough to review and iterate at the plan level
    • Goal: Enable thorough test review for unique testing scenarios, skip boilerplate for standard patterns
  • Code Documentation: Full documentation for novel code, skip for standard patterns
    • Standard CRUD/simple patterns: Developers can follow existing examples - no need to include
    • Novel/complex code: Include COMPLETE documentation with all parameters, return values, examples, type information, and detailed descriptions using your language's documentation standards
    • When documentation IS included, make it thorough and complete - enable full understanding at the plan level
    • Use your language's documentation format (e.g., JSDoc, docstrings, YARD, etc.)
    • Goal: Full documentation for unique code, zero boilerplate for standard patterns
  • Incremental Validation: Include validation steps for complex integrations and end-to-end workflows where manual testing would be tedious
  • Early Sample Data: Include realistic sample data for new backend database models early in development phases, unless model interdependencies prevent it
  • Justification Required: Every implementation phase must be traceable to spec sections
  • Pattern Following: Base implementation approach on established codebase patterns
  • Documentation Required: Include documentation/guide generation as the final phase of every implementation plan
  • Focus on Implementation Only: Do NOT include development philosophy, risk mitigation strategy, or quality assurance strategy sections - developers have vision, requirements, spec, and guides for context
  • Update your TODO list as you complete each phase
  • Focus on WHEN and ORDER of implementation phases
  • Reference implementation guides and similar features
  • Cross-reference all previous documents for business and technical context
  • 上下文优先: 在规划前始终分析现有计划和实现模式
  • 选择性细节策略:
    • 创新/复杂代码: 包含完整、详尽的代码及符合框架规范的全面文档 - 支持计划层面的评审和迭代
    • 既有模式: 参考现有实现，仅标注差异部分 - 不重复样板代码
    • 当确实包含代码时，确保内容足够详尽，以便开发人员在计划层面理解和重构
  • 模式引用: 当存在类似代码时，使用“遵循X中的模式，但调整Y”的表述，而非重复样板代码
  • 必须包含计划概述: 文档开头需包含简洁的概述（我们要构建的内容、核心组件、顺序逻辑，以项目符号呈现）
  • 前置条件作为第一阶段: 将外部设置、手动配置和环境需求作为第一个实施阶段，即使这些是确认性步骤
  • 可执行任务: 使用复选框表示可执行任务和实施步骤
  • 集成式开发: 每个阶段包含代码实现及相应的验证和数据处理（而非独立活动）
  • 代码+验证方法:
    • 实施阶段聚焦于创新/复杂代码的详细内容；对于标准代码，参考既有模式
    • 当确实包含代码时: 确保内容详尽，符合框架规范并带有完整文档，以支持计划层面的评审
    • 包含测试内容: 创新逻辑的测试需完整详细；标准模式的测试参考对应测试框架的既有模式
    • 当不存在正式测试模式时，包含冒烟测试、临时脚本或手动验证步骤
    • 创建新数据模型的阶段需为开发人员提供真实的示例数据
  • 测试结构模式: 根据创新性采用选择性细节策略
    • 标准CRUD/简单模式: 仅参考现有测试模式（如“遵循X中的测试模式”）
    • 创新/复杂测试逻辑: 包含完整的测试结构、测试块和符合测试框架的实现细节
    • 当确实包含测试内容时，确保足够详尽以支持计划层面的评审和迭代
    • 目标: 针对独特测试场景进行全面评审，跳过标准模式的样板内容
  • 代码文档: 创新代码需完整文档化，标准模式无需文档
    • 标准CRUD/简单模式: 开发人员可参考现有示例 - 无需包含文档
    • 创新/复杂代码: 包含完整的文档，涵盖所有参数、返回值、示例、类型信息和详细说明，遵循所用语言的文档标准
    • 当确实包含文档时，确保内容详尽完整 - 支持在计划层面全面理解
    • 使用所用语言的文档格式（如JSDoc、docstrings、YARD等）
    • 目标: 为独特代码提供完整文档，完全避免标准模式的样板内容
  • 增量验证: 对于复杂集成和端到端工作流，包含验证步骤（手动测试会较为繁琐的场景）
  • 提前提供示例数据: 尽早在开发阶段为新的后端数据库模型提供真实的示例数据（除非模型依赖关系不允许）
  • 必须包含依据: 每个实施阶段必须可追溯到规格文档的对应章节
  • 遵循既有模式: 实施方法需基于代码库中的既有模式
  • 必须包含文档/指南生成: 将文档/指南生成为每个实施计划的最后一个阶段
  • 仅聚焦于实施内容: 请勿包含开发理念、风险缓解策略或质量保证策略章节 - 开发人员可通过愿景文档、需求文档、规格文档和指南获取相关上下文
  • 完成每个阶段后更新待办事项列表
  • 聚焦于实施阶段的时间安排和顺序
  • 参考实施指南和类似功能
  • 交叉引用所有前期文档以获取业务和技术上下文

Getting Started Process

启动流程

  1. Create your 3-phase TODO list immediately
  2. Ask user: "What feature directory are you working in? Please provide the full path (e.g., project/features/FT033-feature-name)"
  3. Ask user: "Please tag your vision, requirements, and spec documents with @vision.md @requirements.md @spec.md"
  4. Validate the directory exists and confirm where you'll create the plan documents
  5. Review all previous documents to understand complete feature context
  6. Begin Phase 1 with plan structure analysis and recommendation
  7. Keep recommendations focused and wait for confirmation before proceeding
  1. 立即创建你的3阶段待办事项列表
  2. 询问用户: "你正在哪个功能目录下工作? 请提供完整路径（如project/features/FT033-feature-name）"
  3. 询问用户: "请为你的愿景文档、需求文档和规格文档添加标签@vision.md @requirements.md @spec.md"
  4. 验证目录是否存在，并确认计划文档的创建位置
  5. 审阅所有前期文档以全面理解功能上下文
  6. 开始阶段1的计划结构分析和建议
  7. 建议内容需聚焦，在继续推进前等待用户确认