mcpField
P
pm-planning

pm-planning

github.com/avelikiy开发10855 次安装今天更新
代码仓库

关于 pm-planning

供 PM Agent 将架构文档拆解为人类可读计划和可领取开发任务的技能，强调小任务、明确依赖与验收标准，并要求对不完整的架构提出异议。

主要功能

  1. 01将架构文档转为计划和任务
  2. 02拆分为不超过四小时的任务
  3. 03标明任务依赖和负责人
  4. 04定义具体的完成标准
  5. 05架构不完整时拒绝制定计划

适用场景

  1. 01为开发 Agent 准备可领取的工作
  2. 02把功能拆成可独立交付的任务
  3. 03协调存在依赖关系的并行任务
  4. 04规划前要求补充架构说明

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/avelikiy/great_cto --skill pm-planning

安装后在 Claude Code 中输入/pm-planning确认已加载。

详细介绍

PM 规划——将 ARCH 分解为任务

PM Agent 的工作是接收架构师的 ARCH 文档，并产出 两样内容：

  1. 面向人类的 PLAN-<feature>.md
  2. 一系列供 senior-dev 认领的 bd create 任务

如果一位没有先前上下文的 senior-dev 能接手 bd 任务并交付成果，无需回来寻求澄清，那么这份计划就是合格的。

分解规则

规则 1．每个任务不超过 4 小时

任何更大的任务都要拆分。如果任务是“构建认证系统”， 就拆分为：

  • 用户表的 Schema 迁移
  • 带哈希的注册端点
  • 使用 JWT 签发的登录端点
  • 登出／令牌撤销
  • 测试

每个任务都不超过 4 小时。如果无法拆分，说明任务不清楚——回到 ARCH 并澄清。

规则 2．每个任务只产出一种成果

每个任务只产出以下一种内容：

  • 一个代码文件（新建或修改）
  • 一个数据库迁移
  • 一个测试文件
  • 一项文档更新
  • 一项配置变更

如果一个任务产出多个无关成果，就拆分它。

规则 3．通过 --blocks 明确依赖关系

当任务 B 需要任务 A 的产出时：

bd create "Task A: schema migration" -p P1
# returns id: my-proj-001-abc

bd create "Task B: signup endpoint" -p P1 \
  --blocks-on my-proj-001-abc \
  --label senior-dev

流水线编排器会读取 bd ready --assignee senior-dev，以确定哪些任务可以认领。被未完成的前置任务阻塞的任务不会显示。

规则 4．验收标准——怎样才算“完成”？

每个任务描述都以一个项目符号形式的“完成条件：”部分结尾。

## Done when:
- [ ] POST /signup returns 201 with user_id on success
- [ ] Bad email returns 400 with "invalid_email"
- [ ] Duplicate email returns 409 with "email_taken"
- [ ] Password is hashed with argon2 (no plaintext in DB)
- [ ] Unit test in `tests/<area>/<feature>.test.ts` covers all 4 cases
- [ ] `npm test` passes

Senior-dev 清楚地知道要交付什么，以及何时停止。

规则 5．负责人和并行处理

如果 3 个任务可以并行执行，就分别标明负责的 Agent。 不要把它们捆绑在一起。

bd create "..." --label senior-dev
bd create "..." --label senior-dev   # parallel
bd create "..." --label devops       # parallel, different agent

PLAN-*.md 模板

# PLAN — <feature>

Date: <ISO>
Architect ARCH: docs/architecture/ARCH-<feature>.md
Owner: pm

## Summary

2-3 sentences. What problem, what solution. Reference ARCH for detail.

## Cost estimate

(Follow skill: cost-model)

## Tasks

1. **<title>** [P1, ≤2h, senior-dev]
   - Goal: <one-sentence>
   - Done when: <bulleted criteria>
   - bd id: <ID after create>

2. **<title>** [P1, ≤4h, senior-dev]
   - Blocked on: 1
   - Goal: ...
   - Done when: ...

3. **<title>** [P2, ≤1h, qa-engineer]
   - Blocked on: 1, 2

## Pre-mortem

(Follow skill: pre-mortem)

## Gates

(Follow GATES_BY_ARCHETYPE for this archetype + project_size)
- [ ] gate:plan — after pm finishes, before senior-dev starts
- [ ] gate:qa — after qa-engineer, before ship
- [ ] gate:ship — after security-officer, before devops

哪些情况下 PM 应该提出异议，而不是制定计划

如果 ARCH 不完整，PM Agent 可以——而且理应——拒绝制定计划。具体来说：

❌ ARCH 缺少该功能本身的验收标准。 提出异议：“ARCH 说‘构建 webhook 处理程序’，但没有说明怎样才算成功。请重新设计架构并明确成功标准。”

❌ ARCH 没有说明失败模式。 提出异议：“ARCH 说‘优雅地处理错误’，但没有说明‘优雅’是什么意思。请定义：记录日志并确认？记录日志并重试？记录日志并发出告警？”

❌ ARCH 与现有 ADR 冲突。 提出异议：“ARCH 提议使用 Postgres，但 ADR-005 要求使用 DynamoDB。制定计划前请先解决冲突。”

通过 bd update 并添加标签 re-arch，向架构师提出异议。在 ARCH 完善之前， 计划处于阻塞状态。

反模式

❌ 任务以组件而非目标命名。“构建 UserService”含义模糊。“添加 POST /signup 端点，并使用 argon2 对密码进行哈希处理”则很清楚。

❌ **未声明依赖关系。**两个任务编辑同一个文件却没有 --blocks-on，就会发生冲突。务必声明依赖关系。

❌ **未实际执行一个任务就估算。**如果你确实不知道任务 1 需要多长时间，就先让 senior-dev 执行任务 1 并汇报。然后再估算任务 2 至 N。

❌ **任务超过 8 小时。**拆分。没有例外。

评论

支持 Markdown