dev-workflow-planning

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workflow Planning Skill - Quick Reference

Workflow Planning Skill - 快速参考

This skill enables structured, systematic development workflows. The assistant should apply these patterns when users need to break down complex projects, create implementation plans, or execute multi-step development tasks with clear checkpoints.
Inspired by: Obra Superpowers patterns for structured agent workflows.

该Skill可实现结构化、系统化的开发工作流。当用户需要拆解复杂项目、制定实施计划,或执行带有明确检查点的多步骤开发任务时,助手应应用这些模式。
灵感来源:用于结构化Agent工作流的Obra Superpowers模式。

Quick Reference

快速参考

CommandPurposeWhen to Use
/brainstorm
Generate ideas and approachesStarting new features, exploring solutions
/write-plan
Create detailed implementation planBefore coding, after requirements clarification
/execute-plan
Implement plan step-by-stepWhen plan is approved, ready to code
/checkpoint
Review progress, adjust planMid-implementation, after major milestones
/summarize
Capture learnings, document decisionsEnd of session, before context reset
命令用途适用场景
/brainstorm
生成想法和方案启动新功能、探索解决方案时
/write-plan
创建详细的实施计划编码前、需求明确后
/execute-plan
逐步执行计划计划获批、准备编码时
/checkpoint
回顾进度、调整计划实施中期、完成重要里程碑后
/summarize
记录经验、归档决策会话结束前、上下文重置前

When to Use This Skill

何时使用该Skill

The assistant should invoke this skill when a user requests:
  • Break down a complex feature into steps
  • Create an implementation plan
  • Brainstorm approaches to a problem
  • Execute a multi-step development task
  • Track progress on a project
  • Review and adjust mid-implementation

当用户提出以下需求时,助手应调用该Skill:
  • 将复杂功能拆解为步骤
  • 创建实施计划
  • 针对问题头脑风暴解决方案
  • 执行多步骤开发任务
  • 跟踪项目进度
  • 实施中期回顾与调整

The Three-Phase Workflow

三阶段工作流

Phase 1: Brainstorm

阶段1:头脑风暴(/brainstorm)

Purpose: Explore the problem space and generate potential solutions.
text
/brainstorm [topic or problem]

OUTPUT:
1. Problem Understanding
   - What are we solving?
   - Who is affected?
   - What are the constraints?

2. Potential Approaches (3-5)
   - Approach A: [description, pros, cons]
   - Approach B: [description, pros, cons]
   - Approach C: [description, pros, cons]

3. Questions to Resolve
   - [List of unknowns needing clarification]

4. Recommended Approach
   - [Selected approach with justification]
用途:探索问题范围并生成潜在解决方案。
text
/brainstorm [主题或问题]

输出:
1. 问题理解
   - 我们要解决什么问题?
   - 哪些对象会受影响?
   - 有哪些约束条件?

2. 潜在方案(3-5个)
   - 方案A: [描述、优势、劣势]
   - 方案B: [描述、优势、劣势]
   - 方案C: [描述、优势、劣势]

3. 待澄清问题
   - [需要明确的未知事项列表]

4. 推荐方案
   - [选定方案及理由]

Phase 2: Write Plan

阶段2:制定计划(/write-plan)

Purpose: Create a detailed, actionable implementation plan.
text
/write-plan [feature or task]

OUTPUT:
用途:创建详细、可执行的实施计划。
text
/write-plan [功能或任务]

输出:

Implementation Plan: [Feature Name]

实施计划: [功能名称]

Goal

目标

[Single sentence describing the outcome]
[描述预期成果的单句]

Success Criteria

成功标准

  • Criterion 1
  • Criterion 2
  • Criterion 3
  • 标准1
  • 标准2
  • 标准3

Steps (with estimates)

步骤(含预估时长)

Step 1: [Name] (~Xh)

步骤1: [名称] (~X小时)

  • What: [specific actions]
  • Files: [files to modify/create]
  • Dependencies: [what must exist first]
  • Verification: [how to confirm done]
  • 内容: [具体操作]
  • 文件: [需修改/创建的文件]
  • 依赖: [需提前完成的事项]
  • 验证方式: [确认完成的方法]

Step 2: [Name] (~Xh)

步骤2: [名称] (~X小时)

...
...

Risks & Mitigations

风险与缓解措施

RiskLikelihoodImpactMitigation
Risk 1MediumHighPlan B if...
风险发生概率影响程度缓解方案
风险1中等若出现则采用方案B...

Open Questions

待解决问题

  • [Questions to resolve before starting]
undefined
  • [启动前需明确的问题]
undefined

Phase 3: Execute Plan

阶段3:执行计划(/execute-plan)

Purpose: Implement the plan systematically with checkpoints.
text
/execute-plan [plan reference]

EXECUTION PATTERN:
1. Load the plan
2. For each step:
   a. Announce: "Starting Step X: [name]"
   b. Execute actions
   c. Verify completion
   d. Report: "Step X complete. [brief summary]"
3. After completion:
   a. Run all verification criteria
   b. Report final status

用途:系统地执行计划并设置检查点。
text
/execute-plan [计划引用]

执行模式:
1. 加载计划
2. 针对每个步骤:
   a. 通知: "开始步骤X: [名称]"
   b. 执行操作
   c. 验证完成情况
   d. 汇报: "步骤X完成。[简要总结]"
3. 全部完成后:
   a. 运行所有验证标准
   b. 汇报最终状态

Structured Patterns

结构化模式

Hypothesis-Driven Development

假设驱动开发

text
PATTERN: Test assumptions before committing

Before implementing:
1. State hypothesis: "If we [action], then [expected outcome]"
2. Define experiment: "To test this, we will [minimal test]"
3. Execute experiment
4. Evaluate: "Hypothesis confirmed/rejected because [evidence]"
5. Proceed or pivot based on result
text
模式: 投入前先验证假设

实施前:
1. 提出假设: "如果我们采取[操作],那么会得到[预期结果]"
2. 定义实验: "为验证假设,我们将进行[最小化测试]"
3. 执行实验
4. 评估: "假设成立/不成立,因为[证据]"
5. 根据结果推进或调整方向

Incremental Implementation

增量式实施

text
PATTERN: Build in verifiable increments

For complex features:
1. Identify smallest testable unit
2. Implement and verify
3. Expand scope incrementally
4. Verify at each expansion
5. Integrate and verify whole

Example:
Feature: User authentication
- Increment 1: Basic login form (no backend)
- Increment 2: API endpoint (hardcoded response)
- Increment 3: Database integration
- Increment 4: Session management
- Increment 5: Password reset flow
text
模式: 以可验证的增量方式构建

针对复杂功能:
1. 确定最小可测试单元
2. 实施并验证
3. 逐步扩展范围
4. 每次扩展后验证
5. 集成并验证整体功能

示例:
功能: 用户认证
- 增量1: 基础登录表单(无后端)
- 增量2: API接口(硬编码响应)
- 增量3: 数据库集成
- 增量4: 会话管理
- 增量5: 密码重置流程

Progress Tracking

进度跟踪

text
PATTERN: Maintain visible progress

After each action:
[X] Step 1: Create database schema
[X] Step 2: Implement API endpoints
[IN PROGRESS] Step 3: Add frontend form
[ ] Step 4: Write tests
[ ] Step 5: Deploy to staging

Current: Step 3 of 5 (60% complete)
Blockers: None
Next: Complete form validation
text
模式: 保持进度可视化

每次操作后:
[X] 步骤1: 创建数据库 schema
[X] 步骤2: 实现API接口
[进行中] 步骤3: 添加前端表单
[ ] 步骤4: 编写测试
[ ] 步骤5: 部署到预发布环境

当前状态: 5步中的第3步(完成60%)
阻塞项: 无
下一步: 完成表单验证

Work in Progress (WIP) Limits

在制品(WIP)限制

text
PATTERN: Limit concurrent work to improve flow

WIP limits restrict maximum items in each workflow stage.
Benefits: Makes blockers visible, reduces context switching,
often increases throughput.

RECOMMENDED LIMITS:
| Level | Limit | Rationale |
|-------|-------|-----------|
| Individual | 2-3 tasks | Minimize context switching |
| Team (stories) | Team size + 1 | Allow pairing without blocking |
| In Progress column | 3-5 items | Force completion before starting |
| Code Review | 2-3 PRs | Prevent review bottleneck |

SETTING WIP LIMITS:
1. Start with team size + 1
2. Monitor for 2-4 weeks
3. If limits never reached -> lower them
4. If constantly blocked -> investigate bottleneck, don't raise limit
5. Adjust based on actual flow data

WHEN TO VIOLATE (thoughtfully):
- Emergency production fix
- Unblocking another team
- Document the exception and review in retro

text
模式: 限制并行工作以提升流程效率

WIP限制用于约束每个工作流阶段的最大并行项数量。
优势: 使阻塞项可见,减少上下文切换,通常能提升吞吐量。

推荐限制:
| 层级 | 限制数量 | 理由 |
|-------|-------|-----------|
| 个人 | 2-3项任务 | 最小化上下文切换 |
| 团队(用户故事) | 团队规模+1 | 允许结对编程且不造成阻塞 |
| 进行中列 | 3-5项 | 强制完成现有工作再启动新任务 |
| 代码评审 | 2-3个PR | 避免评审瓶颈 |

设置WIP限制:
1. 从团队规模+1开始
2. 监控2-4周
3. 若从未达到限制 -> 降低限制
4. 若持续阻塞 -> 调查瓶颈,不要直接提高限制
5. 根据实际流程数据调整

可谨慎突破限制的场景:
- 生产环境紧急修复
- 为其他团队解除阻塞
- 记录例外情况并在回顾会议中讨论

Session Management

会话管理

Starting a Session

启动会话

text
Session initialized.
- Project: [name]
- Goal: [today's objective]
- Context loaded: [files, previous decisions]
- Plan status: [steps remaining]

Ready to continue from: [last checkpoint]
text
会话已初始化。
- 项目: [名称]
- 目标: [今日任务]
- 已加载上下文: [文件、之前的决策]
- 计划状态: [剩余步骤]

可从以下位置继续: [上一个检查点]

Ending a Session

结束会话

text
/summarize

OUTPUT:
text
/summarize

输出:

Session Summary

会话总结

Completed

已完成事项

  • [List of completed items]
  • [已完成的任务列表]

In Progress

进行中事项

  • [Current state of incomplete work]
  • [未完成工作的当前状态]

Decisions Made

已做出的决策

  • [Key decisions with rationale]
  • [关键决策及理由]

Next Session

下一次会话任务

  • [First task for next time]
  • [Second task]
  • [下次会话的首个任务]
  • [第二个任务]

Context to Preserve

需保留的上下文

[Critical information for continuity]

---
[保证连续性的关键信息]

---

Decision Framework

决策框架

text
When faced with choices:

1. State the decision clearly
2. List options (2-4)
3. For each option:
   - Pros
   - Cons
   - Effort estimate
   - Risk level
4. Recommendation with justification
5. Reversibility assessment

Example:
Decision: How to implement authentication?

| Option | Pros | Cons | Effort | Risk |
|--------|------|------|--------|------|
| JWT | Stateless, scalable | Token management | 2 days | Low |
| Sessions | Simple, secure | Server state | 1 day | Low |
| OAuth only | No passwords | External dependency | 3 days | Medium |

Recommendation: Sessions for MVP, plan JWT migration for scale.

text
面临选择时:

1. 明确决策内容
2. 列出选项(2-4个)
3. 针对每个选项:
   - 优势
   - 劣势
   - 工作量预估
   - 风险等级
4. 推荐方案及理由
5. 可逆性评估

示例:
决策: 如何实现认证功能?

| 选项 | 优势 | 劣势 | 工作量 | 风险 |
|--------|------|------|--------|------|
| JWT | 无状态、可扩展 | 需管理令牌 | 2天 | 低 |
| 会话 | 简单、安全 | 服务器需维护状态 | 1天 | 低 |
| 仅OAuth | 无需密码 | 依赖外部服务 | 3天 | 中 |

推荐方案: MVP阶段使用会话,后续规划迁移到JWT以支持规模化。

Integration with Other Skills

与其他Skill的集成

With Testing Skill

与测试Skill集成

text
/write-plan with TDD:

Step 1: Write failing test
Step 2: Implement minimal code
Step 3: Verify test passes
Step 4: Refactor
Step 5: Add edge case tests
text
结合TDD使用/write-plan:

步骤1: 编写失败的测试用例
步骤2: 实现最小化代码
步骤3: 验证测试通过
步骤4: 重构
步骤5: 添加边缘情况测试

With Architecture Skill

与架构Skill集成

text
/brainstorm system design:

1. Requirements clarification
2. Component identification
3. Interface definition
4. Data flow mapping
5. Implementation plan

text
结合系统设计使用/brainstorm:

1. 需求澄清
2. 组件识别
3. 接口定义
4. 数据流映射
5. 实施计划制定

Definition of Ready / Done (DoR/DoD)

就绪/完成定义(DoR/DoD)

assets/template-dor-dod.md - Checklists for work readiness and completion.
assets/template-work-item-ticket.md - Ticket template with DoR/DoD and testable acceptance criteria.
assets/template-dor-dod.md - 工作就绪与完成的检查清单。
assets/template-work-item-ticket.md - 包含DoR/DoD和可测试验收标准的工单模板。

Key Sections

核心章节

  • Definition of Ready - User story, bug, technical task checklists
  • Definition of Done - Feature, bug fix, spike completion criteria
  • Acceptance Criteria Templates - Gherkin (Given/When/Then), bullet list, rule-based
  • Estimation Guidelines - Story point reference scale (1-21+), slicing strategies
  • Planning Levels - Roadmap -> Milestone -> Sprint -> Task hierarchy
  • Cross-Functional Coordination - RACI matrix, handoff checklists

  • 就绪定义(DoR) - 用户故事、Bug、技术任务检查清单
  • 完成定义(DoD) - 功能、Bug修复、研究任务的完成标准
  • 验收标准模板 - Gherkin(Given/When/Then)、项目符号列表、规则式
  • 预估指南 - 故事点参考量表(1-21+)、拆分策略
  • 规划层级 - 路线图 -> 里程碑 -> 迭代周期 -> 任务的层级结构
  • 跨职能协作 - RACI矩阵、交接检查清单

Do / Avoid

应做/避免事项

GOOD: Do

应做

  • Check DoR before pulling work into sprint
  • Verify DoD before marking complete
  • Size stories using reference scale
  • Slice large stories (>8 points)
  • Document acceptance criteria upfront
  • Include risk buffer in estimates
  • Coordinate handoffs explicitly
  • 拉取任务到迭代周期前检查DoR
  • 标记完成前验证DoD
  • 使用参考量表估算故事点
  • 拆分大型故事(>8点)
  • 提前记录验收标准
  • 预估时预留风险缓冲
  • 明确协调交接事项

BAD: Avoid

避免

  • Starting work without clear acceptance criteria
  • Declaring "done" without testing
  • Estimating without understanding scope
  • Working on stories too big to finish in sprint
  • Skipping code review "to save time"
  • Deploying without staging verification
  • Assuming handoffs happen automatically

  • 在验收标准不明确时启动工作
  • 未测试就宣称“完成”
  • 未理解范围就进行预估
  • 处理无法在迭代周期内完成的大型故事
  • 为“节省时间”跳过代码评审
  • 未在预发布环境验证就部署
  • 假设交接会自动完成

Anti-Patterns

反模式

Anti-PatternProblemFix
No DoRUnclear requirements discovered mid-sprintGate sprint entry with DoR
Soft DoD"Done" means different thingsWritten DoD checklist
Mega-storiesNever finish, hard to trackSlice to <8 points
Missing ACBuilt wrong thingGherkin format AC
No ownershipWork falls through cracksRACI for every epic
Hope-based estimatesAlways lateUse reference scale + buffer

反模式问题解决方案
无DoR迭代周期中期才发现需求不明确用DoR作为迭代周期准入门槛
模糊的DoD“完成”的定义不统一编写明确的DoD检查清单
巨型故事永远无法完成,难以跟踪拆分到<8个故事点
缺失验收标准开发出不符合需求的功能使用Gherkin格式的验收标准
无人负责工作被遗漏为每个史诗任务指定RACI角色
基于期望的预估总是延期使用参考量表+缓冲时间

Optional: AI/Automation

可选:AI/自动化

Note: AI can assist but should not replace human judgment on priorities and acceptance.
  • Generate acceptance criteria - Draft from story description (needs review)
  • Suggest story slicing - Based on complexity analysis
  • Dependency mapping - Identify blocking relationships
  • AI-augmented planning - Use LLMs to draft plans, but validate assumptions
注意:AI可提供协助,但不应替代人类对优先级和验收标准的判断。
  • 生成验收标准 - 根据故事描述生成草稿(需审核)
  • 建议故事拆分 - 基于复杂度分析
  • 依赖关系映射 - 识别阻塞关系
  • AI辅助规划 - 使用LLM生成计划草稿,但需验证假设

AI-Assisted Planning Best Practices

AI辅助规划最佳实践

  1. Planning first - Create a plan before coding
  2. Scope management - Keep tasks small and verifiable
  3. Iterative steps - Ship in increments with checkpoints
  4. Human oversight - Validate assumptions and outputs (tests, logs, metrics)
  1. 先规划 - 编码前制定计划
  2. 范围管理 - 保持任务小型且可验证
  3. 迭代步骤 - 分增量交付并设置检查点
  4. 人工监督 - 验证假设和输出(测试、日志、指标)

Bounded Claims

局限性声明

  • AI-generated acceptance criteria need human review
  • Story point estimates require team calibration
  • Dependency mapping suggestions need validation
  • AI impact on delivery stability requires monitoring

  • AI生成的验收标准需要人工审核
  • 故事点估算需要团队校准
  • 依赖关系映射建议需要验证
  • AI对交付稳定性的影响需要监控

Navigation

导航

Resources

资源

  • references/planning-templates.md - Plan templates for common scenarios
  • references/session-patterns.md - Multi-session project management
  • references/flow-metrics.md - DORA metrics, WIP limits, flow optimization
  • assets/template-dor-dod.md - DoR/DoD checklists, estimation, cross-functional coordination
  • assets/template-work-item-ticket.md - Work item ticket template (DoR/DoD + acceptance criteria)
  • data/sources.json - Workflow methodology references
  • references/planning-templates.md - 常见场景的计划模板
  • references/session-patterns.md - 多会话项目管理
  • references/flow-metrics.md - DORA指标、WIP限制、流程优化
  • assets/template-dor-dod.md - DoR/DoD检查清单、预估、跨职能协作
  • assets/template-work-item-ticket.md - 工作项工单模板(含DoR/DoD+验收标准)
  • data/sources.json - 工作流方法论参考资料

Related Skills

相关Skill

  • ../software-architecture-design/SKILL.md - System design planning
  • ../docs-ai-prd/SKILL.md - Requirements to plan conversion
  • ../qa-testing-strategy/SKILL.md - TDD workflow integration
  • ../qa-debugging/SKILL.md - Systematic debugging plans
  • ../software-architecture-design/SKILL.md - 系统设计规划
  • ../docs-ai-prd/SKILL.md - 需求到计划的转化
  • ../qa-testing-strategy/SKILL.md - TDD工作流集成
  • ../qa-debugging/SKILL.md - 系统化调试计划