Issue To PR

中文简介

Issue 到 PR 执行器把 Issue、Bug 或需求单推进为范围受控、可复现、可验证、可审查的改动与 PR。它不以“写了代码”为完成；无法证明问题、验收、测试或改动边界时，必须留下真实阻塞和下一步。

使用背景

Issue 常把症状、方案和愿望混在一起：清晰需求仍可能缺验收；Bug 可能无法复现；看似顺手的重构会扩大风险。普通提示词容易直接编造修改路径、跳过失败测试、覆盖用户工作区改动，或用“应该可用”代替命令证据。本 Skill 将这些风险转为可观察门槛和交付物。

核心原则

先确认可执行性，再编辑；事实、假设、推断和未知项必须分栏。
Bug 修复先复现或明确不能复现；没有失败信号，不得声称已修复。
先写并观察失败测试，再做满足该测试的最小改动；不借 Issue 搭车重构。
仓库和工作区属于用户：先查看分支、状态、目标基线和已有改动，绝不覆盖、暂存或混入无关内容。
每项验收必须回链到代码改变与验证证据；未运行、失败和阻塞都如实报告。

适用场景

已有 GitHub Issue、Jira/Linear 工单、Bug 报告或范围明确的需求，需要从分析走到 PR。
修复回归、错误处理、边界状态或已有测试失败，需要建立复现与回归证据。
小到中等的功能改动，已有仓库访问、目标分支和可运行的局部测试路径。
需要将实现拆成审查友好的提交，并写出 PR 风险、验证和回滚说明。

不适用场景

没有问题、受众、目标或成功标准时，先用 prd-builder 或需求探索流程。
尚未知道入口、运行方式或测试拓扑时，先用 codebase-onboarding；不要凭目录名猜文件。
需要定位根因但症状复杂、间歇或线上相关时，先用 bug-debugging-playbook 建立假设与复现路径。
目标是结构改善而非交付 Issue 行为时，使用 refactor-with-safety，不要把重构伪装成 Bug 修复。

输入要求

保留原始输入和可定位来源；未提供内容写为 [未知]，不可补造。

Issue 链接或原文、目标行为、实际行为、受影响用户/环境及负责人。
可观察验收标准、非目标、兼容/发布约束和是否应关闭 Issue。
Bug 的复现步骤、环境、样本、日志、截图、时间窗或近期变更；功能的用户路径和失败/权限状态。
仓库路径、目标分支、当前分支、允许的命令、工作区状态和已存在的用户改动。
可定位的代码、测试、构建、lint、CI、部署或回滚资料；没有时明确缺口。

信息不足时的处理

验收或非目标不清： 先输出 Issue 可执行性卡与最小澄清问题；只做只读调查，不开始实现或承诺 PR。
Bug 无法复现： 记录已尝试的环境、步骤、结果和缺少的变量；提出最小观测、日志或测试夹具需求。不得写“已修复”、不得添加猜测性修复、不得关闭 Issue。
未知仓库落点： 用搜索词、候选职责和阅读停止条件替代具体路径；需要时转交 codebase-onboarding。
工作区有改动： 先列出受影响文件与归属。无关或不明改动保持不动、不暂存；若与任务冲突，停止并请求用户决定隔离、保留或协调方式。
测试命令不可运行： 将命令标为 [未运行] 或 [失败]，记录工作目录、前提、退出码/关键输出和阻断原因；不以计划冒充证据。

工作流

保护现场。 读取仓库根目录、分支、git status --short、目标基线和任务相关 diff；确认不覆盖用户改动。
建立 Issue 可执行性卡。 分类 Bug/功能/配置/文档；分列事实、假设、未知，写目标、验收、非目标、风险、发布约束和停止条件。
调查最小路径。 从入口、失败点、相邻测试和调用链获得可定位证据；只扩展到验收或复现阻断的相邻责任。
复现或明确阻塞。 对 Bug 运行最小复现/现有失败测试，记录预期失败信号。无法复现时交付调查结果，不进入实现。
写失败测试。 让每个待改行为有最小测试并亲眼确认失败原因与 Issue 一致；测试已通过时，先解释它未覆盖的行为或停止修改。
最小实现循环。 一次只实现一个失败测试需要的行为；通过后运行该测试和受影响邻近测试。新增抽象、格式化全仓或无关重命名须单列并获确认。
验收与范围复核。 将验收逐项映射到改动、测试/人工观察和结果；检查 diff 只含任务责任，必要时移出无关变更。
提交与 PR。 按可独立审查行为切分提交；PR 说明问题、解法、证据、风险、回滚、未验证项和 Issue 关联。仅在合并后应关闭时使用 closing keyword。

专业判断规则

Issue 可执行性与范围

门槛	最小证据	不满足时
目标与验收	期望行为、主路径和失败/边界状态	只交付澄清问题与条件计划
非目标	明确不改的功能、模块或重构	将扩展请求移为后续 Issue
技术落点	已读路径/符号、调用链或相邻测试	使用搜索线索，不编造路径
工作区安全	分支、状态、用户改动归属	冲突时停止编辑并请求决定
发布与恢复	风险影响、回滚/不适用理由	PR 保留风险与待确认项

将“顺手整理”“统一架构”“顺便升级依赖”等归为范围外，除非它直接解除当前验收阻塞且得到显式确认。
最小修改以能让失败测试转绿、满足验收且不改变无关公开行为为准；代码行数不是唯一标准。
每个 [事实] 关联 Issue 原文、路径/符号、命令、日志或测试；[推断] 写依据与验证动作；[未知] 写它阻断什么决定。

复现、TDD 与验证证据

Bug 的复现是实际行为与期望行为在指定环境中的可观察差异。日志缺失、环境不明或复现失败不是“低优先级修复”的理由。
失败测试必须在实现前运行并因缺失行为失败，不得因语法、fixture 或环境错误而计作红灯。已有测试绿灯不证明新场景已覆盖。
每一轮只改通过当前失败测试所需的最小责任；绿灯后再执行相邻风险测试、构建、类型检查、lint 或人工验证中适用项。
证据表的 [已运行-通过] 和 [已运行-失败] 都要包含工作目录、命令、退出码、关键输出摘要和可定位记录；[未运行] 不写“通过”。

提交、PR、风险与回滚

一个提交只承载一个可独立审查的行为或必要测试；不要将格式化、锁文件漂移和无关重构混入实现提交。
PR 的风险按用户影响、数据/兼容性、上线可见性和恢复难度描述。不可逆数据或外部副作用不得写成“一键回滚”。
回滚写清代码、flag、数据和外部副作用的边界；不适用时写出基于何种证据不适用。
PR 未达到验收、复现证据、测试证据或工作区范围门槛时，结论是“未就绪”或“有条件就绪”，不是“待审”。

输出契约

按 references/templates.md 交付，缺失信息也保留标签：

Issue 可执行性卡：事实/假设/推断/未知、验收、非目标、停止条件。
仓库与工作区保护记录：分支、基线、用户改动、允许触及范围。
复现或不可复现记录：环境、步骤、期望/实际、命令证据或阻断。
最小实现与 TDD 账本：失败测试、红灯证据、最小改动、绿灯证据。
验收与验证矩阵：每项验收到改动、命令/人工观察、结果和缺口的映射。
提交清单与 PR 描述：Issue 关联、变更、证据、风险、回滚、未验证项与后续。

质量门槛

不在验收、非目标、工作区冲突或仓库证据未过门槛时开始实现。
不在 Bug 未复现时假装修复；只能交付复现调查和继续所需证据。
不跳过失败测试观察，不以实现后才写的绿灯测试代替 TDD 证据。
不修改、暂存、提交或丢弃无关用户改动；最终 diff 不混入范围外重构。
不用“已测试”“应该可用”替代真实命令、退出码和结果。
不创建缺风险、回滚/不适用理由、验收映射或未验证项的 PR。

常见失败与修正

失败	修正
看到 Issue 就列文件并编码	先过可执行性门槛；无仓库证据时只列搜索线索。
无法复现仍改一处“可能为空”的代码	停止修复，记录尝试与变量，补观测或稳定复现。
测试在实现后第一次运行	删除该实现路径的完成声明，先写能红的行为测试再最小实现。
用户工作区有改动却直接 `git add .`	保留并标记归属，只精确暂存本任务文件；冲突时请求决定。
为了整洁混入重构或依赖升级	从当前 PR 移出，另建经确认的 Issue/PR。
PR 写“修复问题，测试通过”	补充验收映射、命令结果、风险、回滚和剩余未知。

参考资料

references/usage-guide.zh.md：中文调用方式、准备度与上下游衔接。
references/templates.md：可执行性、复现/TDD、验证与 PR 模板。
references/checklists.md：范围、工作区、测试、证据和 PR 就绪门。
references/examples.md：清晰 Issue、不可复现 Bug、重构诱惑三场景闭环。

issue-to-pr

SKILL.mdissue-to-pr/SKILL.md