awesome-copilot 实战copilot-pr-autopilot 的 accepted-fix 回复模板——在 PR 审查循环中正确宣告修复【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇技术指南围绕 skills/copilot-pr-autopilot 技能中用于修复已被接受并推送场景的回复模板 reply-fix.md 展开。它位于自动循环的第 8 步回复 解决是 Copilot PR 审查循环中让每个 open thread 闭合的关键一环节。读完本文你将掌握 accepted-fix 回复的固定句式、为什么必须引用推送后的 commit SHA、如何补一行测试确认、以及这条模板在底层 PowerShell 脚本中如何通过两次 GraphQL mutation 落地从而写出能让后续审查不再反复提起的干净回复。背景回复模板在自动审查循环中的位置copilot-pr-autopilot 是 awesome-copilot 仓库中一个仓库无关的 Copilot 审查自动循环技能它通过ghCLI 触发 Copilot Code Review对 PR 上每一个 open thread 执行 triage04-triage.md并行派发修复子代理然后回复、解决再重新触发审查直到收敛。整个循环按步骤编号运行详见 SKILL.mdRequest review → 2. Wait → 3. List threads → 4. Triage → 5. Fix → 6. Build/test →7. Commit push→8. Reply resolve→ 9. Convergence → 回到步骤 1直到Converged: true后执行步骤 10。reply-fix.md正是步骤 8在 triage 判定为fix且修复已经提交推送后使用的回复模板。它之所以是独立的模板文件而不是散落在脚本里的字符串是因为回复体由通用子代理起草、父级代理发布sub-agent drafts, parent posts见 08-reply-resolve.md模板必须作为可复用的提示输入传给起草子代理。为什么回复必须放在 Commit push 之后循环对步骤顺序有硬性约束步骤 8 严格运行在步骤 7 之后。原因写在 08-reply-resolve.md 的引言中——Runs AFTER step 7 (commit push) so every reply can cite thepushed commit SHA。也就是说回复模板中要求的 commit SHA 只有在修复真正推送之后才存在这保证了审查者可以实际浏览到被引用的提交。模板本体三句式结构reply-fix.md 定义的核心结构非常精简只有三句话one sentence acknowledging the finding. one or two sentences describing the fix. Fixed in commit-sha.逐句拆解其职责第一句确认发现acknowledging the finding。用一句话承认 Copilot 指出的问题确实存在这是对话的锚点让审查者一眼确认你说的问题我收到了。第二句描述修复describing the fix。用一到两句话说明修复做了什么应具体到文件、函数、机制层面而不是修了这种空话。第三句引用提交Fixed in 。给出推送后的 commit SHA形成发现 → 修复 → 证据的完整闭环。语言中立示例模板给出的语言中立示例是一个并发锁覆盖范围问题The lock did not cover the install side of the path, so two parallel writers could read the same baseline and clobber each other. Promoted the per-instance lock to a process-wide function-local static so all read-modify-write paths share it. Fixed in abc1234.注意这个示例的写法层次第一句描述了根因锁没有覆盖 install 路径 → 两个并行 writer 可能读到同一 baseline 并互相覆盖第二句描述了修复手段把 per-instance 锁提升为 process-wide function-local static让所有 read-modify-write 路径共享第三句用Fixed in abc1234落锚。这种根因 手段 SHA的组合正是 08-reply-resolve.md 中 Be concrete (cite file paths, commit SHAs, function names) 的具体化。进阶用法修复落在测试覆盖区时补一行测试确认模板的第二部分是一个条件扩展当修复位于有测试覆盖的区域时追加一行测试确认。示例Replaced the platform UUID dependency with a PID monotonic-clock atomic counter so the test target no longer pulls in the platform UUID library. All 42 tests in the affected suite still pass. Fixed in abc1234.这行测试确认的价值在于向审查者证明修复没有破坏既有行为All 42 tests in the affected suite still pass呼应循环中步骤 6 的按仓库约定构建 测试见 SKILL.md 的 Step 6Build test per repo conventions把测试结果作为证据写进线程让回复从我改了升级为我改了且验证过减少下一轮审查把同一问题重新抛出的概率。如果修复本身是纯文档、注释或重构且测试套件没有针对该改动的新用例则只需保持基础三句式不必强行追加测试描述。为什么必须引用推送的 SHA而不是本地提交这是回复模板最容易踩坑的地方08-reply-resolve.md 的 Gotchas 明确写道Cite the pushed SHA, not a local commit. Step 7s recordedHeadOidis the only SHA reviewers can browse to.原因有三层审查者可浏览性审查线程中的人或机器人只能看到已经推送到远程的分支本地提交的 SHA 对审查者不可见引用它等于给了一个死链接。与收敛判定对齐循环第 9 步用LatestCopilotReview.commitOid与步骤 7 记录的HeadOid比较来判定是否收敛见 SKILL.md Step 9。如果回复引用了错误的 SHA收敛证据链会断裂。审计轨迹07-commit-push.md 规定one focused commit per round每轮一个聚焦提交而不是每个 PR 一个并要求提交携带Co-authored-by: Copilot 223556219Copilotusers.noreply.github.comtrailer。每轮回复引用的 SHA 因此与当轮修复一一对应git bisect和事后审计都能准确定位哪个发现驱动了哪个改动。步骤 8 的输入契约正是{ thread_id, action, rationale }完整 triage 表、步骤 7 的推送HeadOid、以及步骤 5 的每线程 fixsummary和files_touched——回复体就是这些输入的直接消费者。底层实现08-reply-and-resolve.ps1 如何落地这条模板模板是文案层真正执行回复的是 scripts/08-reply-and-resolve.ps1。它接收-ThreadIdGraphQL node ID如PRRT_kw...和-Body回复正文支持 Markdown正是模板产出的文本依次执行两次独立的 GraphQL mutationaddPullRequestReviewThreadReply——把回复评论追加到线程resolveReviewThread——把线程标记为已解决。pwsh ./scripts/08-reply-and-resolve.ps1 -ThreadId id -Body text-NoResolve 开关什么时候只回复不解决脚本还提供-NoResolve开关pwsh ./scripts/08-reply-and-resolve.ps1 -ThreadId id -Body text -NoResolve在自动循环的规则中fix与decline两类 action 回复后默认解决线程只有escalate-to-user升级给人工合并负责人的线程才用-NoResolve保持开启见 08-reply-resolve.md。也就是说reply-fix 模板对应的场景总是回复 解决。非原子性与重试策略脚本注释明确警告回复与解决是两次独立的 mutation整体非原子。若回复成功、解决失败瞬时 5xx、限流、线程中途消失回复已经发布。脚本对回复也不幂等——-Body是必填参数重复执行同一命令会发布重复回复。因此推荐的失败处理策略是若 Replied to thread X未打印 → 回复步骤失败可以安全重跑整个命令若 Replied to thread X 已打印但 Resolved thread X 未打印 → 只有解决步骤失败不要重跑脚本会重复回复改为直接调用原始 GraphQL mutationgh api graphql \ -f querymutation($t:ID!){resolveReviewThread(input:{threadId:$t}){thread{id}}} \ -f t$ThreadId共享基础设施脚本第一行通过. $PSScriptRoot/_lib.ps1点源加载 scripts/_lib.ps1其中Assert-GhReady会在gh未安装或未认证时在任何工作开始前抛出包含安装命令与gh auth login指引的可操作错误Invoke-GhGraphQL封装了gh api graphql的调用、退出码检查与 GraphQLerrors数组聚合。所有循环脚本都通过这套共享层与 GitHub API 交互。模板矩阵fix / decline / drift / partial 如何各司其职reply-fix.md不是孤立文件它与 templates 目录下其余三份模板组成完整回复体系由 triage 的 action 决定选用哪一份对应表见 08-reply-resolve.mdTriage action模板要点fix修复被接受reply-fix.md确认发现 描述修复 Fixed in SHAdecline有理由拒绝reply-decline.md必须解释为什么拒绝而非只说自己考虑过拒绝后同样回复 解决文档 / 测试计划漂移reply-drift.md承认并更新 PR 描述 / 注释 / 测试计划与实现对齐部分修复 延后跟进reply-partial.md立即修复部分 明确记录更深层结构问题及跟踪方式escalate-to-user没有模板——它要求撰写定制回复说明处置与留给人工合并负责人的开放问题并用-NoResolve保持线程开启。值得注意的是fix 与 decline 在 triage 层面有着对称的设计哲学fix 用 SHA 作证据decline 用根因作证据declining: 。两者的共同底线是绝不无理由回复这正是 04-triage.md 中 Reply hygiene 的要求——每条回复无论 fix 还是 decline都陈述推理让 PR 自我文档化并给下一轮审查提供可见上下文从而避免同一问题被反复提起。回复质量自检四个必须避免的反模式08-reply-resolve.md 为所有回复含 fix 回复给出质量标尺concrete引用文件路径、commit SHA、函数名、direct有立场时不模棱两可、brief典型 2–4 句并列出四个明确禁止的反模式❌ Thanks! / Good point. 这种无实质内容的回复——没有记录决策❌ Will fix later.——要么现在修用本模板要么拒绝并给理由无跟踪的延迟修复必然丢失❌ 只解决不回复resolve-without-reply——下一轮审查者无法重建线程关闭的原因❌ I disagree. 不带推理——必须陈述具体的技术分歧点。用 reply-fix 模板写出的回复天然规避了前两类问题三句式结构强制至少包含一句对修复的描述和一句 SHA 证据杜绝空感谢与以后再说。常见问题排查在循环中实际使用该模板时可能遇到的问题及处理建议场景处理方式回复后线程仍被下一轮 Copilot 审查重新提起检查第二句是否足够具体是否引用了文件 / 函数 / 机制以及 SHA 是否真的是推送后的HeadOid含糊的 fix 回复会在下一轮被重新质疑修复在测试区域但测试未通过不要用本模板回到步骤 6 修复构建/测试问题后再推送模板中测试确认行的前提是测试真正通过想回复但不解决线程确认 triage action 是否为escalate-to-userfix场景下不要使用-NoResolve否则收敛判定OpenThreadsAwaitingReply 0无法满足修复被接受但发现自己需要延后更深层改动改用 reply-partial.md而不是在本模板里混入延后承诺小结reply-fix.md 虽短却是整个 copilot-pr-autopilot 循环收敛链路上不可省略的一环它以确认发现 → 描述修复 → 引用推送 SHA三句式让每个被修复的 Copilot 线程获得可审计、可复现的关闭理由以测试确认行为修复背书并通过 08-reply-and-resolve.ps1 的两次 GraphQL mutation 与-NoResolve语义精确控制回复并解决的边界。写好这条回复就是在为每一轮审查的收敛与后续维护者的可追溯性投资。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
awesome-copilot 实战copilot-pr-autopilot 的 accepted-fix 回复模板——在 PR 审查循环中正确宣告修复【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot本篇技术指南围绕 skills/copilot-pr-autopilot 技能中用于修复已被接受并推送场景的回复模板 reply-fix.md 展开。它位于自动循环的第 8 步回复 解决是 Copilot PR 审查循环中让每个 open thread 闭合的关键一环节。读完本文你将掌握 accepted-fix 回复的固定句式、为什么必须引用推送后的 commit SHA、如何补一行测试确认、以及这条模板在底层 PowerShell 脚本中如何通过两次 GraphQL mutation 落地从而写出能让后续审查不再反复提起的干净回复。背景回复模板在自动审查循环中的位置copilot-pr-autopilot 是 awesome-copilot 仓库中一个仓库无关的 Copilot 审查自动循环技能它通过ghCLI 触发 Copilot Code Review对 PR 上每一个 open thread 执行 triage04-triage.md并行派发修复子代理然后回复、解决再重新触发审查直到收敛。整个循环按步骤编号运行详见 SKILL.mdRequest review → 2. Wait → 3. List threads → 4. Triage → 5. Fix → 6. Build/test →7. Commit push→8. Reply resolve→ 9. Convergence → 回到步骤 1直到Converged: true后执行步骤 10。reply-fix.md正是步骤 8在 triage 判定为fix且修复已经提交推送后使用的回复模板。它之所以是独立的模板文件而不是散落在脚本里的字符串是因为回复体由通用子代理起草、父级代理发布sub-agent drafts, parent posts见 08-reply-resolve.md模板必须作为可复用的提示输入传给起草子代理。为什么回复必须放在 Commit push 之后循环对步骤顺序有硬性约束步骤 8 严格运行在步骤 7 之后。原因写在 08-reply-resolve.md 的引言中——Runs AFTER step 7 (commit push) so every reply can cite thepushed commit SHA。也就是说回复模板中要求的 commit SHA 只有在修复真正推送之后才存在这保证了审查者可以实际浏览到被引用的提交。模板本体三句式结构reply-fix.md 定义的核心结构非常精简只有三句话one sentence acknowledging the finding. one or two sentences describing the fix. Fixed in commit-sha.逐句拆解其职责第一句确认发现acknowledging the finding。用一句话承认 Copilot 指出的问题确实存在这是对话的锚点让审查者一眼确认你说的问题我收到了。第二句描述修复describing the fix。用一到两句话说明修复做了什么应具体到文件、函数、机制层面而不是修了这种空话。第三句引用提交Fixed in 。给出推送后的 commit SHA形成发现 → 修复 → 证据的完整闭环。语言中立示例模板给出的语言中立示例是一个并发锁覆盖范围问题The lock did not cover the install side of the path, so two parallel writers could read the same baseline and clobber each other. Promoted the per-instance lock to a process-wide function-local static so all read-modify-write paths share it. Fixed in abc1234.注意这个示例的写法层次第一句描述了根因锁没有覆盖 install 路径 → 两个并行 writer 可能读到同一 baseline 并互相覆盖第二句描述了修复手段把 per-instance 锁提升为 process-wide function-local static让所有 read-modify-write 路径共享第三句用Fixed in abc1234落锚。这种根因 手段 SHA的组合正是 08-reply-resolve.md 中 Be concrete (cite file paths, commit SHAs, function names) 的具体化。进阶用法修复落在测试覆盖区时补一行测试确认模板的第二部分是一个条件扩展当修复位于有测试覆盖的区域时追加一行测试确认。示例Replaced the platform UUID dependency with a PID monotonic-clock atomic counter so the test target no longer pulls in the platform UUID library. All 42 tests in the affected suite still pass. Fixed in abc1234.这行测试确认的价值在于向审查者证明修复没有破坏既有行为All 42 tests in the affected suite still pass呼应循环中步骤 6 的按仓库约定构建 测试见 SKILL.md 的 Step 6Build test per repo conventions把测试结果作为证据写进线程让回复从我改了升级为我改了且验证过减少下一轮审查把同一问题重新抛出的概率。如果修复本身是纯文档、注释或重构且测试套件没有针对该改动的新用例则只需保持基础三句式不必强行追加测试描述。为什么必须引用推送的 SHA而不是本地提交这是回复模板最容易踩坑的地方08-reply-resolve.md 的 Gotchas 明确写道Cite the pushed SHA, not a local commit. Step 7s recordedHeadOidis the only SHA reviewers can browse to.原因有三层审查者可浏览性审查线程中的人或机器人只能看到已经推送到远程的分支本地提交的 SHA 对审查者不可见引用它等于给了一个死链接。与收敛判定对齐循环第 9 步用LatestCopilotReview.commitOid与步骤 7 记录的HeadOid比较来判定是否收敛见 SKILL.md Step 9。如果回复引用了错误的 SHA收敛证据链会断裂。审计轨迹07-commit-push.md 规定one focused commit per round每轮一个聚焦提交而不是每个 PR 一个并要求提交携带Co-authored-by: Copilot 223556219Copilotusers.noreply.github.comtrailer。每轮回复引用的 SHA 因此与当轮修复一一对应git bisect和事后审计都能准确定位哪个发现驱动了哪个改动。步骤 8 的输入契约正是{ thread_id, action, rationale }完整 triage 表、步骤 7 的推送HeadOid、以及步骤 5 的每线程 fixsummary和files_touched——回复体就是这些输入的直接消费者。底层实现08-reply-and-resolve.ps1 如何落地这条模板模板是文案层真正执行回复的是 scripts/08-reply-and-resolve.ps1。它接收-ThreadIdGraphQL node ID如PRRT_kw...和-Body回复正文支持 Markdown正是模板产出的文本依次执行两次独立的 GraphQL mutationaddPullRequestReviewThreadReply——把回复评论追加到线程resolveReviewThread——把线程标记为已解决。pwsh ./scripts/08-reply-and-resolve.ps1 -ThreadId id -Body text-NoResolve 开关什么时候只回复不解决脚本还提供-NoResolve开关pwsh ./scripts/08-reply-and-resolve.ps1 -ThreadId id -Body text -NoResolve在自动循环的规则中fix与decline两类 action 回复后默认解决线程只有escalate-to-user升级给人工合并负责人的线程才用-NoResolve保持开启见 08-reply-resolve.md。也就是说reply-fix 模板对应的场景总是回复 解决。非原子性与重试策略脚本注释明确警告回复与解决是两次独立的 mutation整体非原子。若回复成功、解决失败瞬时 5xx、限流、线程中途消失回复已经发布。脚本对回复也不幂等——-Body是必填参数重复执行同一命令会发布重复回复。因此推荐的失败处理策略是若 Replied to thread X未打印 → 回复步骤失败可以安全重跑整个命令若 Replied to thread X 已打印但 Resolved thread X 未打印 → 只有解决步骤失败不要重跑脚本会重复回复改为直接调用原始 GraphQL mutationgh api graphql \ -f querymutation($t:ID!){resolveReviewThread(input:{threadId:$t}){thread{id}}} \ -f t$ThreadId共享基础设施脚本第一行通过. $PSScriptRoot/_lib.ps1点源加载 scripts/_lib.ps1其中Assert-GhReady会在gh未安装或未认证时在任何工作开始前抛出包含安装命令与gh auth login指引的可操作错误Invoke-GhGraphQL封装了gh api graphql的调用、退出码检查与 GraphQLerrors数组聚合。所有循环脚本都通过这套共享层与 GitHub API 交互。模板矩阵fix / decline / drift / partial 如何各司其职reply-fix.md不是孤立文件它与 templates 目录下其余三份模板组成完整回复体系由 triage 的 action 决定选用哪一份对应表见 08-reply-resolve.mdTriage action模板要点fix修复被接受reply-fix.md确认发现 描述修复 Fixed in SHAdecline有理由拒绝reply-decline.md必须解释为什么拒绝而非只说自己考虑过拒绝后同样回复 解决文档 / 测试计划漂移reply-drift.md承认并更新 PR 描述 / 注释 / 测试计划与实现对齐部分修复 延后跟进reply-partial.md立即修复部分 明确记录更深层结构问题及跟踪方式escalate-to-user没有模板——它要求撰写定制回复说明处置与留给人工合并负责人的开放问题并用-NoResolve保持线程开启。值得注意的是fix 与 decline 在 triage 层面有着对称的设计哲学fix 用 SHA 作证据decline 用根因作证据declining: 。两者的共同底线是绝不无理由回复这正是 04-triage.md 中 Reply hygiene 的要求——每条回复无论 fix 还是 decline都陈述推理让 PR 自我文档化并给下一轮审查提供可见上下文从而避免同一问题被反复提起。回复质量自检四个必须避免的反模式08-reply-resolve.md 为所有回复含 fix 回复给出质量标尺concrete引用文件路径、commit SHA、函数名、direct有立场时不模棱两可、brief典型 2–4 句并列出四个明确禁止的反模式❌ Thanks! / Good point. 这种无实质内容的回复——没有记录决策❌ Will fix later.——要么现在修用本模板要么拒绝并给理由无跟踪的延迟修复必然丢失❌ 只解决不回复resolve-without-reply——下一轮审查者无法重建线程关闭的原因❌ I disagree. 不带推理——必须陈述具体的技术分歧点。用 reply-fix 模板写出的回复天然规避了前两类问题三句式结构强制至少包含一句对修复的描述和一句 SHA 证据杜绝空感谢与以后再说。常见问题排查在循环中实际使用该模板时可能遇到的问题及处理建议场景处理方式回复后线程仍被下一轮 Copilot 审查重新提起检查第二句是否足够具体是否引用了文件 / 函数 / 机制以及 SHA 是否真的是推送后的HeadOid含糊的 fix 回复会在下一轮被重新质疑修复在测试区域但测试未通过不要用本模板回到步骤 6 修复构建/测试问题后再推送模板中测试确认行的前提是测试真正通过想回复但不解决线程确认 triage action 是否为escalate-to-userfix场景下不要使用-NoResolve否则收敛判定OpenThreadsAwaitingReply 0无法满足修复被接受但发现自己需要延后更深层改动改用 reply-partial.md而不是在本模板里混入延后承诺小结reply-fix.md 虽短却是整个 copilot-pr-autopilot 循环收敛链路上不可省略的一环它以确认发现 → 描述修复 → 引用推送 SHA三句式让每个被修复的 Copilot 线程获得可审计、可复现的关闭理由以测试确认行为修复背书并通过 08-reply-and-resolve.ps1 的两次 GraphQL mutation 与-NoResolve语义精确控制回复并解决的边界。写好这条回复就是在为每一轮审查的收敛与后续维护者的可追溯性投资。【免费下载链接】awesome-copilotCommunity-contributed instructions, agents, skills, and configurations to help you make the most of GitHub Copilot.项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-copilot创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
)
)
