Back to Details

plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

/plan -- Architecture-Aware Planning

/plan -- 具备架构感知能力的规划

What

概述

Enters a structured planning mode that considers the project's architecture pattern before producing an implementation plan. Instead of jumping straight to code, this command forces a deliberate pause to:
  • Identify the project's current architecture (or recommend one)
  • Map the task to affected layers, modules, and boundaries
  • Produce a numbered implementation plan with clear steps
  • Iterate on the plan until it is solid before writing any code
Plans are living documents -- if something goes sideways during implementation, stop and re-plan rather than pushing through a broken approach.
进入结构化规划模式，在生成实现计划前会考虑项目的架构模式。该命令不会直接跳转至编码环节，而是强制开发者先完成以下步骤：
  • 识别项目当前的架构（或推荐合适的架构）
  • 将任务映射到受影响的层级、模块和边界
  • 生成带有清晰步骤的编号实现计划
  • 在编写代码前反复迭代完善计划，确保其严谨可行
计划是动态文档——如果在实现过程中出现问题，请停止推进并重新规划，不要继续采用有缺陷的方案。

When

适用场景

  • Non-trivial tasks requiring 3 or more implementation steps
  • Tasks involving architectural decisions (new modules, cross-cutting concerns, new bounded contexts)
  • Features that touch multiple layers (API, application, domain, infrastructure)
  • Refactoring that could affect multiple consumers
  • Any time the user says "plan", "think through", "design this", or "how should I approach"
Skip planning for: Single-file changes, simple bug fixes, typo corrections, config tweaks.
  • 需要3个及以上实现步骤的复杂任务
  • 涉及架构决策的任务（新增模块、横切关注点、新限界上下文）
  • 触及多个层级的功能（API、应用层、领域层、基础设施层）
  • 可能影响多个消费者的重构任务
  • 任何用户提及“plan”“think through”“design this”或“how should I approach”的场景
无需规划的场景： 单文件修改、简单bug修复、拼写错误修正、配置微调。

How

操作步骤

Step 1: Understand the Task

步骤1：理解任务

Check 
docs/specs/
for an approved spec covering this task — if one exists, it is the source of truth: map its acceptance criteria to plan steps and skip ahead to Step 2. If the feature is spec-worthy (too big to describe in one sentence) and no spec exists, recommend 
/spec
first instead of planning on assumptions. Otherwise, clarify what the user wants to build with focused questions. Do not assume requirements that were not stated.
检查
docs/specs/
目录下是否有涵盖该任务的已批准规格说明——如果存在，它将作为事实依据：将其验收标准映射到计划步骤，然后直接跳至步骤2。如果该功能需要规格说明（无法用一句话描述）且当前没有相关规格，建议先使用
/spec
命令，而非基于假设进行规划。否则，通过针对性问题明确用户想要构建的内容，不要假设未明确说明的需求。

Step 2: Detect Architecture

步骤2：检测架构

Use the 
architecture-advisor
skill to determine the project's architecture:
  • Check for existing architecture markers (folder structure, project references, patterns)
  • If no architecture is established, run the architecture questionnaire
  • Load the appropriate architecture-specific skill (vertical-slice, clean-architecture, ddd)
使用
architecture-advisor
技能确定项目的架构：
  • 检查是否存在现有架构标记（文件夹结构、项目引用、模式）
  • 如果尚未确立架构，运行架构调查问卷
  • 加载对应的架构专属技能（vertical-slice、clean-architecture、ddd）

Step 3: Map Affected Areas

步骤3：映射受影响区域

Identify every layer, module, and boundary the task touches:
  • Which projects/folders will have new or modified files?
  • Are there cross-cutting concerns (auth, caching, validation, logging)?
  • What existing code will be impacted? Use 
    find_references
    and 
    find_callers
    MCP tools for blast radius.
  • Are there database migrations needed?
识别任务触及的所有层级、模块和边界：
  • 哪些项目/文件夹会有新增或修改的文件？
  • 是否存在横切关注点（认证、缓存、验证、日志）？
  • 哪些现有代码会受到影响？使用
    find_references
    和
    find_callers
    MCP工具评估影响范围。
  • 是否需要数据库迁移？

Step 4: Produce the Plan

步骤4：生成计划

Output a numbered plan with this structure:
undefined
输出带有以下结构的编号计划：
undefined

Plan: [Task Title]

计划：[任务标题]

Architecture: [Detected architecture] Affected layers: [List] Estimated steps: [Count]
架构： [检测到的架构] 受影响层级： [列表] 预计步骤数： [数量]

Steps

步骤

  1. [Step] -- [Which file/layer] -- [Why this order]
  2. ...
  1. [步骤内容] -- [涉及文件/层级] -- [为何按此顺序]
  2. ...

Open Questions

待确认问题

  • [Anything that needs user input before proceeding]
  • [继续推进前需要用户输入的内容]

Risks

风险

  • [Potential issues and mitigations]
undefined
  • [潜在问题及缓解方案]
undefined

Step 5: Iterate

步骤5：迭代完善

Present the plan and ask: "Does this plan look right, or should I adjust anything?" Revise until the user confirms. Only then proceed to implementation.
展示计划并询问：“这个计划是否合适，需要我调整什么内容吗？” 反复修订直到用户确认，之后再开始实现。

Example

示例

User: /plan Add a product catalog feature with search and filtering

Claude: Let me analyze your project structure first...
用户：/plan 添加具备搜索和筛选功能的产品目录特性

Claude：让我先分析你的项目结构...

Plan: Product Catalog Feature

计划：产品目录特性

Architecture: Vertical Slice Architecture Affected layers: Features/, Infrastructure/Persistence/, Tests/ Estimated steps: 6
架构： Vertical Slice Architecture 受影响层级： Features/、Infrastructure/Persistence/、Tests/ 预计步骤数： 6

Steps

步骤

  1. Create Product entity + EF config -- Domain layer -- Foundation for everything else
  2. Add migration -- Infrastructure -- Schema must exist before features
  3. Scaffold GetProducts feature (with filtering) -- Features/Products/ -- Read path first
  4. Scaffold CreateProduct feature -- Features/Products/ -- Write path
  5. Add integration tests -- Tests/Features/Products/ -- Verify both features
  6. Wire up OpenAPI metadata -- Features/Products/ -- Documentation
  1. 创建Product实体 + EF配置 -- 领域层 -- 作为所有功能的基础
  2. 添加迁移 -- 基础设施层 -- 功能实现前需先确定数据库 schema
  3. 搭建GetProducts特性（含筛选功能） -- Features/Products/ -- 优先实现读取路径
  4. 搭建CreateProduct特性 -- Features/Products/ -- 实现写入路径
  5. 添加集成测试 -- Tests/Features/Products/ -- 验证两个特性
  6. 配置OpenAPI元数据 -- Features/Products/ -- 生成文档

Open Questions

待确认问题

  • Should search be full-text (PostgreSQL tsvector) or simple LIKE?
  • Do products need categories/tags for filtering?
Does this plan look right, or should I adjust anything?
undefined
  • 搜索应使用全文检索（PostgreSQL tsvector）还是简单LIKE查询？
  • 产品是否需要分类/标签用于筛选？
这个计划是否合适，需要我调整什么内容吗？
undefined

Related

相关命令

  • /spec
    -- Write the spec first for features too big to describe in one sentence
  • /scaffold
    -- Generate the files once the plan is approved
  • /verify
    -- Run verification after implementing the plan
  • /spec
    -- 对于无法用一句话描述的大型功能，先编写规格说明
  • /scaffold
    -- 计划获批后生成文件
  • /verify
    -- 实现计划后运行验证