用途：把 GitHub issue 转化为具体代码改动，并以 pull request 形式发布结果。适用于端到端修复 issue、用原始 gh 命令收集 issue 上下文与评论、实现改动并创建或更新 PR。不适用于仅审查现有 PR、回复现有 PR 的评审反馈，或项目级规划与 backlog 梳理。
前置条件：需要 gh CLI 认证；GITHUB_TOKEN/GH_TOKEN 必须允许 issue/PR 读写操作。
运行时路径：GITHUB_OUTPUT_DIR 为输出产物目录（优先由调用方提供，否则用临时目录）；GITHUB_CONTEXT_DIR 为上下文目录，默认 ${GITHUB_OUTPUT_DIR}/github-context。
输入：优先使用 ${GITHUB_CONTEXT_DIR}/manifest.json；可选输入为 manifest.artifacts[] 中 status=present 的产物。若无 manifest，则直接用 gh 收集 issue 元数据与评论： gh issue view <issue_number> --repo <owner/repo> --json number,title,body,state,url,author,createdAt,updatedAt,labels gh api repos/<owner>/<repo>/issues/<issue_number>/comments --paginate 不要假设 github/ 下有固定文件名，应通过 manifest.artifacts[] 的 id/path/status/description 解析可用输入。
工作流：1) 收集上下文；2) 分析并实现，提取验收标准与约束，做最小完整改动，使用确定性分支命名（feature/issue-<number> 或 fix/issue-<number>），发布前运行相关验证命令；3) 提交并推送，只提交有意改动，推送分支到远端；4) 发布 PR，使用原始 gh 命令配合 --body-file： gh pr create --repo <owner/repo> --title "<title>" --body-file <summary.md> --head <branch> --base <base> gh pr edit <pr_number> --repo <owner/repo> --title "<title>" --body-file <summary.md> 发布完成是强制要求，没有真实 PR 副作用不得报告成功；5) 在 ${GITHUB_OUTPUT_DIR} 下产出 summary.md 与 manifest.json。
交付标准：范围与 issue 意图一致，避免无关重构；需求模糊时明确说明假设；包含具体验证结果（命令与结果）；无法完整验证时说明尝试内容与不完整原因。
输出契约：summary.md 须包含 issue 引用与解读后的需求、关键代码改动、执行的验证及结果、PR 发布结果（pr_number、pr_url、branch）、明确的阻塞或后续事项。manifest.json 包含 provider: "github-issue-solve"、issue 引用、branch、发布结果字段（pr_number、pr_url）、status（completed|failed）。
失败规则：若未针对 issue 意图产生有意义代码改动、未完成提交/推送、PR 创建/更新失败或无法验证 PR URL，则标记运行失败；不得仅凭产物报告成功。