task-to-pr

任务转 PR

将每项任务作为一个重点明确且有验证依据的拉取请求交付。规格即工单；接受 Markdown 规格、GitHub issue，或附有验收检查项且已确定的任务。 不要创建第二份工作定义。

直接将必需技能的 SKILL.md 文件作为本工作流的指引阅读。不要通过客户端会阻止的技能命令调用它们。

准备

1. 阅读源文件、仓库指引、相关需求与架构、代码和测试。继续工作时，复用现有分支、工作树和拉取请求。
2. 确认结果、范围、决策和检查项足够明确。如果缺少会造成重大影响的决策，先返回 /spec，或在实现前说明所需决策。对于规模较小且已确定的工作，不要编写规格。
3. 需要时用 /plan 拆分较大的规格。每项任务都要交付一个可用的结果。确定依赖关系，并在合适时并行启动独立工作。

交付与修复

1. 创建或复用隔离的分支和工作树。独立工作应从最新的远程默认分支开始。遵循仓库的命名和工作树规则。
2. 实现任务，并为变更行为及受影响的问题编写有意义的测试。如果变更影响需求、架构或规格，请同步更新。确保架构意图和实现状态准确。
3. 使用 /test 验证验收要求和受影响的规则。提交前修复所有失败。
4. 创建 Conventional Commit，推送并创建或更新拉取请求。遵循仓库的 PR 模板。开头说明问题和结果；附上验证依据和源链接。将 PR 标记为可供审查，并在受支持时将跟踪工单移至 Review。
5. 使用 /review，并由未参与实现的全新子 Agent 执行审查。等待当前提交对应的 CI 和自动化审查完成。
6. 修复有效的审查意见以及由变更导致的失败。针对审查意见回复修复方案，或说明不做改动的依据。只有在意见已完全解决时才解决对应讨论串。
7. 实现变更后，重新执行受影响的 /test 检查和全新 /review，然后提交、推送，并再次等待 CI 和自动化审查。更新 PR 验证依据。持续迭代，直到所有可用检查均通过且没有待处理的有效意见。
8. 如果进展需要缺失的决策、权限、不可用的检查或外部修复，应报告阻碍。不要削弱测试、绕过仓库规则，或声称未运行的检查已通过。
9. 将最终验证依据和 PR 链接记录在源规格或任务中。更新交付状态，使其反映实际结果，包括 PR 是开放还是已合并。如果存在原始跟踪项，也要更新。默认让通过检查的 PR 保持开放，等待人工审查。等待人工批准是合并阻碍，不代表实现检查失败。

依赖项

只有在每项前置任务都有开放的 PR、最新的 Approve 审查且没有已知阻碍性意见后，才开始依赖这些任务的工作。将分支基于已审查的前置任务。若有多个前置任务，按依赖顺序合并处理。每个 PR 的差异应仅聚焦于其自身任务。

当前置任务发生变更或合并时，更新依赖分支和 PR 的目标分支。针对新的基础分支，重新执行受影响的测试、独立审查和 CI。

仅在获得授权时合并

明确使用 /factory 或 /codex-issue-coordinator，即授予其限定范围内的合并权限。否则，只有在用户提出要求时才合并。自动选择技能不会授予合并权限。合并前，必须满足以下要求：

• 最终提交具备完整的范围说明和验收证明。
• 测试、必需的 CI 均通过，且最新的 /review 结论为 Approve。
• 没有尚未解决的可执行审查意见或重大决策。
• 满足仓库要求的所有审批。
• PR 已就绪、可合并，且基于最新的必需基准分支。

按照依赖顺序，使用仓库首选的方法合并。切勿绕过分支保护。确认 GitHub 显示已合并，然后在源规范或任务中更新交付状态，并更新原始 issue 和项目状态。合并或关闭后，移除手动创建的工作树；对于托管工作树，使用宿主提供的生命周期工具。保留仍有待合并 PR 的工作树。 合并权限不包含部署或发布权限。

返回结果

报告每个 PR、测试、审查结论、CI 状态和阻碍项。除非已获得限定范围内的合并权限，否则在所有通过检查的 PR 保持开放时停止。在合并模式下，报告已验证的合并结果以及仍需人工处理的事项。