pulls

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Pulls

Command-driven GitHub pull request skill. Parse the first token as a command when it matches the table; otherwise map clear intent.

Default: if the user gives only a PR identifier (

#12

, URL, branch) and optional details — no admin command — execute Complete the work. Same when invoked with no args and a PR matches the current branch. Do not ask which admin command to run. Do not stop at

status

critique

refine

Admin commands shape the PR when explicitly requested; they are not the default path.

基于命令驱动的 GitHub 拉取请求（PR）技能。若第一个 token 匹配下表中的命令，则按命令解析；否则根据明确意图映射对应操作。

默认行为： 若用户仅提供 PR 标识符（

#12

、

、URL、分支名）及可选详情——未指定管理命令——则执行完成工作流程。当无参数调用且当前分支存在对应 PR 时，同样执行该流程。不要询问用户要运行哪个管理命令。不要停留在

status

critique

refine

步骤。

管理命令仅在用户明确请求时用于调整 PR，不属于默认执行路径。

Operating contract

运行契约

Shared by every DecisionNerd/dev-skills skill. Canonical copy:

handbook/concepts/14-operating-contract.md

Define done first. Before using tools, write the finish line in one or two lines: the acceptance criteria (existing issue AC, BDD scenarios, tests, or contract when they exist; otherwise propose them and say where they should live) and the evidence that will prove them. Re-check it before reporting done. Never report done on work you did not verify.
Requested scope sets the finish line. A question ("is it ready?", "why is it broken?", "what next?") ends with the answer and a
```
Next:
```
line naming the exact next invoke. An outcome request ("fix", "finish", "land", "#42") continues through the chain (diagnose → fix → test → check-readiness → merge-it) until the outcome or a real blocker. Do not end a turn with "Do you want me to…?" for in-scope, in-repo work.
Stop only for real blockers. Stop and ask only when you cannot continue without the user, or before: deleting data or unmerged work, force-push or history rewrite, changing anything outside this repository (GitHub objects, deployments, live data, production or paid resources, external services), or leaving the requested scope, unless the user's request already named that exact action. Keep the harness's permission prompts for risky commands. Otherwise keep going and put status notes in the same message as the next action.
Ask well, once. For a genuine question use the harness's structured question tool when it has one (Claude Code:
```
AskUserQuestion
```
; Codex:
```
request_user_input
```
when the current mode supports it) with concrete options; otherwise plain text with numbered options. Treat the answer as settled; do not re-open earlier verdicts, plans, or answers unless asked.
Fan out when work is parallel. Use subagents for independent reads (repo survey, evidence gathering, per-option research, per-area audits) and for independent verification (a reviewer that did not write the change). Writes stay single-owner per path set and sequential. Brief every child with goal, done-when, constraints, must-not, and return shape; verify each child's result before consolidating. Use Claude Code's
```
Workflow
```
tool only for orchestration across many subagents that truly needs it; it is expensive.
Pick the model tier per child; defer to routing config. If the harness or user config already routes subagents (Claude Code
```
CLAUDE_CODE_SUBAGENT_MODEL
```
or a CLAUDE.md rule; Codex
```
agents.default_subagent_model
```
or a role's
```
agents.<name>.config_file
```
; Cursor a custom subagent's
```
model:
```
frontmatter), follow it and do not pass a model. Otherwise: mechanical search or inventory → fast/cheap (Claude Code
```
haiku
```
); implementation and evidence gathering → mid (
```
sonnet
```
); planning, review, adversarial verification → top (
```
opus
```
or
```
fable
```
). In Claude Code set it with the
```
Agent
```
tool
```
model
```
param or agent frontmatter
```
model:
```
; in Codex pass a spawn model or set
```
model
```
in the role's config file; in Cursor set
```
model:
```
(default
```
inherit
```
) in
```
.cursor/agents/*.md
```
. Where the harness cannot choose, children inherit the parent model or the harness picks one (Cursor's built-in Explore/Bash/Browser subagents pick per subtask); say which in the status note.
Keep a checklist on long runs. For more than about five steps or work that crosses skills, keep
```
TASKS.md
```
at the repo root and tick items as they finish. Do not commit it unless the repo already tracks one.
Close every run with three headings.
```
Blocked on me
```
(the one genuine question or blocker, else "none");
```
Changed
```
(files, commits, GitHub objects, deploys, else "nothing");
```
Found
```
(evidence, verdict, and
```
Next: <exact invoke>
```
).

所有 DecisionNerd/dev-skills 技能通用。规范副本见：

handbook/concepts/14-operating-contract.md

。

先定义完成标准。 在使用工具前，用一两行文字明确终点：验收标准（若存在现有 issue 的验收标准、BDD 场景、测试或契约，则沿用；否则提出建议并说明应存放的位置）以及证明达标的证据。在报告完成前重新核对。未经验证的工作绝不能报告为已完成。
请求的范围决定终点。 问题类请求（如“是否就绪？”、“为什么失败了？”、“下一步是什么？”）以答案和
```
Next:
```
行结尾，该行需明确下一次调用的具体内容。结果类请求（如“修复”、“完成”、“上线”、“#42”）将沿链路持续执行（诊断→修复→测试→就绪检查→merge-it），直到达成目标或遇到真正的阻塞。对于范围内、仓库内的工作，不要以“你是否需要我…？”结束本轮回复。
仅因真正的阻塞停止。 仅当无法继续且必须用户介入时，或在以下操作前才停止并询问：删除数据或未合并的工作、强制推送或历史重写、修改本仓库外的任何内容（GitHub 对象、部署、实时数据、生产或付费资源、外部服务），或超出请求范围——除非用户的请求已明确指定该操作。保留运行环境对风险命令的权限提示。否则继续执行，并在同一条消息中附上状态说明和下一步操作。
一次问清楚。 对于真实问题，若运行环境有结构化提问工具（Claude Code：
```
AskUserQuestion
```
；Codex：当前模式支持时使用
```
request_user_input
```
），则使用该工具并提供具体选项；否则使用带编号选项的纯文本。将答案视为最终决定；除非用户要求，否则不要重新讨论之前的结论、计划或答案。
并行工作时分发任务。 对于独立读取类工作（仓库调研、证据收集、各选项研究、各领域审计）和独立验证类工作（未编写变更的评审者），使用子 Agent。写入操作在每条路径上保持单一负责人且顺序执行。向每个子 Agent 简要说明目标、完成条件、约束、禁止事项和返回格式；在整合结果前验证每个子 Agent 的输出。仅当确实需要编排大量子 Agent 时才使用 Claude Code 的
```
Workflow
```
工具；该工具成本较高。
为每个子 Agent 选择模型层级；遵循路由配置。 若运行环境或用户配置已为子 Agent 配置路由（Claude Code 的
```
CLAUDE_CODE_SUBAGENT_MODEL
```
或 CLAUDE.md 规则；Codex 的
```
agents.default_subagent_model
```
或角色的
```
agents.<name>.config_file
```
；Cursor 自定义子 Agent 的
```
model:
```
frontmatter），则遵循配置，不传递模型参数。否则：机械搜索或盘点类→快速/低成本模型（Claude Code
```
haiku
```
）；实现和证据收集类→中等模型（
```
sonnet
```
）；规划、评审、对抗性验证类→顶级模型（
```
opus
```
或
```
fable
```
）。在 Claude Code 中通过
```
Agent
```
工具的
```
model
```
参数或 Agent 前置元数据的
```
model:
```
设置；在 Codex 中传递派生模型或在角色配置文件中设置
```
model
```
；在 Cursor 中在
```
.cursor/agents/*.md
```
中设置
```
model:
```
（默认
```
inherit
```
）。若运行环境无法选择模型，子 Agent 继承父模型或由运行环境选择（Cursor 内置的 Explore/Bash/Browser 子 Agent 会根据子任务选择）；在状态说明中注明使用的模型。
长时间运行时维护检查清单。 对于超过约五个步骤或跨技能的工作，在仓库根目录维护
```
TASKS.md
```
，完成项打勾。除非仓库已跟踪该文件，否则不要提交它。
每次运行结束时包含三个标题。
```
Blocked on me
```
（我这边的阻塞：一个真实问题或阻塞项，没有则填“none”）；
```
Changed
```
（变更内容：文件、提交、GitHub 对象、部署等，没有则填“nothing”）；
```
Found
```
（发现内容：证据、结论，以及
```
Next: <具体调用内容>
```
）。

Commands

命令

Command	What it does
`create` / `open`	Open a PR for the current (or named) branch after draft + approval
`update`	Edit title/body/base; refresh checklist from template
`critique`	Critique PR quality (scope, description, tests, risk, reviewability)
`narrow`	Reduce PR scope (split out commits/files into follow-ups)
`widen`	Intentionally expand PR only with clear rationale (usually discourage)
`merge`	Merge the PR (squash when repo practice); hand off to `merge-it` when review/autofix/CI/issue-close are needed
`clean`	Clean description, checklist noise, stale review threads summary
`refine`	Improve title/body/test plan without changing code scope
`explain`	Explain the PR’s changes to the user in plain language
`document`	Improve/add repo docs required by the PR; link from the PR body
`review`	Structured review summary (findings by severity); does not pretend to be CodeRabbit
`status` / `checks`	CI, reviews, mergeability, deploy/preview status
`close`	Close without merging (with reason)
`ready`	Mark ready for review / convert from draft when appropriate
`help` / `library`	List commands

Target: PR number, URL, branch name, or “current branch”.

命令	功能
`create` / `open`	经过草稿+审批后，为当前（或指定）分支创建 PR
`update`	编辑标题/正文/基础分支；从模板刷新检查清单
`critique`	评审 PR 质量（范围、描述、测试、风险、可评审性）
`narrow`	缩小 PR 范围（将提交/文件拆分到后续 PR 中）
`widen`	仅在有明确理由时有意扩大 PR 范围（通常不建议）
`merge`	合并 PR（仓库惯例为 squash 时使用 squash 合并）；需要评审/自动修复/CI/关闭 issue 时转交至 `merge-it`
`clean`	清理描述、检查清单冗余内容、过时评审线程摘要
`refine`	优化标题/正文/测试计划，不改变代码范围
`explain`	用通俗语言向用户解释 PR 的变更内容
`document`	完善/新增 PR 所需的仓库文档；在 PR 正文中添加链接
`review`	结构化评审摘要（按严重程度分类发现）；不冒充 CodeRabbit
`status` / `checks`	查看 CI、评审、可合并性、部署/预览状态
`close`	不合并直接关闭（需说明原因）
`ready`	标记为就绪待评审/在适当时从草稿转为正式 PR
`help` / `library`	列出所有命令

目标对象：PR 编号、URL、分支名或“当前分支”。

Routing

路由规则

No argument: if a PR matches the current branch → Complete the work on it. Else ask via the structured question tool — options:
```
create
```
a PR for this branch / name a PR number or branch /
```
help
```
.
First word is a command: run it. After admin work, state
```
Next: merge-it
```
and run it when the user signaled progress.
Clear admin intent (“open a PR”, “explain this PR”, “narrow this PR”): map and proceed.
PR identifier ± details, no admin command (
```
#12
```
, URL, branch, or
```
#12 fix the flaky check
```
): Complete the work — execute, don’t menu.

Before mutating GitHub (create/edit/merge/close), state the proposed action; ask one structured question with options

<do it> / revise / stop

. Skip when the user’s request already named that exact action. Prefer squash merge when that is repo practice (see

merge-it

). Completion handoffs follow the target skill’s approval rules.

无参数：若当前分支有匹配的 PR → 对其执行完成工作流程。否则通过结构化提问工具询问——选项：为该分支
```
create
```
一个 PR / 指定 PR 编号或分支 /
```
help
```
。
第一个词是命令：运行该命令。管理操作完成后，说明
```
Next: merge-it
```
，并在用户表示要推进时执行。
明确的管理意图（“打开一个 PR”、“解释这个 PR”、“缩小这个 PR 的范围”）：映射到对应命令并继续。
PR 标识符 ± 详情，无管理命令（
```
#12
```
、URL、分支，或
```
#12 修复不稳定的检查
```
）：执行完成工作流程——直接执行，不显示菜单。

在修改 GitHub 资源（创建/编辑/合并/关闭）前，说明拟执行的操作；通过一个结构化问题提供选项

<执行> / 修改 / 停止

。若用户的请求已明确指定该操作，则跳过询问。若仓库惯例为 squash 合并，则优先使用（见

merge-it

）。完成流程的转交遵循目标技能的审批规则。

Shared operations

共享操作

Use references/ops.md for critique/narrow/widen/merge/clean/refine/explain/document as applied to PRs.

PR 相关的 critique/narrow/widen/merge/clean/refine/explain/document 操作请参考 references/ops.md。

Complete the work

完成工作

PR admin (

create

critique

refine

narrow

/ …) shapes the review unit. Completing the work means fixing what’s broken, proving it, landing it, and closing linked issues.

PR 管理（

create

critique

refine

narrow

/ …）用于调整评审单元。完成工作意味着修复问题、验证修复、上线，并关闭关联的 issue。

Default path (identifier ± details, or no-arg with current-branch PR)

默认路径（提供标识符 ± 详情，或无参数且当前分支有对应 PR）

When routed here (no admin command):

Resolve the PR (
```
gh pr view
```
+ checks + reviews); note linked issues.
Fold any user details into focus (e.g. “only CI”, “address review threads”).
Pick the smallest next execution skill from the table and run it now. One-line why — no recommend-only menu.
Chain forward (usually toward
```
merge-it
```
) until merged/closed, blocked on approval, or the user stops you.
If the PR is missing and the branch has shippable work,
```
create
```
/
```
open
```
then continue completion (often
```
merge-it
```
).

当路由到此处（无管理命令）时：

解析 PR（
```
gh pr view
```
+ 检查 + 评审）；记录关联的 issue。
将用户提供的所有详情纳入关注范围（例如“仅 CI”、“处理评审线程”）。
从下表中选择最小的下一步执行技能并立即运行。用一行说明原因——不要只提供推荐菜单。
向前链式执行（通常朝向
```
merge-it
```
），直到合并/关闭、因审批阻塞，或用户停止。
若不存在对应 PR 但分支有可交付的工作，先
```
create
```
/
```
open
```
PR，再继续完成流程（通常是
```
merge-it
```
）。

After explicit admin commands

显式管理命令之后

After

status

checks

critique

explain

review

create

open

, state

Next: merge-it

(or

fix-it

check-readiness

as fits); run it immediately when the user already signaled land/finish.

Situation	Execute
Failing checks / review comments / need autofix→merge→close	`merge-it`
Linked issue not done / gaps vs AC	`check-readiness` then implement or `fix-it`
Bug still open in the diff	`diagnose-bug` / `troubleshoot-app` → `fix-it`
Missing tests / evidence	`test-it`
Missing observability	`observe-it`
Missing repo docs	`document-it` (or `pulls document` )
PR too large / mixed purpose	`pulls narrow` , then continue landing the remnant
Ready to merge (policy already green)	`merge-it` or `pulls merge`
Landed on staging; production next	Recommend `merge-it` (Ship phase) as a follow-up; run it only when the user requests production promotion
Unsure	`recon` (no args)

Do not default to

pulls refine|critique|clean|status

when a PR identifier (or current-branch PR) was given. Prefer execute (

merge-it

fix-it

check-readiness

在执行

status

checks

、

critique

、

explain

、

review

、

create

open

后，说明

Next: merge-it

（或根据情况选择

fix-it

check-readiness

）；若用户已表示要上线/完成，则立即运行。

场景	执行技能
检查失败 / 评审意见 / 需要自动修复→合并→关闭	`merge-it`
关联 issue 未完成 / 与验收标准有差距	`check-readiness` 然后实现或 `fix-it`
差异中仍有未修复的 bug	`diagnose-bug` / `troubleshoot-app` → `fix-it`
缺少测试 / 证据	`test-it`
缺少可观测性	`observe-it`
缺少仓库文档	`document-it` （或 `pulls document` ）
PR 过大 / 目的混杂	`pulls narrow` ，然后继续合并剩余部分
可合并（策略检查已通过）	`merge-it` 或 `pulls merge`
已上线到预发环境；下一步是生产	推荐 `merge-it` （Ship 阶段）作为后续步骤；仅在用户请求生产发布时执行
不确定	`recon` （无参数）

当提供了 PR 标识符（或当前分支有对应 PR）时，不要默认执行

pulls refine|critique|clean|status

。优先执行实际操作（

merge-it

fix-it

check-readiness

）。

Create / open

创建 / 打开

Read
```
AGENTS.md
```
/ PR template / branch policy (feature→
```
main
```
vs feature→
```
staging
```
).
Inspect
```
git status
```
, diff vs base, linked issues.
Draft title + body (summary, test plan, risk, issue links / closing keywords when appropriate).
Approve →
```
gh pr create
```
(no
```
--json
```
on create if unsupported; view afterward).
Continue into Complete the work — usually
```
merge-it
```
— unless the user only asked to open.

读取
```
AGENTS.md
```
/ PR 模板 / 分支策略（feature→
```
main
```
还是 feature→
```
staging
```
）。
检查
```
git status
```
、与基础分支的差异、关联 issue。
起草标题 + 正文（摘要、测试计划、风险、issue 链接 / 适当的关闭关键字）。
审批 →
```
gh pr create
```
（若不支持创建时使用
```
--json
```
，则创建后再查看）。
进入完成工作流程——通常是
```
merge-it
```
——除非用户仅要求打开 PR。

merge vs merge-it

merge 与 merge-it 的区别

```
pulls merge
```
: merge when checks/reviews already satisfy policy, or user insists on merge-only.
If actionable review comments, failing checks, or issue closure verification are needed, invoke merge-it
instead of reinventing that lifecycle.

```
pulls merge
```
：当检查/评审已满足策略要求，或用户坚持仅合并时执行合并。
若有可处理的评审意见、失败的检查，或需要验证 issue 关闭，则调用 merge-it
，而非重新实现该生命周期。

review / status

```
review
```
: read the diff; report only merge-blocking findings, each with file:line and a repro; label non-blocking findings as such. Use an independent reviewer subagent (top tier) when the diff exceeds a few hundred lines. On default completion routing, proceed into
```
fix-it
```
/
```
merge-it
```
for blocking findings. After an explicit
```
review
```
command, state
```
Next: fix-it
```
or
```
Next: merge-it
```
as appropriate.
```
status
```
/
```
checks
```
:
```
gh pr checks
```
, review decision, mergeStateStatus, preview URLs when present. After an explicit
```
status
```
command, state
```
Next: merge-it
```
(or
```
fix-it
```
). On default routing, skip standalone status and go straight to completion.

```
review
```
：读取差异；仅报告阻塞合并的发现，每条都附带文件:行号和复现步骤；将非阻塞发现标记为非阻塞。当差异超过几百行时，使用独立的评审子 Agent（顶级模型）。在默认完成路由下，针对阻塞发现继续执行
```
fix-it
```
/
```
merge-it
```
。显式执行
```
review
```
命令后，根据情况说明
```
Next: fix-it
```
或
```
Next: merge-it
```
。
```
status
```
/
```
checks
```
：执行
```
gh pr checks
```
，查看评审结论、mergeStateStatus、预览 URL（若有）。显式执行
```
status
```
命令后，说明
```
Next: merge-it
```
（或
```
fix-it
```
）。在默认路由下，跳过单独的状态检查，直接进入完成流程。

Output

输出

Blocked on me

我这边的阻塞

none

无

Changed

变更内容

nothing

无

Found

发现内容

Next: merge-it (or the execution skill that best fits the current state)

Next: merge-it（或最符合当前状态的执行技能）

Related skills

Grounding

基础依据

This skill’s TTPs are grounded in current engineering baselines (DORA, GitHub Docs, Fowler/Beck, Google SRE & SWE book, OpenTelemetry, OWASP LLM / NIST AI RMF, Diátaxis — see handbook

sources.md

PRs as the review unit (GitHub Docs); small reviewable changes (Google eng practices); required checks gate trunk (DORA trunk-based).

Handbook card:

handbook/practices/pulls.md

本技能的战术、技术与程序（TTP）基于当前工程基线（DORA、GitHub Docs、Fowler/Beck、Google SRE 与 SWE 书籍、OpenTelemetry、OWASP LLM / NIST AI RMF、Diátaxis——见手册

sources.md

）。

PR 作为评审单元（GitHub Docs）；小型可评审变更（Google 工程实践）；必要检查作为主干门禁（DORA 主干开发模式）。

手册卡片：

handbook/practices/pulls.md

。

pulls

Original

Translation

Pulls

Pulls

Operating contract

运行契约

Commands

命令

Routing

路由规则

Shared operations

共享操作

Complete the work

完成工作

Default path (identifier ± details, or no-arg with current-branch PR)

默认路径（提供标识符 ± 详情，或无参数且当前分支有对应 PR）

After explicit admin commands

显式管理命令之后

Create / open

创建 / 打开

merge vs merge-it

merge 与 merge-it 的区别

review / status

review / status

Output

输出

Blocked on me

我这边的阻塞

Changed

变更内容

Found

发现内容

Related skills

相关技能

Grounding

基础依据