用途：把 GitHub issue 转化为经过测试与验证的 PR，并如实报告 CI 状态。适用于“修复 issue #123 并开 PR”“实现该功能请求”“把 bug 从 issue 推进到绿色 CI”等请求；不适用于审查已有 PR，或回答不涉及改动的代码问题。
主要能力与流程：
- 读取实时 issue：用 gh issue view <N> --comments 读取正文与完整讨论，并读取 AGENTS.md、贡献文档，确认当前要求、非目标与未回答问题。
- 排查重复工作：用 gh pr list --search "#<N>" --state all 及至少两个关键词变体搜索，并用 git log --oneline -20 -- <相关文件> 检查近期提交。
- 校验前提：在当前默认分支复现 bug 或演示缺失行为，并用 git log -p -S "<符号>" 检查是否为有意设计。
- 定义验收与风险：列出验收标准、接口、迁移、兼容性、安全隐私、发布与回滚，并映射到测试。
- 最小完整改动并修复同类问题：在隔离分支或 worktree 上先加回归测试再实现，用 search_files 查找同类调用点一并修复。
- 证明回归测试有效：临时恢复旧行为确认测试失败，再恢复修复确认通过。
- 运行质量门禁并立即开 PR：运行格式化、lint、类型检查与仓库测试入口，用 requesting-code-review 审查 diff，随后推送并开 PR，加载 github-pr-workflow 处理 PR 机制。
- 诚实跟进 CI：用 gh pr checks / gh run view --log-failed 查看实时检查与失败日志，区分自身改动与既有失败，仅在真实证据下称“绿色”“已合并”“已发布”，PR 落地后在 issue 中评论链接与说明。
限制与注意：不要在未读 issue 评论、未排查重复 PR、未读当前代码前动手；不要“修复”经 git 历史确认的有意设计；不要只修一个调用点而留下同类问题；不要提交在无修复时也能通过的回归测试；不要带未运行测试或无关格式改动开 PR；不要仅因 PR 存在就宣称 issue 已交付。验证清单包括完整读取 issue 讨论、重复 PR 排查、前提复现与设计意图检查、回归测试失败证明、同类调用点处理、每行改动可追溯、CI 状态仅基于实时证据并在 issue 中评论 PR 链接。