dev-workflow-planning
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseWorkflow 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
快速参考
| Command | Purpose | When to Use |
|---|---|---|
| Generate ideas and approaches | Starting new features, exploring solutions |
| Create detailed implementation plan | Before coding, after requirements clarification |
| Implement plan step-by-step | When plan is approved, ready to code |
| Review progress, adjust plan | Mid-implementation, after major milestones |
| Capture learnings, document decisions | End of session, before context reset |
| 命令 | 用途 | 适用场景 |
|---|---|---|
| 生成想法和方案 | 启动新功能、探索解决方案时 |
| 创建详细的实施计划 | 编码前、需求明确后 |
| 逐步执行计划 | 计划获批、准备编码时 |
| 回顾进度、调整计划 | 实施中期、完成重要里程碑后 |
| 记录经验、归档决策 | 会话结束前、上下文重置前 |
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
风险与缓解措施
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Risk 1 | Medium | High | Plan B if... |
| 风险 | 发生概率 | 影响程度 | 缓解方案 |
|---|---|---|---|
| 风险1 | 中等 | 高 | 若出现则采用方案B... |
Open Questions
待解决问题
- [Questions to resolve before starting]
undefined- [启动前需明确的问题]
undefinedPhase 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 resulttext
模式: 投入前先验证假设
实施前:
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 flowtext
模式: 以可验证的增量方式构建
针对复杂功能:
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 validationtext
模式: 保持进度可视化
每次操作后:
[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 retrotext
模式: 限制并行工作以提升流程效率
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 teststext
结合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 plantext
结合系统设计使用/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-Pattern | Problem | Fix |
|---|---|---|
| No DoR | Unclear requirements discovered mid-sprint | Gate sprint entry with DoR |
| Soft DoD | "Done" means different things | Written DoD checklist |
| Mega-stories | Never finish, hard to track | Slice to <8 points |
| Missing AC | Built wrong thing | Gherkin format AC |
| No ownership | Work falls through cracks | RACI for every epic |
| Hope-based estimates | Always late | Use 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辅助规划最佳实践
- Planning first - Create a plan before coding
- Scope management - Keep tasks small and verifiable
- Iterative steps - Ship in increments with checkpoints
- Human oversight - Validate assumptions and outputs (tests, logs, metrics)
- 先规划 - 编码前制定计划
- 范围管理 - 保持任务小型且可验证
- 迭代步骤 - 分增量交付并设置检查点
- 人工监督 - 验证假设和输出(测试、日志、指标)
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 - 系统化调试计划