用途
shipping-a-pr 用于管理拉取请求从交付到维护的整个生命周期。当完成的工作需要以 PR 形式发布，或需要创建、同步、更新元数据、检查状态、监控 CI、处理评审意见时使用。它把 PR 相关操作组织为一个工作流、六个并列的阶段文档，按用户诉求命名的阶段进入，而不是每次都从头执行。
阶段划分与默认模式
各阶段及默认完成模式：
- 创建 PR（工作已完成）：creating.md，快照模式
- 让 PR 与基线同步 / 解决与基线的冲突：syncing.md，快照模式
- 更新 PR 标题或正文：body.md，快照模式
- 添加或刷新 PR 截图：screenshots.md，快照模式
- 一次性报告当前检查 / 合并状态：checks.md，快照模式
- 监控 CI / 调查或修复失败的检查：checks.md，等待模式
- 处理评审评论：review-comments.md，快照模式
复合诉求（例如“变基、验证并创建 PR”）视为一个流程：从最早被命名的阶段开始，各文档自行向前串联。若工作本身尚未完成（诉求中捆绑了新的设计或实现），该部分不属于本工作流，应先按 choosing-a-workflow 处理，完成后再回到这里。
完成模式
快照模式是创建、同步或更新 PR 以及一次性状态请求的默认模式。它取一次新鲜的检查与合并状态快照，如实报告待定、失败或不确定状态，然后停止，不轮询，也不修复无关状态。推送本身不会升级模式。
等待模式需要明确的远程完成诉求，例如监控或观察检查、调查 CI、等到全部通过、让 PR 达到可合并。完成条件是：所有已配置检查通过、头部与基线保持最新、GitHub 报告肯定的合并状态；用户要求的草稿会被报告为草稿，绝不会被说成可合并。没有 CI 的仓库会如实报告，而不是默认视为通过。
验证原则
Git 与 GitHub 状态是并发且可变的：基线会移动、CI 有延迟、可合并性按需计算，工作流自身的步骤也会弄脏刚检查过的代码树。因此每个阶段的每一步都遵循四条规则：
- 在行动点验证：推送、gh pr create、gh pr edit、回复讨论串、宣布完成等不可逆步骤，在运行前立即重新检查其依赖的确切状态。
- 验证与最终代码树绑定：在输入未变时可复用先前结果；每次影响代码的推送前，需运行因后续代码、配置、依赖、基线或冲突解决变化而缺失或失效的项目必需检查；若检查、清理或自审又产生相关编辑，需重新评估并重复。
- 实时获取而非记忆：编辑前读取当前正文，列表一律使用 --paginate，推理基线前先 git fetch。
- 不确定不等于肯定：等待模式下，待定或仍在计算的结果（UNKNOWN 合并状态、排队中的检查）会轮询至明确；只有观察到肯定状态才宣布完成。快照模式下则报告为不确定，而不转为监控。
使用方式
根据诉求分类，选择对应阶段文档并阅读执行；门禁与操作细节只存在于阶段文档中，不应仅凭总览摘要执行某个阶段。选定的完成模式需带入该阶段文档，后续推送不改变它。
工作文件
工作流使用的临时文件均位于工作区被 gitignore 的 .thinkrail/context/ 下：pr-body.md 为 PR 正文草稿，始终通过 --body-file 传入而非内联；pr-shots/ 存放待附加的前后对比截图。阶段完成时会删除这些文件（用户手动上传截图期间截图保留，见 screenshots.md）。
结束
每个阶段最终都通过 checks.md 在所选完成模式下结束。
限制
本技能不负责完成 PR 前的新设计或实现；无 CI 的仓库不会有检查通过判定。具体安装命令、支持平台与收费信息暂未提供。