用途：将 Paperclip 分支工作整理成针对 paperclipai/paperclip master 的可评审、检查全绿的 PR。每个 PR 执行一次；若一个任务拆成多个 PR，则每个都完整走一遍流程。
主要步骤与能力：
- 前置条件：所有 PR 工作都在专用分支的 git worktree 中进行，主 ~/paperclip 检出通常运行着线上 Paperclip 服务，切勿在其中切换分支。用 git rev-parse --git-dir、git branch --show-current 验证当前 worktree/分支；确认目标 remote/ref（通常为 paperclipai/paperclip 的 master，任务可能指定 origin 或 public-gh 等）。
- 提交全部改动：先做逻辑提交，不遗留未提交文件，不用 stash 后遗忘。提交信息必须以 Co-Authored-By: Paperclip noreply@paperclip.ing 结尾。
- 干净地叠到 master 上：fetch 目标 remote 并 rebase（或重放）分支，消除合并冲突；rebase 后按任务要求重新验证构建/测试。
- 护栏清单：绝不提交 pnpm-lock.yaml（仓库有 action 管理它），若已提交需改写/丢弃；除非底层提交本就涉及且任务明确要求，否则不改 .github/workflows/*；不提交设计截图/线框图，除非确属工作产物；迁移编号递增且与 master 无冲突，若编号被占用需重编号，并保持幂等；每个 PR 变更文件数控制在 100 以内，超出则拆分。
- 开 PR：遵循仓库根目录 CONTRIBUTING.md（https://github.com/paperclipai/paperclip/blob/master/CONTRIBUTING.md）的标题、消息格式与 issue 描述要求；推送分支并用 gh 开 PR，立即记录 PR URL。
- 评审循环：运行 /greploop 公司技能，触发 Greptile 评审、处理评论、推送，直到 Greptile 给出 5/5 且无未解决评论（最多 20 轮），不得提前停止；随后运行 /prcheckloop 并处理可修复的验证/CI 失败。要求 Greptile 达到 5/5、所有测试与验证通过、无合并冲突。
- 汇报与交接：在驱动任务下评论所做工作、PR URL、worktree 路径（用 ~ 表示家目录）、Greptile 分数与检查状态；为每个 PR 创建 pull_request 工作产物（必要时含分支/提交产物）；按任务要求创建并链接后续子 issue。
硬性规则：绝不丢失工作（无孤立 stash、无丢弃文件、不做丢弃提交的 force-push）；始终发布所创建的每个 PR 的 URL。
限制：资料未提供该技能的具体安装命令、收费方式或平台支持范围。