dev-workflow-planning by vasilyu1983/ai-agents-public
npx skills add https://github.com/vasilyu1983/ai-agents-public --skill dev-workflow-planning此技能支持结构化、系统化的开发工作流。当用户需要分解复杂项目、创建实施计划或执行具有明确检查点的多步骤开发任务时,助手应应用这些模式。
灵感来源:Obra Superpowers 的结构化智能体工作流模式。
| 命令 | 用途 | 使用时机 |
|---|---|---|
/brainstorm | 生成想法和方法 | 开始新功能、探索解决方案时 |
/write-plan | 创建详细的实施计划 | 编码前、需求澄清后 |
/execute-plan | 逐步实施计划 | 计划已批准、准备编码时 |
/checkpoint |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
| 审查进度、调整计划 |
| 实施中期、主要里程碑完成后 |
/summarize | 总结收获、记录决策 | 会话结束前、上下文重置前 |
当用户请求以下内容时,助手应调用此技能:
目的:探索问题空间并生成潜在的解决方案。
/brainstorm [主题或问题]
输出:
1. 问题理解
- 我们要解决什么?
- 谁受到影响?
- 有哪些约束条件?
2. 潜在方法(3-5 个)
- 方法 A:[描述、优点、缺点]
- 方法 B:[描述、优点、缺点]
- 方法 C:[描述、优点、缺点]
3. 待解决的问题
- [需要澄清的未知事项列表]
4. 推荐方法
- [选定的方法及理由]
目的:创建详细、可操作的实施计划。
/write-plan [功能或任务]
输出:
## 实施计划:[功能名称]
### 目标
[描述结果的单句话]
### 成功标准
- [ ] 标准 1
- [ ] 标准 2
- [ ] 标准 3
### 步骤(含估算)
#### 步骤 1:[名称] (~Xh)
- 内容:[具体操作]
- 文件:[要修改/创建的文件]
- 依赖项:[必须先存在的内容]
- 验证:[如何确认完成]
### 风险与缓解措施
| 风险 | 可能性 | 影响 | 缓解措施 |
|------|-----------|--------|------------|
| 风险 1 | 中等 | 高 | 如果...则采用方案 B |
### 待解决问题
- [开始前需要解决的问题]
当计划将由多个子智能体执行时,每个任务必须明确声明其依赖项。这使协调器能够确定哪些任务可以并行运行。
### 任务依赖关系图
| 任务 ID | 名称 | depends_on | 文件 | 智能体范围 |
|---------|------|------------|-------|-------------|
| T1 | 设置数据库模式 | [] | db/schema.sql | db-engineer |
| T2 | 创建 API 路由 | [T1] | src/routes/*.ts | backend-dev |
| T3 | 构建身份验证中间件 | [T1] | src/middleware/auth.ts | backend-dev |
| T4 | 前端组件 | [] | src/components/*.tsx | frontend-dev |
| T5 | 集成测试 | [T2, T3, T4] | tests/integration/*.test.ts | qa-agent |
依赖关系图规则:
depends_on: [] 并明确指定任务 ID(空数组表示无阻塞项)。集群波次(准确性优先) — 为每个未阻塞的任务启动一个子智能体,按依赖关系分批进行。等待每批任务完成后再启动下一批。适用于生产代码和复杂的相互依赖关系。
超级集群(速度优先) — 尽可能多地同时启动子智能体,不考虑依赖关系。适用于原型和全新项目的脚手架搭建。预计会出现合并冲突。
完整的集群就绪计划模板请参见 references/planning-templates.md。
目的:通过检查点系统性地实施计划。
/execute-plan [计划引用]
执行模式:
1. 加载计划
2. 对于每个步骤:
a. 宣布:"开始步骤 X:[名称]"
b. 执行操作
c. 验证完成情况
d. 报告:"步骤 X 完成。[简要总结]"
3. 完成后:
a. 运行所有验证标准
b. 报告最终状态
对于生产编码会话,使用交付护栏包装 /execute-plan:
npm run test:analytics-gate)。./scripts/git/feature-workflow.sh start <feature-slug>
cd .worktrees/<feature-slug>
# 实施计划步骤
../../scripts/git/feature-workflow.sh gate
../../scripts/git/feature-workflow.sh pr --title "feat: <summary>"
来自生产经验的关键规则(2026 年 2 月):
完整的生产证据表和长会话检查点协议请参见 references/session-patterns.md。
在进行大规模编辑、测试或审查之前——运行 60 秒的起飞前检查:
pwd / git branch --show-current / ls -latest -e <路径> 以在执行繁重命令前验证目标路径npx <工具> --help 以在首次使用前验证标志[]、*、? 或空格的路径完整的 git/分支安全起飞前检查、端到端/服务器起飞前检查、shell 安全门和 SDK 类型验证请参见 references/operational-checklists.md。
模式:在提交前测试假设
实施前:
1. 陈述假设:"如果我们[操作],那么[预期结果]"
2. 定义实验:"为了测试这一点,我们将[最小化测试]"
3. 执行实验
4. 评估:"假设被证实/拒绝,因为[证据]"
5. 根据结果继续或调整方向
以可验证的增量构建:最小的可测试单元 → 实施并验证 → 扩大范围 → 每次扩大时验证 → 集成并验证整体。
包含 5 个增量的身份验证功能示例请参见 references/planning-templates.md。
模式:保持进度可见
[X] 步骤 1:创建数据库模式
[X] 步骤 2:实现 API 端点
[进行中] 步骤 3:添加前端表单
[ ] 步骤 4:编写测试
当前:第 3 步,共 4 步(完成 75%)
阻塞项:无
下一步:完成表单验证
限制并发工作:个人(2-3 个任务)、团队故事(团队规模 + 1)、进行中列(3-5 个项目)、代码审查(2-3 个 PR)。如果从未达到限制,则降低限制。如果经常被阻塞,则调查瓶颈。
完整的在制品限制参考和设置指南请参见 references/planning-templates.md。
对于多步骤执行,在里程碑边界处约束范围并检查点进度。
1-2 个可交付成果。在每个里程碑处记录:
当出现以下任何情况时停止并重新确定范围:
完整的范围预算模型和执行规则请参见 references/session-scope-budgeting.md。
会话已初始化。
- 项目:[名称]
- 目标:[今日目标]
- 已加载上下文:[文件、先前决策]
- 计划状态:[剩余步骤]
准备从以下位置继续:[上一个检查点]
/summarize
输出:
## 会话总结
### 已完成
- [已完成项目列表]
### 进行中
- [未完成工作的当前状态]
### 已做出的决策
- [关键决策及理由]
### 下次会话
- [ ] [下次的第一个任务]
### 需要保留的上下文
[用于连续性的关键信息]
面临选择时:
1. 清晰地陈述决策
2. 列出选项(2-4 个)
3. 对于每个选项:优点 / 缺点 / 工作量 / 风险
4. 带有理由的推荐
5. 可逆性评估
示例:
| 选项 | 优点 | 缺点 | 工作量 | 风险 |
|--------|------|------|--------|------|
| JWT | 无状态、可扩展 | 令牌管理 | 2 天 | 低 |
| 会话 | 简单、安全 | 服务器状态 | 1 天 | 低 |
| 仅 OAuth | 无密码 | 外部依赖 | 3 天 | 中等 |
推荐:MVP 使用会话,为扩展计划 JWT 迁移。
使用 TDD 的 /write-plan:
步骤 1:编写失败的测试
步骤 2:实现最小化代码
步骤 3:验证测试通过
步骤 4:重构
步骤 5:添加边缘情况测试
系统设计的 /brainstorm:
1. 需求澄清
2. 组件识别
3. 接口定义
4. 数据流映射
5. 实施计划
assets/template-dor-dod.md - 工作就绪和完成检查清单。
assets/template-work-item-ticket.md - 包含 DoR/DoD 和可测试验收标准的工单模板。
关键部分:就绪定义 / 完成定义检查清单、验收标准模板(Gherkin)、估算指南(故事点规模 1-21+)、规划级别(路线图 → 冲刺 → 任务)、跨职能 RACI。
| 反模式 | 问题 | 修复方法 |
|---|---|---|
| 无 DoR | 冲刺中期发现需求不明确 | 使用 DoR 作为冲刺入口门控 |
| 软 DoD | "完成"意味着不同的事情 | 书面 DoD 检查清单 |
| 巨型故事 | 永远无法完成,难以跟踪 | 拆分为 <8 点 |
| 缺少 AC | 构建了错误的东西 | Gherkin 格式的 AC |
| 无所有权 | 工作无人负责 | 每个史诗都有 RACI |
| 基于希望的估算 | 总是延迟 | 使用参考规模 + 缓冲 |
注意:AI 可以提供帮助,但不应取代人类在优先级和验收方面的判断。
AI 生成的标准和估算在承诺之前需要人工校准。
每周安装次数
73
仓库
GitHub 星标数
49
首次出现
2026 年 1 月 23 日
安全审计
已安装于
gemini-cli59
opencode58
codex57
cursor57
github-copilot54
claude-code49
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.
| Command | Purpose | When to Use |
|---|---|---|
/brainstorm | Generate ideas and approaches | Starting new features, exploring solutions |
/write-plan | Create detailed implementation plan | Before coding, after requirements clarification |
/execute-plan | Implement plan step-by-step | When plan is approved, ready to code |
/checkpoint | Review progress, adjust plan | Mid-implementation, after major milestones |
/summarize | Capture learnings, document decisions | End of session, before context reset |
The assistant should invoke this skill when a user requests:
Purpose : Explore the problem space and generate potential solutions.
/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]
Purpose : Create a detailed, actionable implementation plan.
/write-plan [feature or task]
OUTPUT:
## Implementation Plan: [Feature Name]
### Goal
[Single sentence describing the outcome]
### Success Criteria
- [ ] Criterion 1
- [ ] Criterion 2
- [ ] Criterion 3
### Steps (with estimates)
#### Step 1: [Name] (~Xh)
- What: [specific actions]
- Files: [files to modify/create]
- Dependencies: [what must exist first]
- Verification: [how to confirm done]
### Risks & Mitigations
| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Risk 1 | Medium | High | Plan B if... |
### Open Questions
- [Questions to resolve before starting]
When a plan will be executed with multiple subagents, each task must declare its dependencies explicitly. This enables the orchestrator to determine which tasks can run in parallel.
### Task Dependency Graph
| Task ID | Name | depends_on | Files | Agent Scope |
|---------|------|------------|-------|-------------|
| T1 | Setup database schema | [] | db/schema.sql | db-engineer |
| T2 | Create API routes | [T1] | src/routes/*.ts | backend-dev |
| T3 | Build auth middleware | [T1] | src/middleware/auth.ts | backend-dev |
| T4 | Frontend components | [] | src/components/*.tsx | frontend-dev |
| T5 | Integration tests | [T2, T3, T4] | tests/integration/*.test.ts | qa-agent |
Rules for dependency graphs:
depends_on: [] with explicit task IDs (empty array = no blockers).Swarm Waves (Accuracy-First) — Launch one subagent per unblocked task, in dependency-respecting waves. Wait for each wave to complete before launching the next. Best for production code and complex interdependencies.
Super Swarms (Speed-First) — Launch as many subagents as possible at once, regardless of dependencies. Best for prototypes and greenfield scaffolding. Expect merge conflicts.
See references/planning-templates.md for the full swarm-ready plan template.
Purpose : Implement the plan systematically with checkpoints.
/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
For production coding sessions, wrap /execute-plan with a delivery guardrail:
npm run test:analytics-gate)../scripts/git/feature-workflow.sh start <feature-slug>
cd .worktrees/<feature-slug>
# implement plan steps
../../scripts/git/feature-workflow.sh gate
../../scripts/git/feature-workflow.sh pr --title "feat: <summary>"
Key rules from production experience (Feb 2026):
See references/session-patterns.md for the full production evidence table and checkpoint protocol for long sessions.
Before broad edits, tests, or reviews — run a 60-second preflight:
pwd / git branch --show-current / ls -latest -e <path> to verify target paths before heavy commandsnpx <tool> --help to validate flags before first use[], *, ?, or spacesSee references/operational-checklists.md for the full git/branch safety preflight, E2E/server preflight, shell safety gate, and SDK type verification.
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
Build in verifiable increments: smallest testable unit → implement and verify → expand scope → verify at each expansion → integrate and verify whole.
See references/planning-templates.md for an authentication feature example with 5 increments.
PATTERN: Maintain visible progress
[X] Step 1: Create database schema
[X] Step 2: Implement API endpoints
[IN PROGRESS] Step 3: Add frontend form
[ ] Step 4: Write tests
Current: Step 3 of 4 (75% complete)
Blockers: None
Next: Complete form validation
Limit concurrent work: individual (2-3 tasks), team stories (team size + 1), in-progress column (3-5 items), code review (2-3 PRs). If limits are never reached, lower them. If constantly blocked, investigate the bottleneck.
See references/planning-templates.md for the full WIP limits reference and setting guidelines.
For multi-step execution, constrain scope and checkpoint progress at milestone boundaries.
1-2 deliverables only.At each milestone, record:
Stop and rescope when any occur:
See references/session-scope-budgeting.md for full scope budgeting model and enforcement rules.
Session initialized.
- Project: [name]
- Goal: [today's objective]
- Context loaded: [files, previous decisions]
- Plan status: [steps remaining]
Ready to continue from: [last checkpoint]
/summarize
OUTPUT:
## 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]
### Context to Preserve
[Critical information for continuity]
When faced with choices:
1. State the decision clearly
2. List options (2-4)
3. For each option: Pros / Cons / Effort / Risk
4. Recommendation with justification
5. Reversibility assessment
Example:
| 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.
/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
/brainstorm system design:
1. Requirements clarification
2. Component identification
3. Interface definition
4. Data flow mapping
5. Implementation plan
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.
Key sections: Definition of Ready / Done checklists, Acceptance Criteria templates (Gherkin), Estimation Guidelines (story point scale 1-21+), Planning Levels (Roadmap → Sprint → Task), Cross-Functional RACI.
| 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 |
Note : AI can assist but should not replace human judgment on priorities and acceptance.
AI-generated criteria and estimates require human calibration before committing to them.
Weekly Installs
73
Repository
GitHub Stars
49
First Seen
Jan 23, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
gemini-cli59
opencode58
codex57
cursor57
github-copilot54
claude-code49
开源项目教练指南 - 诊断问题、制定行动计划、优化开源项目运营
46,800 周安装
阿里云 AnalyticDB MySQL 数据库技能冒烟测试指南与自动化脚本
144 周安装
AI技能模板 - 高效构建AI助手技能,支持主流开发工具集成
145 周安装
iOS游戏开发终极指南:SpriteKit、SceneKit、RealityKit架构、性能优化与故障排除
142 周安装
Anime.js v4 中文指南:轻量级 JavaScript 动画库安装、核心概念与 API 详解
145 周安装
Claude Code 插件设置模式详解:YAML配置与本地状态管理
146 周安装
AI内部沟通助手:自动生成3P更新、公司通讯、FAQ回复、状态报告
145 周安装