用途：把跟踪器（tracker）工单从开始推进到交付（shipped）。PR 的具体机制由其他技能承担，本技能处理工单在流程之上附加的部分。
主要能力与步骤：
- 读取工单及其最新评论，并在开始前列出已有 PR（可用 acli、Jira、Linear、gh）。使用 acli 时请求 --fields summary,description,status,comment,issuelinks --json，因为默认视图会省略评论，而评论中可能包含重新打开的 QA 范围。同时阅读已有 PR 的 diff 和正文，后续提交可能使正文中的实现声明失效。
- 开始前确认正确的基础分支。有些组织需要发布分支加默认分支（stacked-pr）。不要假设，要核实组织规则。
- 查找已有 PR 或新建一个（work → pr-update），然后推动其达到可合并状态（pr-ready），并在交接前打磨（clean）。
- 选择交接状态前，先阅读仓库的工单/标签指南，不要用通用工作流名称替代。在 MR 中，使用 .claude/skills/create-pr/SKILL.md 和 teams.md 获取标签规则。对于被 QA 退回后修复的已有 DOTCOMPB PR，用户的复测交接是 In Test 加 Pending QA Review，而不是重置为 In Code Review。保留由工单驱动的 Needs UI Review 标签。单独报告 CI/部署阻塞项；In Test 不代表可合并。当用户请求交接时，链接 PR 并添加事实性的复测更新。
- 起草干系人更新（Slack 或工单评论），简短、不套话。除非被要求，否则不要发送。
禁止事项：不要假设基础分支；CI 红灯或评审线程未关闭时不要把工单标记为完成；不要让工单和 PR 对工作状态给出不一致的叙述。
适用场景：需要把跟踪器工单推进到交付、协调 PR 与工单状态、准备交接与干系人沟通的工程流程。
限制：资料未提供具体安装命令、收费、价格、平台支持范围或效果数据；部分步骤依赖 acli、Jira、Linear、gh 等外部工具及仓库内特定文件（如 .claude/skills/create-pr/SKILL.md、teams.md），实际可用性取决于这些依赖是否存在。