# Git Pr Workflows Git Workflow > 编排从代码审查到 PR 创建的完整 git 工作流，利用专业智能体进行质量保证、测试和部署就绪检查。当用户要求'git工作流'、'PR创建'、'代码审查流程'或'多智能体编排git操作'时使用。 - Skill: `kscz0000/git-pr-workflows-git-workflow` (Agent Skill) - Install (CLI): `npx skillmds@latest add kscz0000/git-pr-workflows-git-workflow` - Raw SKILL.md: https://api.skillmd.com/api/skills/kscz0000/git-pr-workflows-git-workflow/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Productivity - Author: kscz0000 (https://skillmd.com/u/kscz0000) - Updated: 2026-09-21 - Page: https://skillmd.com/skills/kscz0000/git-pr-workflows-git-workflow --- # 完整 Git 工作流与多智能体编排 编排从代码审查到 PR 创建的完整 git 工作流，利用专业智能体进行质量保证、测试和部署就绪检查。本工作流实现了现代 git 最佳实践，包括 Conventional Commits、自动化测试和结构化 PR 创建。 [扩展思考：本工作流协调多个专业智能体，确保代码在提交前通过质量检查。code-reviewer 智能体执行初始质量检查，test-automator 确保所有测试通过，deployment-engineer 验证生产就绪状态。通过顺序编排这些智能体并传递上下文，我们在保持高效率的同时防止有问题的代码进入仓库。工作流支持 trunk-based 和 feature-branch 两种策略，具有可配置选项以适应不同团队需求。] ## 使用本技能的时机 - 处理涉及多智能体编排的完整 git 工作流任务或工作流 - 需要完整 git 工作流与多智能体编排的指导、最佳实践或检查清单 ## 不使用本技能的时机 - 任务与完整 git 工作流及多智能体编排无关 - 需要此范围之外的其他领域或工具 ## 指令 - 明确目标、约束和所需输入。 - 应用相关最佳实践并验证结果。 - 提供可执行的步骤和验证方法。 - 如需详细示例，请打开 `resources/implementation-playbook.md`。 ## 配置 **目标分支**: $ARGUMENTS（如未指定则默认为 'main'） **支持的标志**: - --skip-tests: 跳过自动化测试执行（谨慎使用） - --draft-pr: 将 PR 创建为草稿，用于进行中的工作 - --no-push: 执行所有检查但不推送到远程 - --squash: 推送前压缩提交 - --conventional: 严格强制 Conventional Commits 格式 - --trunk-based: 使用 trunk-based 开发工作流 - --feature-branch: 使用 feature branch 工作流（默认） ## 阶段 1：提交前审查与分析 ### 1. 代码质量评估 - 使用 Task 工具，subagent_type="code-reviewer" - 提示词："审查所有未提交的更改以发现代码质量问题。检查：1) 代码风格违规，2) 安全漏洞，3) 性能问题，4) 缺失的错误处理，5) 不完整的实现。生成包含严重程度级别（critical/high/medium/low）的详细报告，并提供具体的逐行反馈。输出格式：JSON，结构为 {issues: [], summary: {critical: 0, high: 0, medium: 0, low: 0}, recommendations: []}" - 预期输出：结构化代码审查报告，供下一阶段使用 ### 2. 依赖与破坏性变更分析 - 使用 Task 工具，subagent_type="code-reviewer" - 提示词："分析更改中的：1) 新依赖或版本变更，2) 破坏性 API 变更，3) 数据库模式修改，4) 配置变更，5) 向后兼容性问题。来自上一审查的上下文：[插入问题摘要]。识别任何需要迁移脚本或文档更新的变更。" - 来自上一阶段的上下文：可能表明破坏性变更的代码质量问题 - 预期输出：破坏性变更评估和迁移需求 ## 阶段 2：测试与验证 ### 1. 测试执行与覆盖率 - 使用 Task 工具，subagent_type="unit-testing::test-automator" - 提示词："为修改的代码执行所有测试套件。运行：1) 单元测试，2) 集成测试，3) 端到端测试（如适用）。生成覆盖率报告并识别任何未测试的代码路径。基于审查问题：[插入 critical/high 问题]，确保测试覆盖问题区域。提供测试结果，格式为：{passed: [], failed: [], skipped: [], coverage: {statements: %, branches: %, functions: %, lines: %}, untested_critical_paths: []}" - 来自上一阶段的上下文：需要测试覆盖的关键代码审查问题 - 预期输出：完整测试结果和覆盖率指标 ### 2. 测试建议与缺口分析 - 使用 Task 工具，subagent_type="unit-testing::test-automator" - 提示词："基于测试结果 [插入摘要] 和代码更改，识别：1) 缺失的测试场景，2) 未覆盖的边界情况，3) 需要验证的集成点，4) 需要的性能基准。按风险优先级生成测试实现建议。考虑已识别的破坏性变更：[插入破坏性变更]。" - 来自上一阶段的上下文：测试结果、破坏性变更、未测试路径 - 预期输出：按优先级排序的额外测试需求列表 ## 阶段 3：提交信息生成 ### 1. 变更分析与分类 - 使用 Task 工具，subagent_type="code-reviewer" - 提示词："分析所有更改并根据 Conventional Commits 规范进行分类。识别主要变更类型（feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert）和范围。对于更改：[插入文件列表和摘要]，确定这应该是单个提交还是多个原子提交。考虑测试结果：[插入测试摘要]。" - 来自上一阶段的上下文：测试结果、代码审查摘要 - 预期输出：提交结构建议 ### 2. Conventional Commit 信息创建 - 使用 Task 工具，subagent_type="llm-application-dev::prompt-engineer" - 提示词："基于分类创建 Conventional Commits 格式的信息：[插入分类]。格式：(): ，空行后是 解释做了什么和为什么（不是怎么做），然后是