Git PR 多智能体工作流

问题背景

从本地改完代码到 PR 可合并，中间往往散落着风格与安全审查、破坏性变更梳理、测试与覆盖率、Conventional Commits 文案、分支策略以及 PR 描述与元数据配置。若全靠人工串这些步骤，容易漏检、上下文在工具之间断裂，或在未就绪时就把变更推上远程。

技能如何工作

本技能把上述链路编排成 五个阶段，各阶段通过 Task 调用不同 subagent_type，并把上一阶段的结构化输出写入下一阶段提示词。

1. 提交前审查与分析：code-reviewer 对未提交变更做质量评估（JSON 报告含严重级别）；再次用审查智能体做依赖与破坏性变更分析。
2. 测试与验证：unit-testing::test-automator 跑单元/集成/E2E（视情况），产出覆盖率与失败清单；随后做测试差距与补充场景建议。
3. 提交信息生成：审查智能体按 Conventional Commits 做变更分类与是否拆提交的建议；llm-application-dev::prompt-engineer 生成符合规范的 subject/body/BREAKING CHANGE。
4. 分支策略与推送准备：cicd-automation::deployment-engineer 按 --trunk-based 或默认 --feature-branch 准备分支与冲突检查，并做推送前终检（敏感信息、分支保护、审查项是否闭环）。
5. Pull Request 创建：documentation-generation::docs-architect 写 GitHub 风格 PR 描述；部署工程师智能体配置 reviewer、标签、关联 issue、合并策略与 --draft-pr 等。

可配置项包括目标分支（默认 main）、--skip-tests、--no-push、--squash、--conventional 等。文档中还定义了 成功标准（关键/高严重问题已处理、测试通过、覆盖率目标、无冲突、PR 完整等）以及合并后的 回滚流程（git revert、功能开关、热修复分支等）。

适用边界

• 任务必须与「多智能体编排的完整 Git 工作流」相关；纯领域问题或无关工具不在范围内。
• --skip-tests 仅应在明确知情下使用；工作流假设运行环境已具备对应 Task/subagent 能力。
• 更细的示例与 playbook 见技能内 resources/implementation-playbook.md，本介绍不替代逐步执行说明。