" --body "<body>" * 如果已经在功能分支上，请跳过 `git checkout -b` * 检查 PR 是否存在： `agent-tools-gh pr status` （自动检测当前分支或 GitButler 工作区的 PR） * 如果 PR 存在，请使用 `agent-tools-gh pr edit --pr <pr_number> --title "<title>" --body "<body>"` 而不是 `agent-tools-gh pr create` * 基础分支：用户提供的参数（默认：`test`） * 分支命名：根据变化`feat/`、`fix/`、`chore/` #### 公关正文格式 ## 总结 <1-2句话> ## 变化 - <项目符号列表> ### 提交消息标准 **每次提交都必须使用正确的常规提交来描述实际更改，而不是像“地址审查反馈”或“修复 CI”这样的元描述。** 格式：`<类型>（<范围>）：<实际更改的内容>` * `type`：`fix`、`feat`、`refactor`、`perf`、`style`、`chore` 等。 * `scope`：受影响的模块/区域（例如，`auth`、`db`、`ui`、`api`） * `message`：描述具体的改变，而不是你提交的原因 **好的例子：** * `修复（auth）：在重定向之前添加会话令牌的空检查` * `refactor(api)：将验证逻辑提取到共享中间件中` * `fix(db): 修正用户查询中的 JOIN 条件` * `perf(search): 在created_at上添加索引以加快查找速度` * `style(ui): 在侧边栏导航中对齐间距` **不好的例子（永远不要使用这些）：** * ~~`修复：解决评论反馈`~~ * ~~`修复：解决 CI 检查失败问题`~~ * ~~`修复：解决克劳德公关反馈问题`~~ * ~~`杂务：解决问题`~~ 如果单个提交涉及不同范围内的多个审阅评论，请针对每个范围进行**单独提交**，而不是一揽子提交。 ### 第 2 阶段：主动监视循环 ** PR 创建/更新后，立即进入活动监视循环。无需暂停，无需等待用户输入。** 通知用户：“PR 创建/更新。进入活动监视循环 - 监控 CI 和评论。（说‘停止’退出）” ** ** #### 循环开始 ##### 第 1 步：观看 CI 检查等待所有 CI 检查完成： agent-tools-gh pr 检查 --pr <pr_number> --watch --fail-fast > /dev/null 2>&1;回声$？ **退出代码：** `0` = 全部通过，`1` = 检测到失败。 “--fail-fast”标志在第一次失败时立即退出，以加快迭代速度。 ##### 步骤 2：处理 CI 结果 **如果检查失败（退出代码 1）：** 1. 立即获取失败检查详细信息： agent-tools-gh pr 检查失败 --pr <pr_number> 2. 要进行更深入的 CI 日志分析，请为失败的作业获取干净的解析日志： agent-tools-gh 工作流程作业日志 --run <run_id> --job "<job_name>" --failed-steps-only 3.从日志中分析错误 4. **在本地修复问题** — 不要问，只需修复 5. 运行验证：包子运行检查 6. 提交并推送： git add -A && git commit -m "<常规提交消息>" && git Push origin HEAD 7. 如果失败看起来不稳定（例如超时、网络问题），请考虑重新运行而不是修复： agent-tools-gh pr 重新运行检查 --pr <pr_number> --failed-only 8. **→ 返回循环开始** **如果检查通过（退出代码 0）：** 继续执行步骤 3。 ##### 第 3 步：检查评论和评论立即运行完整的分类： agent-tools-gh pr 审查分类 --pr <pr_number> 然后检查每个反馈来源： **3.1 内联审核线程：** agent-tools-gh pr 线程 --pr <pr_number> --unresolved-only 每个线程包括“threadId”、“commentId”、“path”、“line”和“body”。 **3.2 AI审稿人问题评论**（Claude bot、Sentry Seer等）： agent-tools-gh pr 讨论摘要 --pr <pr_number> agent-tools-gh pr issues-comments-latest --pr <pr_number> --author claude --body-contains“克劳德代码审查” agent-tools-gh pr 问题评论最新 --pr <pr_number> --author sentry-io --body-contains“哨兵” AI 审阅者将调查结果发布为一般 PR 评论，其中包含严重性标记的项目（严重、主要、次要）、特定文件路径和行号以及代码建议。解析评论正文以提取可操作的项目。 **3.3 决定：** * **如果没有未解决的话题，也没有可操作的 AI 评论 →** PR 是干净的。 **→ 转到循环退出** * **如果发现任何反馈 →** 继续执行步骤 4 ##### 第 4 步：立即处理每条评论对于每条评论/发现： 1. **读取文件**中提到的特定行 2. **理解建议** — 要求进行哪些更改？ 3. **评估并采取行动：** * **自动应用**（无需确认）：拼写错误、样式修复、缺失类型、导入清理、明显错误、性能改进、与 CLAUDE.md 约定匹配的安全修复 * **根据判断应用**：重构建议，提高清晰度、错误处理、命名改进 * **首先询问用户**：删除功能、更改公共 API 签名、与现有模式相矛盾、建议不明确 4. **立即修复** — 跟踪更改的内容以及原因 ##### 步骤 5：回复评论并解决话题 **关键：每个线程在解决之前都必须有回复。** 首先，确定所有需要回复的线程： agent-tools-gh pr 线程 --pr <pr_number> agent-tools-gh 公关评论 --pr <pr_number> 只有 1 条评论的主题（原始）需要添加回复。 **回复每个帖子**（包括已经解决的缺少回复的帖子）：对于内联线程 - 使用快捷方式一步回复和解决： agent-tools-gh pr 回复和解析 --pr <pr_number> --comment-id <comment_id> --thread-id <thread_id> --body "<response>" 或者单独回复再解决： agent-tools-gh pr 回复 --pr <pr_number> --comment-id <comment_id> --body "<响应>" agent-tools-gh pr 解析 --thread-id <thread_id> 对于一般公关评论： agent-tools-gh pr 注释 --pr <pr_number> --body "<响应>" **回复格式：** * **如果已修复**：“已解决 - [更改内容的简要描述]” * **如果不适用** ：“不适用 - [简要解释原因]” * **如果积极反馈** ：“感谢您的反馈！”或类似的确认 * **如果需要讨论** ：“问题：[要求澄清]” **如果回复失败并出现“待审核”错误：** 首先提交待审核，然后重试： agent-tools-gh pr 提交审核 --pr <pr_number> **不要解决**您提出问题的线程。 ##### 第 6 步：验证并推送包子运行检查修复任何新问题。然后提交并推送： git add -A && git commit -m "<常规提交消息>" && git Push origin HEAD **→ 返回循环开始** ** ** #### 循环退出当到达这里时（所有检查都通过+没有未解决的评论）：通知用户：“所有 CI 检查均已通过。所有审核意见均已处理。PR 已准备好接受审核！🎉” #### 循环退出条件在以下情况下退出监视循环： * **所有检查均通过且没有未解决的反馈** — 自然退出 * **用户说“停止”**或请求退出 * **达到最大 10 次迭代** — 询问用户是否要继续 ** ** ## 推送工作流程通过一个命令提交所有更改并推送到当前分支。＃＃＃指示将所有内容作为一个链接命令运行，以便用户仅批准一次： git add -A && git commit -m "<msg>" && git Push origin HEAD * 提交消息：常规提交（`feat:`、`fix:`、`chore:` 等） * 如果没有改变，则跳过 ** ** ## 分支工作流程从基础创建一个新的功能分支，保留当前的更改。 * 基础分支：用户提供的参数，如果未提供则为“test” * 分支命名：根据变化`feat/`、`fix/`、`chore/` * 从更改中推断分支名称或询问用户 ### 说明 **如果有未提交的更改：** 但 oplog snapshot -m “分支切换之前” && git checkout <base> && git pull origin <base> && git checkout -b <branch-name> && 但 oplog 恢复注意：“but oplog snapshot/restore”是“git stash”（在 GitButler 工作区中被禁止）的 GitButler 安全替代品。 **如果工作树是干净的：** git checkout <基础> && git pull origin <基础> && git checkout -b <分支名称> ** ** ## 同步分支工作流程合并所有环境分支，以便 test、prod 和 main 指向同一提交。 ### 第 1 步：安全快照和拆卸但是 oplog snapshot -m“预同步安全” 但拆解如果拆卸失败并显示“未找到活动分支”，请手动检查测试： git 结帐测试 ### 第 2 步：检查测试并拉取 git 结帐测试 git pull 原点测试 ### 步骤 3：将 prod 和 main 合并到测试中 git fetch origin prod main git fetch origin prod main git merge origin/prod --no-edit git merge origin/main --no-edit git merge origin/main --no-edit 如果发生冲突，请使用“--theirs”（首选传入）解决，并仅在冲突不明确时询问用户： git checkout --theirs <冲突文件> git add <冲突文件> git commit --无编辑 ### 步骤 4：推送测试 git推送原点测试 ### 步骤 5：从测试中快进生产 git fetch origin 测试 prod main git checkout 产品 git pull origin 产品 git merge origin/test --no-edit git Push 原始产品 ### 步骤 6：从 prod 快进 main git fetch origin 测试 prod main git checkout 主要 git pull origin 主要 git merge origin/prod --no-edit git推送原点主要 ### 第 7 步：验证同步 git fetch origin 测试 prod main echo“测试：$(git rev-parse origin/test)” echo“产品：$（git rev-parse origin / prod）” echo“主要：$（git rev-parse origin / main）” 所有三个都必须显示相同的 SHA。如果没有，请调查并修复。 ### 步骤 8：返回 GitButler 工作区 git 结帐测试但设置 ### 约束 * **始终在拆卸前创建快照** — 保护未提交的工作区文件 * **始终使用`--no-edit`**进行合并提交——没有交互式编辑器 * **始终在 git 命令之前设置非交互式环境变量**（`GIT_MERGE_AUTOEDIT=no`、`GIT_PAGER=cat` 等） * **永远不要强制推送** - 所有合并都应该是快进或常规合并 * **切勿跳过验证**（步骤 7）— 返回工作区之前确认所有 SHA 匹配 ### 输出报告最终状态：分支已同步到 <SHA> 测试：<SHA> 产品：<SHA> 主要：<SHA></article></body></html>

# Git 工作流程公关生命周期自动化。创建 PR → 观察 → 修复 → 地址 → 推送 → 重复直到绿色。 ## 公关工作流程 **触发器**：用户说“pr” 整个公关生命周期作为一个连续的积极循环运行。没有单独的“修复评论”步骤——这都是一个工作流程。 ### 第 1 阶段：创建或更新 PR 将所有内容作为一个链接命令运行，以便用户仅批准一次： git checkout -b && git add -A && git commit -m "" && git push -u origin HEAD && agent-tools-gh pr create --base --title "" --body "<body>" * 如果已经在功能分支上，请跳过 `git checkout -b` * 检查 PR 是否存在： `agent-tools-gh pr status` （自动检测当前分支或 GitButler 工作区的 PR） * 如果 PR 存在，请使用 `agent-tools-gh pr edit --pr <pr_number> --title "<title>" --body "<body>"` 而不是 `agent-tools-gh pr create` * 基础分支：用户提供的参数（默认：`test`） * 分支命名：根据变化`feat/`、`fix/`、`chore/` #### 公关正文格式 ## 总结 <1-2句话> ## 变化 - <项目符号列表> ### 提交消息标准 **每次提交都必须使用正确的常规提交来描述实际更改，而不是像“地址审查反馈”或“修复 CI”这样的元描述。** 格式：`<类型>（<范围>）：<实际更改的内容>` * `type`：`fix`、`feat`、`refactor`、`perf`、`style`、`chore` 等。 * `scope`：受影响的模块/区域（例如，`auth`、`db`、`ui`、`api`） * `message`：描述具体的改变，而不是你提交的原因 **好的例子：** * `修复（auth）：在重定向之前添加会话令牌的空检查` * `refactor(api)：将验证逻辑提取到共享中间件中` * `fix(db): 修正用户查询中的 JOIN 条件` * `perf(search): 在created_at上添加索引以加快查找速度` * `style(ui): 在侧边栏导航中对齐间距` **不好的例子（永远不要使用这些）：** * ~~`修复：解决评论反馈`~~ * ~~`修复：解决 CI 检查失败问题`~~ * ~~`修复：解决克劳德公关反馈问题`~~ * ~~`杂务：解决问题`~~ 如果单个提交涉及不同范围内的多个审阅评论，请针对每个范围进行**单独提交**，而不是一揽子提交。 ### 第 2 阶段：主动监视循环 ** PR 创建/更新后，立即进入活动监视循环。无需暂停，无需等待用户输入。** 通知用户：“PR 创建/更新。进入活动监视循环 - 监控 CI 和评论。（说‘停止’退出）” ** ** #### 循环开始 ##### 第 1 步：观看 CI 检查等待所有 CI 检查完成： agent-tools-gh pr 检查 --pr <pr_number> --watch --fail-fast > /dev/null 2>&1;回声$？ **退出代码：** `0` = 全部通过，`1` = 检测到失败。 “--fail-fast”标志在第一次失败时立即退出，以加快迭代速度。 ##### 步骤 2：处理 CI 结果 **如果检查失败（退出代码 1）：** 1. 立即获取失败检查详细信息： agent-tools-gh pr 检查失败 --pr <pr_number> 2. 要进行更深入的 CI 日志分析，请为失败的作业获取干净的解析日志： agent-tools-gh 工作流程作业日志 --run <run_id> --job "<job_name>" --failed-steps-only 3.从日志中分析错误 4. **在本地修复问题** — 不要问，只需修复 5. 运行验证：包子运行检查 6. 提交并推送： git add -A && git commit -m "<常规提交消息>" && git Push origin HEAD 7. 如果失败看起来不稳定（例如超时、网络问题），请考虑重新运行而不是修复： agent-tools-gh pr 重新运行检查 --pr <pr_number> --failed-only 8. **→ 返回循环开始** **如果检查通过（退出代码 0）：** 继续执行步骤 3。 ##### 第 3 步：检查评论和评论立即运行完整的分类： agent-tools-gh pr 审查分类 --pr <pr_number> 然后检查每个反馈来源： **3.1 内联审核线程：** agent-tools-gh pr 线程 --pr <pr_number> --unresolved-only 每个线程包括“threadId”、“commentId”、“path”、“line”和“body”。 **3.2 AI审稿人问题评论**（Claude bot、Sentry Seer等）： agent-tools-gh pr 讨论摘要 --pr <pr_number> agent-tools-gh pr issues-comments-latest --pr <pr_number> --author claude --body-contains“克劳德代码审查” agent-tools-gh pr 问题评论最新 --pr <pr_number> --author sentry-io --body-contains“哨兵” AI 审阅者将调查结果发布为一般 PR 评论，其中包含严重性标记的项目（严重、主要、次要）、特定文件路径和行号以及代码建议。解析评论正文以提取可操作的项目。 **3.3 决定：** * **如果没有未解决的话题，也没有可操作的 AI 评论 →** PR 是干净的。 **→ 转到循环退出** * **如果发现任何反馈 →** 继续执行步骤 4 ##### 第 4 步：立即处理每条评论对于每条评论/发现： 1. **读取文件**中提到的特定行 2. **理解建议** — 要求进行哪些更改？ 3. **评估并采取行动：** * **自动应用**（无需确认）：拼写错误、样式修复、缺失类型、导入清理、明显错误、性能改进、与 CLAUDE.md 约定匹配的安全修复 * **根据判断应用**：重构建议，提高清晰度、错误处理、命名改进 * **首先询问用户**：删除功能、更改公共 API 签名、与现有模式相矛盾、建议不明确 4. **立即修复** — 跟踪更改的内容以及原因 ##### 步骤 5：回复评论并解决话题 **关键：每个线程在解决之前都必须有回复。** 首先，确定所有需要回复的线程： agent-tools-gh pr 线程 --pr <pr_number> agent-tools-gh 公关评论 --pr <pr_number> 只有 1 条评论的主题（原始）需要添加回复。 **回复每个帖子**（包括已经解决的缺少回复的帖子）：对于内联线程 - 使用快捷方式一步回复和解决： agent-tools-gh pr 回复和解析 --pr <pr_number> --comment-id <comment_id> --thread-id <thread_id> --body "<response>" 或者单独回复再解决： agent-tools-gh pr 回复 --pr <pr_number> --comment-id <comment_id> --body "<响应>" agent-tools-gh pr 解析 --thread-id <thread_id> 对于一般公关评论： agent-tools-gh pr 注释 --pr <pr_number> --body "<响应>" **回复格式：** * **如果已修复**：“已解决 - [更改内容的简要描述]” * **如果不适用** ：“不适用 - [简要解释原因]” * **如果积极反馈** ：“感谢您的反馈！”或类似的确认 * **如果需要讨论** ：“问题：[要求澄清]” **如果回复失败并出现“待审核”错误：** 首先提交待审核，然后重试： agent-tools-gh pr 提交审核 --pr <pr_number> **不要解决**您提出问题的线程。 ##### 第 6 步：验证并推送包子运行检查修复任何新问题。然后提交并推送： git add -A && git commit -m "<常规提交消息>" && git Push origin HEAD **→ 返回循环开始** ** ** #### 循环退出当到达这里时（所有检查都通过+没有未解决的评论）：通知用户：“所有 CI 检查均已通过。所有审核意见均已处理。PR 已准备好接受审核！🎉” #### 循环退出条件在以下情况下退出监视循环： * **所有检查均通过且没有未解决的反馈** — 自然退出 * **用户说“停止”**或请求退出 * **达到最大 10 次迭代** — 询问用户是否要继续 ** ** ## 推送工作流程通过一个命令提交所有更改并推送到当前分支。＃＃＃指示将所有内容作为一个链接命令运行，以便用户仅批准一次： git add -A && git commit -m "<msg>" && git Push origin HEAD * 提交消息：常规提交（`feat:`、`fix:`、`chore:` 等） * 如果没有改变，则跳过 ** ** ## 分支工作流程从基础创建一个新的功能分支，保留当前的更改。 * 基础分支：用户提供的参数，如果未提供则为“test” * 分支命名：根据变化`feat/`、`fix/`、`chore/` * 从更改中推断分支名称或询问用户 ### 说明 **如果有未提交的更改：** 但 oplog snapshot -m “分支切换之前” && git checkout <base> && git pull origin <base> && git checkout -b <branch-name> && 但 oplog 恢复注意：“but oplog snapshot/restore”是“git stash”（在 GitButler 工作区中被禁止）的 GitButler 安全替代品。 **如果工作树是干净的：** git checkout <基础> && git pull origin <基础> && git checkout -b <分支名称> ** ** ## 同步分支工作流程合并所有环境分支，以便 test、prod 和 main 指向同一提交。 ### 第 1 步：安全快照和拆卸但是 oplog snapshot -m“预同步安全” 但拆解如果拆卸失败并显示“未找到活动分支”，请手动检查测试： git 结帐测试 ### 第 2 步：检查测试并拉取 git 结帐测试 git pull 原点测试 ### 步骤 3：将 prod 和 main 合并到测试中 git fetch origin prod main git fetch origin prod main git merge origin/prod --no-edit git merge origin/main --no-edit git merge origin/main --no-edit 如果发生冲突，请使用“--theirs”（首选传入）解决，并仅在冲突不明确时询问用户： git checkout --theirs <冲突文件> git add <冲突文件> git commit --无编辑 ### 步骤 4：推送测试 git推送原点测试 ### 步骤 5：从测试中快进生产 git fetch origin 测试 prod main git checkout 产品 git pull origin 产品 git merge origin/test --no-edit git Push 原始产品 ### 步骤 6：从 prod 快进 main git fetch origin 测试 prod main git checkout 主要 git pull origin 主要 git merge origin/prod --no-edit git推送原点主要 ### 第 7 步：验证同步 git fetch origin 测试 prod main echo“测试：$(git rev-parse origin/test)” echo“产品：$（git rev-parse origin / prod）” echo“主要：$（git rev-parse origin / main）” 所有三个都必须显示相同的 SHA。如果没有，请调查并修复。 ### 步骤 8：返回 GitButler 工作区 git 结帐测试但设置 ### 约束 * **始终在拆卸前创建快照** — 保护未提交的工作区文件 * **始终使用`--no-edit`**进行合并提交——没有交互式编辑器 * **始终在 git 命令之前设置非交互式环境变量**（`GIT_MERGE_AUTOEDIT=no`、`GIT_PAGER=cat` 等） * **永远不要强制推送** - 所有合并都应该是快进或常规合并 * **切勿跳过验证**（步骤 7）— 返回工作区之前确认所有 SHA 匹配 ### 输出报告最终状态：分支已同步到 <SHA> 测试：<SHA> 产品：<SHA> 主要：<SHA></article></body></html>

Git 工作流程

包含技能