Back to Details

create-plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create Plan

创建计划

Create a comprehensive implementation plan and enter plan mode for execution.
创建全面的实施计划并进入计划模式以执行。

Position in Workflow

在工作流中的位置

Step 4 of development workflow:
  1. /research
    - Understand problem, explore implementation
  2. /brainstorm-solutions
    - Explore solutions
  3. /design-solution
    - Converge on a solution
  4. /make-plan
    - Create implementation plan (THIS)
  5. Code, review, ship
开发工作流的第4步：
  1. /research
    - 理解问题，探索实现方式
  2. /brainstorm-solutions
    - 探索解决方案
  3. /design-solution
    - 确定最终方案
  4. /make-plan
    - 创建实施计划（本环节）
  5. 编码、评审、交付

Core Principle

核心原则

First principles. Simple over easy. Go deep.
You have a bias toward finishing quickly. Resist it.
Never cut corners or take the path of least resistance. Prefer the fundamentally right solution even if it requires significantly more work. The cost of a suboptimal solution compounds over time. Rushed plans degrade codebases.
Simple ≠ Easy:
  • Easy: Less work now, more pain later (shortcuts, hacks, "good enough")
  • Simple: More work now, less pain forever (clean, maintainable, right)
Always choose simple. Always go deep enough to find it.
第一性原理，简单优于容易，深入本质
你可能会倾向于快速完成任务，请抵制这种倾向。
绝不要走捷径或选择阻力最小的路径。即使需要投入更多工作，也要选择本质上正确的解决方案。次优解决方案的成本会随着时间推移不断累积。仓促制定的计划会导致代码库质量下降。
简单 ≠ 容易：
  • 容易：当前工作量少，但后续麻烦多（捷径、临时方案、“差不多就行”）
  • 简单：当前投入更多，但长期无后顾之忧（清晰、可维护、正确）
始终选择简单方案，始终深入探索以找到它。

Input

输入

Default: Use chosen solution from current conversation context.
If argument provided: Additional constraint or clarification for the plan.
默认情况： 使用当前对话上下文选定的解决方案。
若提供参数： 计划的额外约束或说明。

Workflow

工作流

1. Verify Ready State

1. 验证准备状态

Before planning, confirm:
  • Research is complete (problem understood)
  • Solution space was explored
  • A solution has been chosen
If missing context, ask: "I need [research/solution choice] before creating a plan. Should I run 
/research
or 
/design-solution
first?"
制定计划前，确认：
  • 调研已完成（问题已理解）
  • 解决方案空间已探索
  • 已选定最终方案
若缺少上下文，询问：“我需要[调研/方案选定]才能创建计划。是否应先执行/research或/design-solution？”

2. Specify Behavior Explicitly

2. 明确行为规范

This is the most critical step. Be exhaustive.
For each feature/change, document:
这是最关键的步骤。 务必详尽。
针对每个功能/变更，记录：

Desired Behavior

期望行为

  • What SHOULD happen in normal cases
  • Expected outputs for typical inputs
  • Success criteria
  • 正常情况下应发生的事件
  • 典型输入对应的预期输出
  • 成功标准

Undesired Behavior

禁止行为

  • What MUST NOT happen
  • Edge cases to handle gracefully
  • Error conditions and their responses
  • 绝对不能发生的事件
  • 需要妥善处理的边缘情况
  • 错误场景及响应方式

Usage Patterns

使用模式

  • Common usage patterns (happy path)
  • Unhappy paths (errors, edge cases, invalid input)
  • Boundary conditions
Example format:
undefined
  • 常见使用模式（正常流程）
  • 异常流程（错误、边缘情况、无效输入）
  • 边界条件
示例格式：
undefined

Behavior: User Authentication

行为：用户认证

Desired

期望

  • Valid credentials → session created, redirect to dashboard
  • Session expires after 24h of inactivity
  • Invalid credentials → clear error message, no session
  • 有效凭证 → 创建会话，重定向至仪表盘
  • 会话在24小时无活动后过期
  • 无效凭证 → 显示清晰错误信息，不创建会话

Undesired

禁止

  • NEVER store password in plain text
  • NEVER expose session token in URL
  • NEVER allow infinite login attempts
  • 绝不能明文存储密码
  • 绝不能在URL中暴露会话令牌
  • 绝不能允许无限次登录尝试

Edge Cases

边缘情况

  • Expired password → prompt reset before login
  • Concurrent sessions → configurable limit
  • Network timeout during auth → retry with backoff
undefined
  • 密码过期 → 登录前提示重置
  • 并发会话 → 可配置数量限制
  • 认证时网络超时 → 退避重试
undefined

3. Go Deep - Gather Sufficient Context

3. 深入调研 - 收集足够上下文

Do not plan without full understanding. Read more code than feels necessary. Understand the implications of each decision.
Before finalizing any part of the plan:
  • Read all related files, not just the obvious ones
  • Understand how similar problems were solved elsewhere in the codebase
  • Trace the full impact of proposed changes
  • Identify hidden dependencies and side effects
You are not ready to plan if:
  • You haven't read the files your changes will affect
  • You don't understand the existing patterns in this area
  • You're making assumptions instead of verifying
未充分理解前不要制定计划。 阅读比你认为必要的更多代码，理解每个决策的影响。
在最终确定计划的任何部分前：
  • 阅读所有受变更影响的文件
  • 理解代码库中该区域的现有解决方案模式
  • 追踪拟议变更的全面影响
  • 识别隐藏的依赖关系和副作用
若出现以下情况，说明你还没准备好制定计划：
  • 未阅读受变更影响的文件
  • 不理解该区域的现有模式
  • 仅凭假设而非验证来制定计划

4. Apply First Principles Check

4. 第一性原理校验

For each part of the plan, challenge ruthlessly:
QuestionPurpose
Is this necessary?Avoid bloat
Is there a simpler approach?Simple > easy
Does this fight the codebase?Respect existing patterns
What would we regret in 6 months?Long-term thinking
Are we cutting corners?No shortcuts
Do I have enough context?Go deeper if uncertain
Red flags - STOP and reconsider:
  • "This is faster but..." → You're choosing easy over simple
  • "We can clean this up later..." → You won't. Do it right now.
  • "Good enough for now..." → It will become permanent tech debt
  • Adding TODO comments for "later" → Later never comes
  • Skipping error handling "for simplicity" → That's not simplicity, it's negligence
  • "I think this should work..." → You don't know. Go read more code.
  • Feeling rushed → Slow down. Bad plans cost more than slow plans.
针对计划的每个部分，严格质疑：
问题目的
这一步是否必要？避免冗余
是否有更简单的方法？简单 > 容易
这是否与代码库现有模式冲突？尊重现有模式
6个月后我们会后悔什么？长期思维
我们是否在走捷径？拒绝捷径
我的上下文信息足够吗？不确定时深入探索
危险信号 - 立即停止并重新考虑：
  • “这样更快但……” → 你在选择容易而非简单
  • “我们以后再清理……” → 你不会的，现在就做好
  • “现在差不多就行……” → 这会变成永久的技术债务
  • 添加TODO注释留待“以后”处理 → 以后永远不会来
  • 为了“简化”跳过错误处理 → 这不是简化，是疏忽
  • “我觉得这样应该可行……” → 你不确定，去读更多代码
  • 感到仓促 → 慢下来，糟糕的计划比缓慢的计划成本更高

5. Design Tests

5. 设计测试

Write test specifications BEFORE implementation details:
Test design principles:
  • Test behavior, not implementation
  • Cover happy paths AND edge cases
  • One assertion per test (when practical)
  • Tests should be fast and isolated
Format:
undefined
在确定实现细节前先编写测试规范：
测试设计原则：
  • 测试行为而非实现
  • 覆盖正常流程和边缘情况
  • 每个测试尽量对应一个断言
  • 测试应快速且独立
格式：
undefined

Tests

测试

Unit Tests

单元测试

  • test_valid_credentials_creates_session
    - happy path
  • test_invalid_credentials_returns_error
    - error case
  • test_expired_password_prompts_reset
    - edge case
  • test_valid_credentials_creates_session
    - 正常流程
  • test_invalid_credentials_returns_error
    - 错误场景
  • test_expired_password_prompts_reset
    - 边缘情况

Integration Tests

集成测试

  • test_full_login_flow_with_redirect
  • test_session_timeout_behavior
undefined
  • test_full_login_flow_with_redirect
  • test_session_timeout_behavior
undefined

6. Enter Plan Mode

6. 进入计划模式

After documenting behavior and tests, switch to plan mode:
Say: "Entering plan mode to create the implementation plan."
Then use the 
EnterPlanMode
tool.
记录行为和测试后，切换至计划模式：
说明： “进入计划模式以创建实施计划。”
然后使用
EnterPlanMode
工具。

Output Format (Before Plan Mode)

输出格式（进入计划模式前）

markdown
undefined
markdown
undefined

Implementation Plan: [Feature Name]

实施计划：[功能名称]

Chosen Solution

选定方案

[Brief restatement of chosen approach from /design-solution]
[来自/design-solution的选定方案简述]

Behavior Specification

行为规范

[Component/Feature 1]

[组件/功能1]

Desired:
  • [What should happen]
Undesired:
  • [What must not happen]
Edge Cases:
  • [Boundary conditions and handling]
期望：
  • [应发生的事件]
禁止：
  • [绝不能发生的事件]
边缘情况：
  • [边界条件及处理方式]

[Component/Feature 2]

[组件/功能2]

[Same structure]
[相同结构]

Tests

测试

Unit Tests

单元测试

  • test_name
    - [what it verifies]
  • test_name
    - [验证内容]

Integration Tests

集成测试

  • test_name
    - [what it verifies]
  • test_name
    - [验证内容]

First Principles Check

第一性原理校验

  • [Confirmation that no shortcuts are taken]
  • [Confirmation of simplest viable approach]
  • [Alignment with existing patterns]
Entering plan mode to create implementation steps.
undefined
  • [确认未走捷径]
  • [确认采用最简可行方案]
  • [与现有模式一致]
进入计划模式以创建实施步骤。
undefined

Common Mistakes

常见错误

MistakeFix
Insufficient context gatheringRead ALL related files before planning
Vague behavior specsWrite explicit examples for each case
Only happy pathAlways include unhappy paths and edge cases
Tests as afterthoughtDesign tests BEFORE implementation
Shortcut rationalizationApply first principles check ruthlessly
Rushing to plan modeComplete behavior spec first
Missing "undesired" sectionExplicitly state what must NOT happen
Planning with assumptionsVerify by reading code, don't assume
Choosing easy over simpleMore work now = less pain forever
错误修复方式
上下文收集不足制定计划前阅读所有相关文件
行为规范模糊为每个场景编写明确示例
仅覆盖正常流程始终包含异常流程和边缘情况
测试事后补充先设计测试再考虑实现
合理化捷径严格执行第一性原理校验
急于进入计划模式先完成行为规范
遗漏“禁止”部分明确说明绝对不能发生的事件
基于假设制定计划通过阅读代码验证，而非假设
选择容易而非简单现在多投入=长期无麻烦

What NOT to Do

禁止事项

  • Do NOT plan without reading all affected code
  • Do NOT make assumptions - verify by reading
  • Do NOT skip behavior specification
  • Do NOT leave edge cases undefined
  • Do NOT take shortcuts for "simplicity"
  • Do NOT skip the first principles check
  • Do NOT enter plan mode without tests designed
  • Do NOT proceed if solution wasn't explicitly chosen
  • Do NOT rush - bad plans cost more than slow plans
  • Do NOT rationalize shortcuts with "we can fix it later"
  • 未阅读所有受影响代码时，禁止制定计划
  • 禁止仅凭假设行事 - 通过阅读代码验证
  • 禁止跳过行为规范环节
  • 禁止遗漏边缘情况定义
  • 禁止为“简化”走捷径
  • 禁止跳过第一性原理校验
  • 未设计测试时，禁止进入计划模式
  • 未明确选定解决方案时，禁止推进
  • 禁止仓促行事 - 糟糕的计划比缓慢的计划成本更高
  • 禁止用“以后再修复”为捷径找借口