资讯动态

oh-my-pi `/review-prs` 命令实战:并行 PR 分诊、Rebased Worktree 准备与“人类合入”工作流全解析

发布时间:2026/9/10 16:01:48 来源:尧图企业网站定制
oh-my-pi/review-prs命令实战并行 PR 分诊、Rebased Worktree 准备与“人类合入”工作流全解析【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pioh-my-pi 将 PR 审查建模为一条可由 Agent 完整执行的分诊流水线解析待审 PR 集合、每个 PR 派发一个隔离的task子代理、在专用 worktree 中 rebase 并只修合并阻塞项最后汇总成表格交还人工合入。本篇以仓库内的命令模板 .omp/commands/review-prs.md 为主体完整继承其参数约定、六步子代理工作流与硬规则并结合github工具源码pr_checkout/pr_push/search_prs实现与pr://内部 URL 机制逐段补充实现级依据帮助你在 oh-my-pi 中落地一套可复制的并行 PR 审查流程。1. 命令定位项目级原生 slash commandreview-prs不是内置命令而是 oh-my-pi 的“文件型 slash command”一个 Markdown 模板放在项目的 .omp/commands/ 目录下同目录还有 cleanup.md、triage.md 等由 coding-agent 在提示词阶段展开为完整的提示模板注入给 Agent。从 docs/slash-command-internals.md 的加载规则看原生命令的解析优先级为“项目先于用户”项目级读取cwd/.omp/commands/*.md用户级读取活动 profile 的commands/*.md默认~/.omp/agent/commands/*.mdgetConfigDirs()返回项目在前、用户在后因此同名时项目原生命令压过用户命令。这意味着团队把review-prs.md提交进仓库后所有克隆仓库的成员在该项目中都能直接以/review-prs触发同一套分诊流程且项目版本始终优先。模板本身的目标一句话概括原文开头Parallel PR triage: decide merge-worthiness, prepare rebased worktrees, fix blockers, return them for human merge. 并行 PR 分诊判定是否值得合并、准备 rebase 好的 worktree、修复阻塞项最后交回给人工合入。1.1 参数$ARGUMENTS可选空格或逗号分隔的PR 编号/URL或者GitHub 搜索限定符is:open、author:foo、label:bug、draft:false……以及/或时间窗3d、2w、12h。不带任何参数时的默认行为审查“最近 3 天内打开的全部 open PR”。2. 阶段一解析 PR 集合Resolve PRs模板要求先解析$ARGUMENTS显式给出的编号/URL原样使用verbatim不再搜索否则调用github工具的op: search_prs操作解析集合无参数默认调用为github { op: search_prs, query: is:open, since: 3d, limit: 50 }参数传递规则用户给出的限定符原样拼进query若未出现is:open则补上时间窗3d、2w、12h、ISO 日期映射到since字段dateField默认created只有用户明确要求“最近被动过”的 PR 时才设updated扇出fan-out前必须先打印解析出的 PR 集合供人工确认审查范围。2.1search_prs的实现事实按 docs/tools/github.mdsearch_prs实际执行gh api -X GET /search/issues -f qquery [date qualifier] [repo:repo] is:pr -F per_pagelimitlimit默认10向下取整、钳制到50、必须 0——模板默认limit: 50恰好取满上限一次拿到尽可能多的候选since/until接受相对时长3d、12h、2w、2mo、1y、YYYY-MM-DD或 ISO datetime省略repo时默认取当前 checkout 的owner/repo除非 query 已含repo:/org:/user:/owner:限定符每个结果输出为带仓库/状态/作者/标签/时间戳/URL 的条目便于直接生成“解析集合”确认清单。所有gh调用都经由packages/coding-agent/src/utils/github.ts的github.run/json/text()封装非交互环境、5 分钟命令超时、8 MiB 输出上限未认证时映射为可读错误。3. 阶段二每个 PR 一个并行task子代理模板硬性规定MUST 使用并行子代理、一个 PR 一个NEVER 串行循环。每个子代理拿到该 PR 的编号、head ref、作者与工作流说明子代理之间相互隔离仅当“PR A 的修复显然与 PR B 冲突”时才通过irc通报。这一点与task工具的模型侧提示一致packages/coding-agent/src/prompts/tools/task.md 要求“并行化独立的职责边界Parallelize independent ownership”同文件编辑不保证可合并、共享文件的兄弟代理应经由hub/irc协调并指定唯一的集成负责人。PR 分诊场景下每个 worktree 独立、路径不同天然满足“独立所有权”前提。以下task子代理的标准工作流Read decide → Checkout → Symlink → Rebase → Review fix → Commit → Report完整来自模板是整条流水线的执行内核。3.1 Read and decide先读后判读取pr://N默认含评论?comments0跳过评论与pr://N/diff变更文件清单完整 unified diff 用pr://N/diff/all单文件切片用pr://N/diff/i检查git log origin/main与gh search prs排查“等价改动是否已合入”给出裁决slopAI 生成的噪音、坏掉、偏离规格或净负价值 → 丢弃1–2 行理由不 checkoutsuperseded已被 main 或更新的 PR 修复/覆盖 → 丢弃并给出指向worthy进入后续流程。拿不准时判worthy——由人类在真实分支上最终决定。实现依据docs/tools/read.md 说明pr://N及长形式pr://owner/repo/N路由到与github工具共享的 SQLite 缓存?comments0选择无评论渲染PR diff 三件套/diff、/diff/i、/diff/all共享同一次gh pr diff调用的pr-diff缓存行键为 repoPR 号因此子代理连续读取 diff 切片不会重复打 GitHub API。docs/tools/github.md 的 Limits 一节还给出边界pr://视图的 PR 文件预览仅前50个文件FILE_PREVIEW_LIMIT超大的聚合 diff 会回退到分页 files API每页 100 个文件、至多 3000 个二进制或单文件过大时保留清单并标注 patch 不可用。3.2 Checkout必须用github pr_checkout模板给出gh_PRNUMBER # pr_checkout creates ~/.omp/wt/encoded-repo/pr-N/ and configures push remote并强调MUST 使用github工具的pr_checkout禁止裸gh pr checkout——因为它会创建“后续pr_push可直接对接”的专用 worktree。从源码看这套约束为何成立packages/coding-agent/src/tools/gh-pr-checkout.ts、docs/tools/github.md本地分支名恒为pr-numberworktree 路径为worktrees-base/number-repo-hashrepo-hash是主仓根路径的 7 位十六进制摘要hashPath见 packages/utils/src/dirs.ts基础目录按顺序解析有效的OMP_WORKTREE_DIR→worktree.base设置 → profile/XDG 数据根默认通常~/.omp/wt路径冲突时resolveAvailableWorktreePath()追加-2/-3… 后缀上限 100 次尝试所有 git 变更先经过withRepoLock()packages/coding-agent/src/utils/repo-lock.ts按主仓根串行化——因为多 worktree 共享.git/config、packed-refs等文件并行 checkout 不能竞态推送元数据以git config写入主仓共享配置branch.pr-number.remote/.merge/.pushRemote/.ompPrHeadRef/.ompPrUrl/.ompPrIsCrossRepository/.ompPrMaintainerCanModifypr_push正是靠回读这些键推导 refspec没有 checkout 过就无法 push跨仓 PR 会解析 head 仓库克隆 URL复用同 URL 的现有 remote 或新建fork-owner/fork-owner-nrefs/heads/pr-number已存在且指向不同提交时除非forcetrue重置到 PR head否则失败已存在匹配 worktree 则直接复用并报告reused: true。3.3 Symlink build artifactsworktree 里先软链主仓产物模板要求在 worktree 里执行任何 build/test之前从主 checkout 软链构建产物避免bun check/cargo build/ native-loader 重复编译MAINabsolute path to main worktree, e.g. ~/Projects/pi WT$(pwd) # Rust target dir JS deps (root-level in this monorepo) ln -snf $MAIN/target $WT/target ln -snf $MAIN/node_modules $WT/node_modules # Prebuilt native addon (avoids 30s napi-rs rebuild). Link only the .node # binaries — the rest of packages/natives/native/ is tracked by git, so # folder-level symlinks would shadow PR-modified files and break review. for f in $MAIN/packages/natives/native/*.node; do [ -e $f ] ln -snf $f $WT/packages/natives/native/ done配套的三条硬性注意事项均为模板原文约束$MAIN应在pr_checkout之前从原始 cwd 用git rev-parse --show-toplevel推导软链必须用绝对路径worktree 位于主仓之外相对路径会断链禁止整目录软链packages/natives/native/该目录中除.node外的文件被 git 跟踪目录级软链会遮蔽 PR 修改过的文件、直接破坏审查。只链.node二进制即可跳过 napi-rs 30 秒以上的重建同时保留对 PR 改动文件的完整可见性。这与本 monorepo 的实际布局吻合target/与node_modules/均在仓库根Rust workspace 根 Cargo.toml、JS 工作区根 package.json预编译原生插件位于 packages/natives/native/其 TypeScript 包装见 packages/natives/。3.4 Rebase机械冲突修语义冲突停git fetch origin main git rebase origin/main机械性冲突格式、import 顺序、相邻行编辑解决并git rebase --continue语义性冲突git rebase --abort在最终报告里注明不要提交。3.5 Review and fix只修合并阻塞项审查维度正确性、安全、回归、破坏性变更影响、新增路径的测试覆盖。修复范围严格限定为合并阻塞项build/test 失败显而易见的 PR 引入 bugPR 目标本身要求的边界情形。明确禁止为“品味”重写、顺带重构、扩大范围。每次修复的要求先读现有模式、遵循 AGENTS.md 的仓库约定、为行为变更补/改测试、只跑改动区域的定向测试文件子代理里禁止跑全项目测试最后对“所有被编辑文件的并集”执行bun fmt。3.6 Commit一个 conventional commit绝不碰作者历史在 rebase 后的 PR 分支之上提交一个conventional commit / 逻辑修复git add -A git commit -m fix(scope): what why Addresses review feedback on #PR.红线不得 amend 作者提交、不得 push、不得 merge、不得 force-push 作者历史——人工负责审查与合入。这与github工具的审批模型也一致pr_checkout与pr_push都要求执行审批docs/tools/github.md “Availability and approval”而本命令干脆让 Agent 止步于本地 worktree。3.7 Report子代理的统一回报格式PR #N title Decision: worthy | slop | superseded Worktree: ~/.omp/wt/.../pr-N (or: not checked out) Rebase: clean | conflicts (resolved | aborted: reason) Fixes: commit shas one-liners (or: none needed) Blockers: anything the human must decide4. 阶段三汇总Aggregate全部子代理结束后打印汇总表| PR | Title | Decision | Rebase | Fixes | Blockers | |----|-------|----------|--------|-------|----------|随后按裁决worthy / slop / superseded分组列出 worktree 路径供人工cd过去逐个审查、合入。由于 worktree 名内含 PR 号与仓 hash如~/.omp/wt/下的number-repo-hash目录按裁决分组的路径清单让人类可以在几分钟内完成“值得合并”的收尾动作。5. 硬规则Rules与设计边界模板结尾四条 Rules 是整个流程的安全边界值得逐条对照实现理解MUST 并行子代理、一个 PR 一个NEVER 串行循环——对应task工具的并行 fan-out 语义每个子代理空白启动、独立所有权slop/superseded跳过 checkout——只记录裁决不产生 worktree 噪音修复仅限该 PR diff 内的合并阻塞项——防止子代理在 worktree 里做范围蔓延保证人工合入时 diff 可预期MUST NOT push 或 merge——Agent 的产物是“rebase 干净、阻塞项已修、带一条清晰 commit 的本地 worktree”推送pr_push依赖pr_checkout写入的ompPrHeadRef等 git config 元数据与合入永远留给经过审批的人类。使用前提github工具默认关闭github.enabled默认false需在 Settings → Tools 开启且gh必须位于PATH上、已完成认证search_prs等读操作请求读审批pr_checkout/pr_push请求执行审批。满足这些前提后/review-prs 3d label:bug这类一行命令即可获得“解析确认 → 并行分诊 → worktree 就绪 → 汇总表”的完整闭环。6. 相关源码与文档索引命令模板.omp/commands/review-prs.md同目录可参考 .omp/commands/triage.md、.omp/commands/fix-issues.md命令加载与优先级机制docs/slash-command-internals.mdgithub工具全量输入/输出/流程含search_prs、pr_checkout、pr_pushdocs/tools/github.mdpr://URL 方案与 diff 切片docs/tools/read.mdcheckout 实现packages/coding-agent/src/tools/gh-pr-checkout.ts、packages/coding-agent/src/tools/gh.ts仓库级写串行化packages/coding-agent/src/utils/repo-lock.tsworktree 基础目录解析packages/utils/src/dirs.ts并行子代理语义packages/coding-agent/src/prompts/tools/task.md【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价