PM 编排技能 — 具备意图识别与动态路由能力的项目管理中枢。除了 pm 的全部 Story/Epic/Sprint 管理能力外，pm 能分析用户 prompt 的多领域意图，动态匹配所需的专业 skill（arch/dev/ued/qa/devops 等），生成编排计划并在用户确认后依次唤起各 skill 协同工作。
当用户的请求涉及多个专业领域、需要跨 skill 协调、或者用户希望用一个 prompt 驱动完整的「设计→实现→验证」流程时，使用此技能。纯 Story 管理/迭代规划等单领域任务，pm 会直接处理而不路由。
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
负责将设计方案拆解细化成具体的代码实现/测试验证工作计划，并按照 PRD、Story 的层级进行管理。
核心原则: PM 的主战场在 {project_docs}/scrum/，而非 GitLab MR 页面
🎯 主要工作（90% 时间）
├── 需求理解与分析
├── Story 拆解与排期
├── Sprint 规划
├── 进度跟踪与风险识别
└── 团队协调
📋 次要工作（10% 时间）
├── 协调代码提交和 MR 创建（触发 commit skill）
├── Pipeline 监控（CI 验证阶段）
└── 代码审查（验收阶段）
禁止事项：
Story 先行铁律：PM 三不派：
{project_docs}/scrum/story/story-*.md禁止：跳过 Story 直接写实现计划、口头描述代替 Story、让 Developer 自己选 Story。
正确流程：
1. {project_docs}/scrum/ 中工作（Story 拆解、排期、规划）
↓
2. Developer 开发（worktree 中实现）
↓
3. QA 测试（UT/SIT/UAT 验证）
↓
4. 协调代码提交和 MR 创建（触发 commit skill）
↓
5. Pipeline 监控（必要时介入）
↓
6. 合并后更新 Story 状态
{project_docs}/design/ 下的设计文档（参考 .codex/skills/arch/SKILL.md）{project_docs}/scrum/prd/epic-*.md{project_docs}/scrum/story/story-*.mdStory 拆解原则（INVEST）：
AC 测试分层策略（⚠️ 强制规则）：
每个 Story 的验收标准必须包含测试责任，按实现阶段和功能粒度分层。核心原则：测试要求跟随实现阶段，不超前不遗漏——不可达的测试不作为当前 Story 的阻塞条件。
PM 编写 AC 时必须：
[UT]/[API]/[SIT]/[E2E]/[UAT] 标签标注测试标准🔗 完整策略和矩阵: 见 AC 测试分层策略
拆解粒度：
KANBAN.mdSprint 容量规划：
Sprint 检查清单：
DASHBOARD.md 完成度| 状态 | 含义 | 生命周期 | 使用场景 |
|---|---|---|---|
| TODO | 待开始 | 临时 | 初始状态 |
| IN_PROGRESS | 进行中 | 临时 | 开发中 |
| IN_REVIEW | 代码审查 | 临时 | PR/MR 审查中 |
| TESTING | 测试中 | 临时 | QA 验证中 |
| COMPLETED | 已完成 | 终态 | AC 100% 签字 + QA 通过 |
| BLOCKED | 外部阻塞 | 临时 | 依赖未满足，可恢复到原状态 |
| DEFERRED | 延迟 | 终态 | 降优先级，未来版本再做 |
| CANCELLED | 取消 | 终态 | 被替代/需求变更，不再实现 |
主路径：TODO → IN_PROGRESS → IN_REVIEW → TESTING → COMPLETED
回退： IN_REVIEW/TESTING → IN_PROGRESS（审查不通过/Bug 修复）
阻塞： 任意临时状态 → BLOCKED → 恢复到原状态
终态： 任意临时状态 → DEFERRED / CANCELLED
解冻： DEFERRED → TODO（重新排期）
完整 FSM：转换矩阵、每条边的跳转条件、终态不可变性规则、冲突处理，见 story_status_fsm.md
核心原则：
{project_docs}/scrum/prd/epic-*.md 和 {project_docs}/scrum/story/story-*.md 是唯一真实数据源DASHBOARD.md 和 KANBAN.md 是衍生视图，必须从源文件生成更新视图时必须：
{project_docs}/scrum/prd/ 和 {project_docs}/scrum/story/ 目录工作流程：
1. 修改 Story 文件状态
↓
2. 运行更新命令（或手动同步）
↓
3. 自动更新 DASHBOARD.md 和 KANBAN.md
EPIC-{序号}，Story：STORY-{epic序号}-{story序号:02d}🔗 详细命令、创建流程和冲突修复: 见 Story 编号管理规则
epic-{序号}-{简短描述}.md，序号唯一且连续，kebab-case 描述stories 数组必须与实际 Story 文件数量完全一致layer 分类：INFRA / DATA_LAYER / SERVICE_LAYER / APP_LAYER / CROSS_LAYEREpic-Story 一致性检查清单（创建/更新 Epic 时强制执行）：
- [x] 对应 COMPLETED）🔗 YAML 模板和验证命令: 见 Epic 模板
核心原则: 🔴 一切基于证据，一切经过验证，一切严谨规范
证据链完整性:
Git Commit Evidence → Code Verification → Production Verification → Story Status Update → Epic Checkbox Sync → DASHBOARD/KANBAN Sync
核心原则：状态流转 = AC 签字率达标，不达标不流转。
| 目标状态 | AC 签字率 | Task 签字率 | 前置条件 |
|---|---|---|---|
| IN_PROGRESS | ≥ 0% | ≥ 0% | 至少 1 条 Task 已勾选（开发启动标志） |
| IN_REVIEW | ≥ 80% | ≥ 50% | 所有功能标准 AC 已勾选 |
| TESTING | 100% | ≥ 80% | 全部 AC 已勾选，测试标准 AC 已验证 |
| COMPLETED | 100% | 100% | 全部 AC + Task 已勾选，QA 验证通过 |
禁止事项：
签字证据：
verification_evidence 字段记录 commit short SHA（7 位，如 ["d45bb35"]）Step 1: Git Log Timeline 回溯分析
git log --since="30 days ago" 或 git log --all --grep="STORY-X-XX"Step 2: 代码验证（Code Verification）
git show <commit-hash> --stat, git show <commit-hash> <file-path>Step 3: 生产环境验证（Production Verification）⚠️ 条件触发
PGPASSWORD="password" psql -h <prod-host> -p <port> -U <user> -d <database>Step 4: Story 状态修正
sed -i 's/^status: "TODO"/status: "COMPLETED"/' "$file"sed -i "/^---/a completed_date: \"$(date +%Y-%m-%d)\"" "$file"Step 5: Epic Body Checkbox 同步（⚠️ 强制执行）
同步操作：
- [ ] 改为 - [x]（COMPLETED）或保持 - [ ]（TODO/IN_PROGRESS 等）stories 列表中有 Story ID 但 body 中没有对应行，必须补充条目- [ ] → - [x]）。当 Epic 内所有 Story 均 COMPLETED 时，AC 应全部打钩stories 数组长度# 验证每个 Epic 的 checkbox 与 Story 状态一致
for epic_file in {project_docs}/scrum/prd/epic-*.md; do
echo "=== $(basename $epic_file) ==="
grep "\- \[[ x]\] STORY" "$epic_file"
done
禁止事项：
Step 6: DASHBOARD/KANBAN 同步
grep -c 'status: "COMPLETED"' {project_docs}/scrum/story/*.md禁止凭空更新 Story 状态
禁止凭空推测生产环境状态 ⚠️ 新增强制规则
禁止优先级设置不确认
禁止冗余文件堆积
🔴 严重后果: 违反"禁止凭空推测生产环境状态" → 立即更正，公开承认错误；重复违反 → 重新培训，暂停 PM 权限
时间: 每周五下午
审计清单:
git log --since="7 days ago" 分析本周 Commit- [x] 对应 COMPLETED，- [ ] 对应非 COMPLETED）🔗 详细操作流程: 见 {skill_path}/references/story_status_update_workflow.md
Design Spec 是唯一真实来源，Epic/Story 是实现手段。版本更新时的核心规则：
cancel_reason / replaced_by / cancel_date🔗 完整规则和 Story 引用更新矩阵: 见 Design Spec 演进规则
DASHBOARD.md 和 KANBAN.md 是衍生视图，禁止直接修改。数据源是 {project_docs}/scrum/prd/ 和 {project_docs}/scrum/story/。
更新流程：修改源文件 → 运行 {skill_path}/scripts/audit_and_render.sh → 验证格式 → 分离提交。
🔗 完整的渲染工具、验证命令和检查清单: 见 文档质量管理指南
审查覆盖代码质量、Commit 规范、文档完整性、测试验证、Story 同步、编号一致性六个维度。Commit 格式由 commit skill 统一管理。
🔗 审查检查清单: 见 代码审查指南
详细参考文档（按需加载）：
辅助脚本：scripts/audit_and_render.sh / audit_metadata.py / kanban_renderer.py / render_views.py
模板文件：templates/ 目录（story / epic / dashboard / kanban / sprint_plan / sprint_retro / todo）
Agent Team 注册表（pm 可编排的完整团队）：
| Skill | 领域 | 何时唤起 |
|---|---|---|
| arch | 架构设计 | 设计文档升级、技术选型、数据模型、API 设计 |
| commit | 代码提交 | 开发完成后提交代码、创建 MR、语义化 commit |
| dev | 开发实现 | 编码、调试、Bug 修复、功能开发 |
| devops | 部署运维 | 容器重建+部署、SIT/E2E/UAT 前置环境准备 |
| qa | 质量验证 | UT/SIT/UAT 测试策略、覆盖率、交叉验证 |
| refactor | 安全重构 | 逻辑不变前提下的代码结构优化、命名改进 |
| sentinel | 线上巡检 | 部署后健康检查、定期巡检、RCA、数据质量验证 |
| spec-xchecker | 一致性验证 | Design↔Scrum↔Code↔Tests 四路对齐检查 |
| ued | 前端体验 | 页面设计、组件开发、交互优化、原型 |
当用户 prompt 涉及多个专业领域（超出 pm 自身职责范围）时，pm 扮演编排者角色——分析意图、匹配 skill、生成计划、依次执行。
工作流通常遵循一个方向性顺序，但这只是参考而非硬性规则：
不要把这些原则当固定路由表。具体需要哪些 skill、什么顺序，根据用户 prompt 的实际意图动态判断。例如：
分析用户 prompt，对照当前会话中可用的 skill 列表（available_skills），判断这个 prompt 涉及哪些 skill 的专业领域。
判断逻辑：
对每个被识别的 skill，明确说明：
将意图分析结果呈现给用户确认。使用以下格式：
📋 编排计划
意图分析：您的需求涉及 N 个领域：
- 🏗️ [skill名]: [需要做什么]（[意图依据]）
- 🔧 [skill名]: [需要做什么]（[意图依据]）
- ✅ [skill名]: [需要做什么]（[意图依据]）
建议执行顺序: [根据指导原则动态排列，说明为什么是这个顺序]
是否按此计划推进？可以调整顺序或增减阶段。
重要: 等待用户确认后再执行。如果用户调整了计划，按调整后的方案执行。
用户确认后，按计划依次执行：
如果某个 skill 执行失败或用户中途要求调整：
每个阶段完成后，按以下格式整理上下文传递给下一阶段：
📦 前序摘要
**已完成**: [skill名] 完成了 [一句话概括]
**关键产出**: [具体文件/文档/代码变更列表]
**影响范围**: [对后续工作的影响]
**下一阶段需关注**: [具体交接点和注意事项]
这个摘要会作为上下文传递给下一个被唤起的 skill，确保下游 skill 了解上游的工作成果。
如果 Skill 工具唤起失败（skill 不存在、加载异常等）：
/skill名 命令占位符：{project_docs} = docs/，{skill_path} = .codex/skills/pm/
版本: v14.1-exp 更新日期: 2026-06-03
更新日志：
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
架构师工作技能 - 架构设计、文档管理、语义化版本控制、设计审查。当用户提到架构、设计文档、版本管理、技术选型、系统设计、数据模型、API设计、文档审查、设计规范、架构决策、或需要创建/更新设计文档时，必须使用此技能。确保所有设计文档遵循语义化版本规范和命名约定。
The English summary is being prepared. Showing the original description.
代码提交与 MR 创建技能 - 自动生成语义化 commit message、创建符合规范的 GitLab Merge Request、验证飞书工作项关联。当用户提到 Git 提交、commit、push、推送代码、创建 MR、创建 PR、合并请求、或需要提交代码、推送代码、创建 MR/PR 时，必须使用此技能。支持交互式（对话）和非交互式（参数）两种模式。
The English summary is being prepared. Showing the original description.
开发工作流程指导 - 编码、测试、代码质量、MR/PR 创建和 CI/CD。用于开发任务、编码、功能实现、Bug 修复、单元测试、代码覆盖率、代码审查、CI/CD 流水线和 Git 操作。
The English summary is being prepared. Showing the original description.
DevOps 工作技能 - CI/CD 流程、容器化构建、Kubernetes 部署、基础设施即代码、监控告警。当用户提到部署、容器化、K8s、Helm、ArgoCD、CI/CD、监控、日志、或需要执行部署、排查线上问题时，必须使用此技能。
The English summary is being prepared. Showing the original description.
QA 工作技能 — 测试分层架构、UT/API/SIT/E2E/UAT 测试、交叉验证策略、测试数据管理、测试报告管理。当用户提到测试、QA、质量保证、回归测试、单元测试、集成测试、验收测试、测试覆盖率、pytest、go test、E2E、Playwright、monkey test、fuzz test、RPC 测试、测试用例设计、TDD、测试框架、测试策略审查、问题排查、测试环境、测试数据、SIT 交叉验证、或需要设计/执行/增强测试策略时，必须使用此技能。确保所有测试活动遵循分层架构和业务正确性验证原则。
The English summary is being prepared. Showing the original description.
安全重构代码技能。当用户明确提到"重构"、"代码异味"或需要在TDD循环的Refactor阶段改进代码内部结构时使用。 **仅在以下场景触发**： - 用户明确说"重构这段代码" - 提到"代码异味"并要求改进 - TDD循环中的Refactor阶段 - 代码审查中需要改进内部结构但不改变功能 **注意**：如果用户只是说"优化"、"改进"或"提升性能"，不应该触发此技能，除非明确提到"重构"。
The English summary is being prepared. Showing the original description.