用途：把 issue 相关工作整理为一次交付——结构化 commit、push 分支、创建或更新 PR，并在 PR 中通过 Closes #N 关联 issue。仅在用户明确要求 PR 时使用；简单的“ship it”不构成触发条件。该技能最终产物是等待评审的 PR 及一条 QA 评论；仅在明确选择时才把 PR 合并到本地分支 local。
主要能力：按共享 ship policy 执行 PR 专属步骤；PR 标题与 commit subject 一致；正文包含 Closes #<num>、Summary、Where changed、Decisions、How to test、Evidence、Merge danger、Notes 等章节，并保持顺序与结构。可撰写独立的 QA 评论，引用实际 SHA、分支与 PR URL。支持读取 issue 标签、分支处理、提交信息格式、预提交安全检查、推送与 PR 创建/更新、读回校验。
必要用法：先读 references/ship-policy.md 及其命名章节，保留安全门。步骤包括读取状态、解析或创建 issue、读取 issue 标签、分支处理、草拟 commit 与 PR/QA 草稿、展示草稿等待一次合并审批、预提交安全、提交、推送、创建或更新 PR、可选合并到 local、最终报告。推送命令示例：git push 或 git push -u origin <branch>。创建 PR 使用 gh pr create --base "<resolved-base>" --head "<current-branch>" --title "<subject>" --body-file <pr-body-file>.md。
适用场景：有明确 issue 编号或可创建内联 issue 的小型临时工作；需要结构化 PR 正文、测试证据、合并风险说明和 QA 交接的仓库。
限制：任何 stage、push 或 gh pr create 之前必须获得用户合并审批；用户离开时只展示草稿并停止。默认分支 PR 必须包含 Closes #N；非默认目标分支和 delivery 分支 local 使用普通 issue 引用并说明完成方式。不得添加共同作者、AI 或工具署名。gh 查询失败视为未知，不得据此创建第二个 PR。合并冲突由用户处理，shipping 不解决冲突。其他细节如具体 QA handoff 模板内容、merge-into-local 步骤等，资料未完整展开。