用途
work-with-pr 是一个用于执行完整 Pull Request（PR）生命周期的技能。它适用于需要按规范化流程提交代码变更的场景：从为每个任务创建独立的 git worktree 开始，经过实现、验证，直到 PR 被合并。其核心目标是把工作拆分为最小的、可独立编译、通过检查、能自洽的原子 PR，而不是简单地"一个任务一个 PR"。
主要能力
-
PR 拆分与并行：在开始前将任务分解为最小的原子 PR，每个都经过编译、通过检查并交付一个可评审的切片。独立切片从基分支分出并行运行；有依赖的切片则层层叠加。推荐并发构建多个独立 PR——可通过子代理（每个 PR 一个后台子代理）或团队模式（team_mode）实现。
-
隔离的 worktree：为每个 PR 创建全新的隔离 worktree，用户主工作目录仅作为只读上下文。worktree 放置在仓库的同级目录下。
-
ulw-loop 驱动实现：所有实现都通过 ulw-loop 技能驱动，用二元成功标准分解目标，将代码编辑和 QA 委派给合适大小的子代理。
-
证据绑定的手动 QA：任何到达 OpenCode 或 Codex 的变更在驱动真实环境（tmux / HTTP / 浏览器 / GUI）并写出证据到磁盘之前都不算完成。没有证据文件即视为 QA 未发生，不得提交或推送。类型检查通过、bun test 通过都不算 QA。
-
验证循环：包含两道门禁——Gate A（CI，通过 gh pr checks 检查 bun test、typecheck、build）与 Gate B（Cubic，cubic-dev-ai[bot] 给出 "No issues found"）。任一失败即回到 Phase 1 修复并重新 QA。循环无迭代上限。
-
合并与清理：默认启用自动合并（auto-merge），等待实际合并完成后同步 .omo 状态到主仓库并移除 worktree。
使用方式
技能按四个阶段执行：
- Phase 0 设置：决定 PR 拆分，解析仓库上下文（如 REPO、REPO_NAME、BASE_BRANCH="dev"），创建分支（如 feature/... 或 fix/...），创建 worktree（路径为 ../${REPO_NAME}-wt/${BRANCH_NAME}），并在 worktree 内安装依赖。
- Phase 1 实现：在 worktree 内通过 ulw-loop 技能实现，遵守范围纪律，原子提交（3+ 文件变更至少 2 次提交，5+ 至少 3 次，10+ 至少 5 次），推送前运行本地验证（bun run typecheck、bun test、bun run build）。
- Phase 2 创建 PR：推送并创建 PR，PR 描述用英文撰写，面向未跟踪实现过程的评审者。如需要截图或终端 PNG，按 docs/reference/github-attachment-upload.md 上传。
- Phase 3 验证循环：等待 CI 完成（通过 monitor 订阅，不用 --watch 阻塞），检查 Cubic 审核。失败时读取日志修复、重新 QA、原子提交、推送，再从 Gate A 重新验证。
- Phase 4 合并与清理：启用 auto-merge（使用 --merge，禁用 --squash 或 --rebase），订阅合并完成，同步 .omo 状态，移除 worktree 并 prune，最后报告完成情况。
失败恢复方面：遇到不可恢复错误（如与基分支的合并冲突、基础设施故障）时，不要删除 worktree，报告发生了什么、尝试了什么、当前状态，并附上 worktree 路径以便用户手动继续。合并冲突可执行 git rebase origin/$BASE_BRANCH 解决。
适用场景
适用于需要严格 PR 工作流、手动 QA 证据、CI 与自动代码审核双重门禁的代码变更交付场景。特别适合需要将大任务拆分为多个小而可评审的 PR 的团队。
限制与注意事项
- 手动 QA 是硬性门槛，仅测试通过不构成完成。
- 修复迭代中必须避免无关改动（范围蔓延），否则会增加调试难度并可能引入新失败。
- Cubic 门禁仅在配额耗尽时可被跳过（记录为 SKIPPED），发现问题时绝不能跳过。
- 反模式中，在主 worktree 而非隔离 worktree 中工作被标记为 CRITICAL 严重级别，可能污染用户工作目录或破坏未提交的工作。
- 在没有手动 QA 证据的情况下提交或推送是不被允许的。
- 关于定价、具体支持的平台列表、更多使用步骤等细节，资料中暂未提供。