Project management
AI 编程助手的专业技能库，涵盖 30+ 技能，按 6 类组织
npx -y skills add morning-start/agent-skills --skill project-managementAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
全流程项目管理母技能，整合需求拆解、任务排期、技术设计、编码测试、测试验收、发布部署六大子技能 + 规划子技能（ROADMAP/TODO/OKR），覆盖软件项目从规划到上线的完整生命周期。适用于新项目启动、阶段性推进和问题诊断。
SKILL.md
7.3 KB, ~2.5k tokens by cl100k_base, as published. Nobody here has run it
项目全流程管理
任务目标
- 本 Skill 用于: 软件项目全生命周期管理，从需求澄清到正式发布
- 能力包含: 六大阶段标准化流程、状态管理、决策检查点
- 触发条件: 新项目启动、项目中途介入、阶段性问题诊断
核心流程
需求拆解 → 任务排期 → 技术设计 → 编码测试 → 测试验收 → 发布部署
子技能索引
| 阶段 | 子技能 | 核心职责 | 参考文档 |
|---|---|---|---|
| 规划 | planning/1-roadmap-planner | ROADMAP/OKR/里程碑 | 详情 |
| 规划 | planning/2-todo-planner | TODO/优先级/MoSCoW | 详情 |
| 需求 | requirement-decomposition | 澄清→拆解→验证 | 详情 |
| 计划 | task-scheduling | 工时评估、任务认领 | 详情 |
| 设计 | tech-design | 数据库、API、UI | 详情 |
| 开发 | coding-unit-test | 开发规范、单元测试 | 详情 |
| 测试 | testing-acceptance | 提测、Bug、UAT | 详情 |
| 发布 | release-deployment | 灰度、回滚、监控 | 详情 |
操作步骤
阶段推进流程
标准流程:
- 进入阶段: 根据项目当前状态进入对应阶段
- 调用子技能: 调用该阶段的子技能执行具体任务
- 阶段评审: 执行关键决策点检查
- 状态更新: 确认通过后进入下一阶段
阶段1：需求阶段
- 触发条件: 用户提出模糊需求（如"做一个商城系统"）
- 使用技能: requirement-decomposition
- 操作: 澄清需求 → 拆解需求 → 验证需求
- 输出: 用户故事列表、验收标准、任务清单
- 决策点: 需求评审 - 需求是否清晰无歧义？
- 下一步: 通过 → 阶段2；未通过 → 继续澄清
阶段2：计划阶段
- 触发条件: 需求已确认，准备进入开发
- 使用技能: task-scheduling
- 操作: 工时评估 → 任务认领 → Sprint规划
- 输出: 工时评估表、Sprint计划
- 决策点: 计划评审 - 任务分配是否合理？
- 下一步: 通过 → 阶段3；未通过 → 重新调整
阶段3：设计阶段
- 触发条件: Sprint计划已确定，开发前准备
- 使用技能: tech-design
- 操作: UI设计 → 技术架构 → 接口约定
- 输出: ER图、API文档、技术选型表
- 决策点: 技术评审 - 技术方案是否可行？
- 下一步: 通过 → 阶段4；未通过 → 重新设计
阶段4：开发阶段
- 触发条件: 设计文档已确认
- 使用技能: coding-unit-test
- 操作: 并行开发 → 单元测试 → Code Review
- 输出: 源代码、测试报告
- 日常流程: 每日站会同步进度
- 决策点: 代码评审 - 代码是否符合规范？
- 下一步: 通过 → 阶段5；未通过 → 修复
阶段5：测试阶段
- 触发条件: 开发完成，准备提测
- 使用技能: testing-acceptance
- 操作: 提测 → 系统测试 → Bug修复 → UAT
- 输出: 测试用例、Bug记录、UAT报告
- 决策点: 测试评审 - 测试是否全部通过？
- 下一步: 通过 → 阶段6；未通过 → 继续修复
阶段6：发布阶段
- 触发条件: 测试全部通过
- 使用技能: release-deployment
- 操作: 发布准备 → 灰度发布 → 正式发布 → 监控
- 输出: 发布checklist、回滚方案、监控报告
- 决策点: 发布评审 - 是否满足发布条件？
- 下一步: 通过 → 项目完成
状态管理
项目状态矩阵
项目状态:
☐ 需求阶段 - requirement-decomposition 已完成
☐ 计划阶段 - task-scheduling 已完成
☐ 设计阶段 - tech-design 已完成
☐ 开发阶段 - coding-unit-test 已完成
☐ 测试阶段 - testing-acceptance 已完成
☐ 发布完成 - release-deployment 已完成
当前阶段: [根据实际进度标记]
状态转换规则
| 当前状态 | 可转向 | 条件 |
|---|---|---|
| 需求阶段 | 计划阶段 | 需求评审通过 |
| 计划阶段 | 设计阶段 | 计划评审通过 |
| 设计阶段 | 开发阶段 | 技术评审通过 |
| 开发阶段 | 测试阶段 | 代码评审通过 |
| 测试阶段 | 发布阶段 | 测试评审通过 |
| 任意阶段 | 需求阶段 | 重大需求变更 |
决策检查点
| 决策点 | 评审问题 | 通过标准 | 负责人 |
|---|---|---|---|
| 需求评审 | 需求是否清晰无歧义？ | 验收标准已定义 | 产品经理 |
| 计划评审 | 任务分配是否合理？ | 工时评估完成 | 技术负责人 |
| 技术评审 | 技术方案是否可行？ | 架构设计通过 | 技术负责人 |
| 代码评审 | 代码是否符合规范？ | Review通过 | 技术负责人 |
| 测试评审 | 测试是否全部通过？ | P0/P1 Bug已清零 | QA负责人 |
| 发布评审 | 是否满足发布条件？ | Checklist全部通过 | 项目经理 |
资源索引
- 子技能文档: 见上方子技能索引表
- 需求拆解参考: requirement-decomposition
- 任务排期参考: task-scheduling
- 技术设计参考: tech-design
- 编码测试参考: coding-unit-test
- 测试验收参考: testing-acceptance
- 发布部署参考: release-deployment
注意事项
- 阶段推进必须经过决策检查点，不可跳过
- 重大需求变更时允许回退到上一阶段
- 每个阶段产出物必须归档后再进入下一阶段
- 阻塞问题应在每日站会中及时暴露
使用示例
示例1：新项目启动
用户: 帮我做一个奶茶店点单系统
1. 进入【需求阶段】
→ 调用 requirement-decomposition
→ 输出: 用户故事、验收标准、任务清单
2. 进入【计划阶段】
→ 调用 task-scheduling
→ 输出: Sprint计划、任务分配
3. 后续阶段按需调用对应子技能...
示例2：项目中途介入
用户: 项目卡在测试阶段，不知道怎么推进
1. 诊断当前状态
→ 项目状态: 测试阶段
2. 调用对应子技能
→ 调用 testing-acceptance
→ 继续测试流程
3. 推进到下一阶段...
示例3：问题诊断
用户: 开发效率低，总是返工
1. 诊断问题阶段
→ 可能是设计阶段或开发阶段问题
2. 检查对应阶段产出物
→ tech-design: 接口文档是否清晰？
→ coding-unit-test: Code Review是否执行？
3. 针对问题调用子技能优化