github-issue-to-pr

GitHub Issue 转 Pull Request

将 GitHub issue 转化为经过测试和验证的 PR。本技能负责端到端流程，包括验证问题前提、排查重复工作、修复整类问题，以及如实报告 CI 状态；配套的 GitHub 和开发技能各自负责对应的具体操作。

适用场景

• “修复 issue #123 并创建 PR。”
• “实现这个 GitHub 功能请求。”
• “修复这个 issue 中的错误，直到 CI 全部通过。”

不适用于：审查现有 PR，或回答没有要求修改代码的问题。

流程

1. 阅读最新 issue——正文和完整讨论串

使用 terminal 运行 gh issue view <N> --comments。正文只是提交 issue 时的快照；最新评论才反映当前情况：已合并的部分修复、新的根因分析、维护者的决定，或向你提出并会改变任务的问题。还要使用 read_file 阅读仓库说明（AGENTS.md、贡献文档）。确认已了解当前要求的行为、非目标，以及讨论串中任何尚未回答的问题后，即可完成本步骤。

2. 排查现有工作和重复工作

在编写任何代码之前，运行 gh pr list --search "#<N>" --state all，并针对问题表现的关键词或同义词至少使用两个变体（gh pr list --search "<subsystem> <symptom>" --state open）。热门 issue 往往会吸引多个独立修复；重复实现会浪费精力，也无法获得应有的贡献认可。还要检查最近的提交是否已经修复问题：git log --oneline -20 -- <relevant files>。确认已了解所有涉及此 issue 的开放 PR 和近期提交，或确认不存在这类工作后，即可完成本步骤。

3. 根据当前代码和设计意图验证问题前提

使用 search_files 和 read_file 追踪报告所涉及的代码路径，通过失败测试或测试样例，在当前默认分支上复现错误，或证明所需行为缺失。然后再问一个问题：这个“错误”是否其实是刻意的设计？针对 issue 要求修改的代码运行 git log -p -S "<symbol>"，并阅读原始提交的意图——缺失的链接或限制往往正是该功能的一部分。不要盲目照着过时或有误的问题描述实现。确认已在当前代码中证明根因或功能缺口，并且修改不会与既定设计冲突后，即可完成本步骤。

4. 明确验收标准和风险

列出验收标准、接口、迁移／状态变更、兼容性、安全／隐私、发布计划和回滚方案。为每项标准对应一项测试或明确的验证方式。确保评审时有一份范围明确的约定后，即可完成本步骤。

5. 实施最小且完整的修改——并修复整类问题

在独立分支或 worktree 上工作；如果问题类型需要，可加载 systematic-debugging 或 test-driven-development。先添加回归测试，再实现修改。修复完成后，使用 search_files 检查同级调用点是否存在相同的问题模式，并在此 PR 中修复整类问题——留下已知同类问题未修复的不完整改动，比不修更糟。每一行改动都必须能追溯到该 issue；不要顺手清理无关代码。确认目标测试通过、原问题无法再复现，并且同级调用点的问题已修复或明确排除后，即可完成本步骤。

6. 验证回归测试确实有效（破坏性测试）

临时恢复被测函数的旧行为，运行新测试并确认测试失败；然后恢复修复并确认测试通过。无论是否修复都能通过的回归测试毫无意义。确认测试在修复前的代码上确实会失败后，即可完成本步骤。

7. 运行仓库质量检查，然后立即创建 PR

对受影响的部分运行格式化工具、lint、类型检查和仓库的标准测试入口；针对差异使用 requesting-code-review。然后立即推送并创建 PR——PR 会触发 CI，而 CI 耗时最长；不要让已完成的工作搁置。加载 github-pr-workflow，了解 PR 流程：使用符合规范的分支名和提交信息，并在正文中关联问题，说明问题、解决方法、测试、风险和不包含的内容。重新查看 PR，核实 head SHA、base、标题和文件。完成标准：PR 已创建，包含预期的差异，且 CI 正在运行。

8. 如实跟进 CI 并完成闭环

通过 gh pr checks / gh run view --log-failed 检查实时检查状态和失败日志。区分由你的差异引入的失败与已有基线问题或基础设施故障——不确定时，在默认分支上复现；只有确实属于基础设施偶发故障时才重新运行一次。没有实时证据证明确切状态时，绝不要声称“通过”“已合并”或“已发布”。PR 合并后，在问题中评论并附上 PR 链接，以及一句话说明，让报告者能够追踪问题的解决情况。完成标准：CI 状态、剩余阻碍和问题讨论串都如实反映当前情况。

易犯错误

• 未阅读问题评论、未全面查找重复 PR，或未阅读当前代码就开始编码。
• “修复”原始提交表明属于有意设计的行为。
• 只修复一个调用点的症状，却让其他同类调用点保留相同的缺陷。
• 提交的回归测试在没有修复的情况下也能通过。
• 创建 PR 时包含未运行的测试，或无关的格式变更。
• 因为 PR 已存在，就声称问题已交付。

验证

• 已阅读完整的问题讨论串；计划反映最新评论中的状态。
• 已使用问题编号和两个关键词变体查找重复 PR。
• 已在当前代码上复现前提；已通过 git 历史核实设计意图。
• 已证明回归测试在没有修复时会失败。
• 已修复同类调用点，或明确说明为何不需要修复。
• 每一处变更都能追溯到该问题。
• 仅依据实时证据报告 CI 状态；已在问题中评论并附上 PR 链接。