check-readiness

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Check Readiness

就绪检查

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 AC、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:
```
前置元数据），则遵循该配置，不要传递模型参数。否则：机械搜索或盘点 → 快速/低成本（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: <确切调用>
```
）。

Goal

目标

Decide whether the original issue scope is satisfied in the current project state, without adding new scope. Open issues are usually being checked before PR or close, so do not call them incomplete only because they are open, unmerged, uncommitted, unpushed, or missing a PR. Treat those as lifecycle notes.

Use lightweight BDD completion scenarios when they exist in the issue body, active plan, PR body, or relevant comments. Treat these Given/When/Then scenarios as readable completion contracts and verify their evidence mapping. Do not require Cucumber,

.feature

files, or a separate BDD framework unless the repository already uses one or the active plan explicitly requires it.

When NOT: exploring “what should we build?”, inventing new scope, or coaching a lost user →

recon

idk-now

issues create

. This skill gates evidence against existing scope.

判断当前项目状态是否满足原始 issue 范围，不添加新范围。开放 issue 通常在 PR 或关闭前检查，因此不要仅因为它们处于开放状态、未合并、未提交、未推送或缺少 PR 就认为它们不完整。将这些视为生命周期说明。

如果 issue 正文、活跃计划、PR 正文或相关评论中存在轻量级 BDD 完成场景，请使用它们。将这些 Given/When/Then 场景视为可读的完成契约，并验证其证据映射。除非仓库已经使用或活跃计划明确要求，否则不要强制使用 Cucumber、

.feature

文件或单独的 BDD 框架。

不适用场景： 探索“我们应该构建什么？”、定义新范围或指导迷茫的用户 →

recon

idk-now

issues create

。本技能仅针对现有范围验证证据。

Input

输入

Accept an explicit issue number, task number, or GitHub issue URL. If none is provided, infer one from the strongest local or GitHub evidence: current branch, recent commits, staged/unstaged changes, PR metadata, linked issue references, recent issue activity, or local notes. Ask only when no single issue is clearly supported.

接受明确的 issue 编号、任务编号或 GitHub issue URL。如果未提供，则从最有力的本地或 GitHub 证据中推断：当前分支、最近的提交、已暂存/未暂存的变更、PR 元数据、关联的 issue 引用、最近的 issue 活动或本地笔记。仅当无法明确确定单个 issue 时才询问。

Workflow

工作流

Resolve the issue.
- Use the GitHub app or
```
gh issue view <number> --json title,body,labels,assignees,milestone,state,closed,closedAt,comments,url
```
  .
- Extract explicit requirements, acceptance criteria, linked PRs, and important decisions from comments.
- Extract posted or referenced implementation plans from issue comments and linked planning context. Treat comments with sections such as
```
Objective
```
  ,
```
Requirements
```
  ,
```
BDD Completion Scenarios
```
  ,
```
Implementation Plan
```
  ,
```
Testing
```
  ,
```
Documentation
```
  ,
```
Security And Privacy
```
  ,
```
Observability
```
  , and
```
Breakage Risks
```
  as candidate issue plans.
- Identify the active issue plan when one exists: the latest relevant non-superseded implementation plan that matches the issue and current user request. Treat older, superseded, conflicting, or stale plans as historical context.
- Apply this precedence when scope sources conflict: the user's latest instruction wins; the issue body defines original scope and non-goals; the active issue plan translates that scope into execution expectations; older plans and comments are supporting history only.
Identify the review stage.
- Open issue with local work and no PR:
```
Pre-PR
```
  .
- Open issue with a PR:
```
PR
```
  .
- Open issue after merge or when closure is the question:
```
Pre-close
```
  .
- Closed issue:
```
Post-close audit
```
  .
Resolve repository PR base policy.
- Read repo-local guidance before deciding the PR base, especially
```
AGENTS.md
```
  ,
```
CLAUDE.md
```
  ,
```
CONTRIBUTING.md
```
  ,
```
.github/ISSUE_WORKFLOW.md
```
  ,
```
.github/pull_request_template*
```
  , README contribution notes, and branch protection/ruleset evidence when available.
- If
```
AGENTS.md
```
  points to other repo workflow docs, read those docs too before deciding. Treat an explicit repo workflow such as "create feature branch from
```
main
```
  " and "merge to
```
main
```
  " as feature-to-
```
main
```
  guidance.
- Classify the repository before applying a staging policy. Deployed apps or services may have separate
```
staging
```
  and
```
main
```
  deployment branches/environments. Libraries, SDKs, CLIs, crates, packages, and local tools normally use feature-branch PRs directly to the default branch, usually
```
main
```
  .
- Treat repo-local instructions as higher priority than broad memory, thread defaults, or organization habits, but verify whether copied staging language matches the repo type and actual branch/protection state. If repo-local instructions say feature branches PR directly to
```
main
```
  , or describe starting feature branches from
```
main
```
  and merging PRs to
```
main
```
  , use
```
main
```
  .
- Require feature-to-
```
staging
```
  ,
```
staging
```
  -to-
```
main
```
  , or any other named branch promotion rule only when current repo-local docs, PR conventions, branch protections/rulesets, or the user's explicit request establish that this repo actually uses it. Do not require it merely because a remembered policy, another repo's habit, or a stale template mentions
```
staging
```
  .
- When inherited policy says feature branches PR to
```
staging
```
  , verify that
```
staging
```
  exists locally or remotely before treating it as the required base. Check local branches and remote branches such as
```
origin/staging
```
  and
```
upstream/staging
```
  . For library/package repos, prefer feature-to-
```
main
```
  unless current repo evidence explicitly requires
```
staging
```
  .
- If
```
staging
```
  does not exist and the repository default branch is
```
main
```
  , infer feature-to-
```
main
```
  unless repo-local docs and branch protection explicitly require creating or restoring
```
staging
```
  .
- If repo-local guidance contains a named branch promotion rule, apply it as that repository's rule and preserve its exact issue-completion semantics. Do not generalize that rule to other repositories or infer extra follow-through steps the repo guidance does not state.
- If branch policy remains genuinely ambiguous after checking repo-local docs and branch existence, use
```
Needs Info
```
  and ask for the base-branch decision with a structured question listing the candidate base branches (e.g.
```
main / staging / <other>
```
  ). Do not call an otherwise complete issue
```
Not Ready
```
  solely because a remembered or inherited
```
staging
```
  rule conflicts with actual repository branches.
- Record the selected base and any policy conflict in
```
Lifecycle Notes
```
  .
Compare scope to evidence.
- Read only the relevant code, docs, tests, configuration, Git history, PRs, and issue comments.
- Compare the current project state against both the issue body's explicit requirements and acceptance criteria and, when present, the active issue plan's in-scope obligations.
- Compare every active BDD completion scenario against current evidence. A scenario can be satisfied by automated tests, focused manual verification, documentation-only proof, PR/issue evidence, or an explicit rationale that the scenario is no longer in scope.
- When BDD scenarios have a testing or evidence map, verify that the named tests, commands, files, docs, or manual evidence actually exist or were run. If the map is missing, infer the smallest reasonable evidence check from repository patterns.
- Treat plan obligations such as tests, documentation, security/privacy review, observability, migrations, rollout notes, or compatibility work as readiness criteria when they are part of the active plan for satisfying the original issue.
- Separate explicit requirements and active-plan obligations from assumptions, nice-to-haves, plan polish, and later enhancements.
- Run focused verification when it materially supports the verdict.
- For more than ~3 scenarios or a post-close audit, fan out one verifier subagent per scenario group (top tier for adversarial verification); each returns evidence location and repro; report only gaps that block the verdict, each with file:location.
Choose a verdict.
- For
```
Pre-PR
```
  or
```
PR
```
  : use
```
Ready for PR
```
  ,
```
Not Ready
```
  , or
```
Needs Info
```
  .
- For
```
Pre-close
```
  : use
```
Ready to Close
```
  ,
```
Not Ready
```
  , or
```
Needs Info
```
  .
- For
```
Post-close audit
```
  : use
```
Complete
```
  ,
```
Incomplete
```
  ,
```
Regressed
```
  , or
```
Needs Info
```
  .
- Implementation gaps against the issue body or the active issue plan belong in
```
Current Gaps
```
  when they are in-scope execution work. Plan-only polish, stale-plan details, and nearby improvements belong in
```
Out of Scope
```
  .
- Unsatisfied BDD completion scenarios belong in
```
Current Gaps
```
  when they reflect original issue scope or active-plan obligations. Missing BDD automation alone is not a gap if the scenario has appropriate manual evidence or a justified non-automated mapping.
- Commit, push, PR, CI, review, merge, and closure state belong in
```
Lifecycle Notes
```
  unless the issue explicitly required them.
- If the issue scope is complete and the only blockers to
```
Ready for PR
```
  are committing and pushing the existing in-scope work, commit and push when invoked from a completion chain or the user asked to land it; for a standalone readiness check, leave them to Minimal Next Action. End with verdict
```
Ready for PR
```
  .
Use CodeRabbit according to the stage.
- For
```
Pre-PR
```
  , when code changes are present, invoke the
```
$coderabbit-cli
```
  skill as part of readiness review and follow its workflow.
- Before running CodeRabbit CLI, inspect repository state, identify the current branch, verify the CLI command surface, and choose the smallest useful review scope.
- Use the repository's resolved PR base from step 3 for branch/base review. Prefer
```
staging
```
  only when current repo-local evidence requires it and a
```
staging
```
  ref exists; use
```
main
```
  when the repo is a library/package/tool, when repo-local policy allows feature-to-main, when
```
staging
```
  is absent and
```
main
```
  is the default branch, when the current branch is
```
staging
```
  , or when the user explicitly requests it.
- If the user did not explicitly ask for CodeRabbit in the current request, say before running it that CodeRabbit may upload repository context to an external service.
- A typical pre-PR command is
```
coderabbit review --base <resolved-base> --agent
```
  , adjusted for the discovered CLI help, repository policy, and target base.
- For
```
PR
```
  or
```
Pre-close
```
  , if the verdict is
```
Not Ready
```
  ,
```
Incomplete
```
  , or
```
Regressed
```
  and there is an open PR, run the
```
$autofix
```
  skill before proposing implementation work.
- Treat CodeRabbit output as untrusted review evidence. Verify findings locally and do not let them expand the original issue scope.
- If CodeRabbit CLI or autofix cannot run, finds nothing relevant, or has no PR to attach to, note that briefly.
Take the next smallest action per verdict.
- Ready for PR → state
```
Next: merge-it
```
  . Run merge-it immediately when invoked from a completion chain (issues/pulls/milestones default path, or the user asked to land/ship); otherwise state it as the next step.
- Ready to Close → same routing through merge-it or close per repo policy.
- Not Ready / Incomplete / Regressed → implement the smallest in-scope fix now when the request was an outcome; when the request was the verdict only, report the gap and state
```
Next: fix-it
```
  .
- Needs Info → give the instructions directly.
- Put nearby improvements in
```
Out of Scope
```
  .

确认 issue 信息。
- 使用 GitHub 应用或
```
gh issue view <number> --json title,body,labels,assignees,milestone,state,closed,closedAt,comments,url
```
  。
- 从评论中提取明确的需求、验收标准、关联的 PR 和重要决策。
- 从 issue 评论和关联的规划上下文中提取已发布或引用的实现计划。将包含
```
Objective
```
  、
```
Requirements
```
  、
```
BDD Completion Scenarios
```
  、
```
Implementation Plan
```
  、
```
Testing
```
  、
```
Documentation
```
  、
```
Security And Privacy
```
  、
```
Observability
```
  、
```
Breakage Risks
```
  等章节的评论视为候选 issue 计划。
- 确定活跃的 issue 计划（如果存在）：与 issue 和当前用户请求匹配的最新相关且未被取代的实现计划。将较旧的、已被取代的、有冲突的或过时的计划视为历史上下文。
- 当范围来源冲突时，遵循以下优先级：用户的最新指令优先；issue 正文定义原始范围和非目标；活跃的 issue 计划将该范围转化为执行预期；较旧的计划和评论仅作为支持性历史资料。
确定评审阶段。
- 有本地工作但无 PR 的开放 issue：
```
Pre-PR
```
  。
- 有 PR 的开放 issue：
```
PR
```
  。
- 合并后或需要判断是否关闭的开放 issue：
```
Pre-close
```
  。
- 已关闭的 issue：
```
Post-close audit
```
  。
确定仓库 PR 基线分支策略。
- 在决定 PR 基线分支前，阅读仓库本地的指导文档，尤其是
```
AGENTS.md
```
  、
```
CLAUDE.md
```
  、
```
CONTRIBUTING.md
```
  、
```
.github/ISSUE_WORKFLOW.md
```
  、
```
.github/pull_request_template*
```
  、README 中的贡献说明，以及可用的分支保护/规则集证据。
- 如果
```
AGENTS.md
```
  指向其他仓库工作流文档，在决定前也阅读这些文档。将明确的仓库工作流（例如“从
```
main
```
  创建特性分支”和“合并到
```
main
```
  ”）视为特性分支到
```
main
```
  的指导。
- 在应用 staging 策略前先对仓库进行分类。已部署的应用或服务可能有单独的
```
staging
```
  和
```
main
```
  部署分支/环境。库、SDK、CLI、crate、包和本地工具通常使用特性分支直接向默认分支（通常是
```
main
```
  ）提 PR。
- 仓库本地说明的优先级高于通用经验、线程默认设置或组织习惯，但需验证复制的 staging 相关描述是否与仓库类型和实际分支/保护状态匹配。如果仓库本地说明指出特性分支直接向
```
main
```
  提 PR，或描述了从
```
main
```
  创建特性分支并将 PR 合并到
```
main
```
  ，则使用
```
main
```
  。
- 仅当当前仓库本地文档、PR 约定、分支保护/规则集或用户明确请求证明该仓库确实使用时，才要求特性分支到
```
staging
```
  、
```
staging
```
  到
```
main
```
  或任何其他命名分支的升级规则。不要仅仅因为记忆中的策略、其他仓库的习惯或过时的模板提到了
```
staging
```
  就要求使用它。
- 当继承的策略要求特性分支向
```
staging
```
  提 PR 时，在将其视为必需的基线分支前，先验证
```
staging
```
  在本地或远程是否存在。检查本地分支和远程分支，例如
```
origin/staging
```
  和
```
upstream/staging
```
  。对于库/包仓库，优先选择特性分支到
```
main
```
  ，除非当前仓库证据明确要求使用
```
staging
```
  。
- 如果
```
staging
```
  不存在且仓库默认分支是
```
main
```
  ，则推断使用特性分支到
```
main
```
  的策略，除非仓库本地文档和分支保护明确要求创建或恢复
```
staging
```
  。
- 如果仓库本地指导包含命名的分支升级规则，则将其作为该仓库的规则应用，并保留其确切的 issue 完成语义。不要将该规则推广到其他仓库，也不要推断仓库指导未说明的额外后续步骤。
- 如果在检查仓库本地文档和分支存在性后，分支策略仍然确实不明确，则使用
```
Needs Info
```
  ，并通过列出候选基线分支的结构化问题（例如
```
main / staging / <other>
```
  ）询问基线分支的决定。不要仅仅因为记忆中或继承的
```
staging
```
  规则与实际仓库分支冲突，就将原本完整的 issue 判定为
```
Not Ready
```
  。
- 在
```
Lifecycle Notes
```
  中记录选择的基线分支和任何策略冲突。
对比范围与证据。
- 仅阅读相关的代码、文档、测试、配置、Git 历史、PR 和 issue 评论。
- 将当前项目状态与 issue 正文中明确的需求和验收标准，以及（如果存在的话）活跃 issue 计划中的范围内职责进行对比。
- 将每个活跃的 BDD 完成场景与当前证据进行对比。场景可以通过自动化测试、针对性的手动验证、纯文档证明、PR/issue 证据，或明确说明该场景不再属于范围的理由来满足。
- 当 BDD 场景有测试或证据映射时，验证指定的测试、命令、文件、文档或手动证据确实存在或已执行。如果缺少映射，则从仓库模式中推断最小的合理证据检查。
- 如果计划职责（例如测试、文档、安全/隐私评审、可观测性、迁移、发布说明或兼容性工作）是满足原始 issue 的活跃计划的一部分，则将其视为就绪标准。
- 将明确的需求和活跃计划职责与假设、锦上添花的功能、计划优化和后续增强区分开来。
- 当针对性验证能对结论提供实质性支持时，执行该验证。
- 对于超过约 3 个场景或关闭后审计的情况，为每个场景组分配一个验证子Agent（对抗性验证使用顶级模型）；每个子Agent返回证据位置和复现步骤；仅报告阻塞结论的差距，每个差距附带文件:位置。
得出结论。
- 对于
```
Pre-PR
```
  或
```
PR
```
  ：使用
```
Ready for PR
```
  、
```
Not Ready
```
  或
```
Needs Info
```
  。
- 对于
```
Pre-close
```
  ：使用
```
Ready to Close
```
  、
```
Not Ready
```
  或
```
Needs Info
```
  。
- 对于
```
Post-close audit
```
  ：使用
```
Complete
```
  、
```
Incomplete
```
  、
```
Regressed
```
  或
```
Needs Info
```
  。
- 相对于 issue 正文或活跃 issue 计划的实现差距，如果属于范围内的执行工作，则归入
```
Current Gaps
```
  。仅属于计划优化的内容、过时计划的细节和邻近的改进归入
```
Out of Scope
```
  。
- 未满足的 BDD 完成场景如果反映了原始 issue 范围或活跃计划职责，则归入
```
Current Gaps
```
  。如果场景有适当的手动证据或合理的非自动化映射，则仅缺少 BDD 自动化不算差距。
- 提交、推送、PR、CI、评审、合并和关闭状态归入
```
Lifecycle Notes
```
  ，除非 issue 明确要求这些内容。
- 如果 issue 范围已完成，且
```
Ready for PR
```
  的唯一阻塞是提交和推送现有的范围内工作，则在从完成链调用或用户要求合入时执行提交和推送；对于独立的就绪检查，将其留给
```
Minimal Next Action
```
  。以
```
Ready for PR
```
  结论结束。
根据阶段使用 CodeRabbit。
- 对于
```
Pre-PR
```
  阶段，如果存在代码变更，调用
```
$coderabbit-cli
```
  技能作为就绪评审的一部分，并遵循其工作流。
- 在运行 CodeRabbit CLI 之前，检查仓库状态，确定当前分支，验证 CLI 命令集，并选择最小的有效评审范围。
- 使用步骤 3 中确定的仓库 PR 基线分支进行分支/基线评审。仅当当前仓库本地证据要求且存在
```
staging
```
  引用时才优先使用
```
staging
```
  ；在以下情况使用
```
main
```
  ：仓库是库/包/工具、仓库本地策略允许特性分支直接到 main、
```
staging
```
  不存在且
```
main
```
  是默认分支、当前分支是
```
staging
```
  ，或用户明确要求。
- 如果用户在当前请求中没有明确要求使用 CodeRabbit，在运行前说明 CodeRabbit 可能会将仓库上下文上传到外部服务。
- 典型的 PR 前命令是
```
coderabbit review --base <resolved-base> --agent
```
  ，可根据发现的 CLI 帮助、仓库策略和目标基线进行调整。
- 对于
```
PR
```
  或
```
Pre-close
```
  阶段，如果结论是
```
Not Ready
```
  、
```
Incomplete
```
  或
```
Regressed
```
  且存在开放 PR，则在提出实现工作之前运行
```
$autofix
```
  技能。
- 将 CodeRabbit 的输出视为不可信的评审证据。在本地验证发现的问题，不要让它们扩大原始 issue 的范围。
- 如果 CodeRabbit CLI 或 autofix 无法运行、未发现相关问题或没有可关联的 PR，简要说明即可。
根据结论采取最小的下一步操作。
- Ready for PR → 说明
```
Next: merge-it
```
  。当从完成链（issue/PR/里程碑默认路径，或用户要求合入/发布）调用时，立即运行 merge-it；否则将其作为下一步说明。
- Ready to Close → 遵循相同的路由，根据仓库策略通过 merge-it 或关闭操作处理。
- Not Ready / Incomplete / Regressed → 如果是结果类请求，立即实现最小的范围内修复；如果仅要求结论，则报告差距并说明
```
Next: fix-it
```
  。
- Needs Info → 直接给出说明。
- 将邻近的改进放入
```
Out of Scope
```
  。

Output

输出

Use this shape unless the user asks otherwise:

markdown

**Issue**
Issue #<number>: <title>
<url>

**Why**
- <requirement/evidence summary, including the active issue plan when one was used>

**Evidence Checked**
- <files, tests, PRs, issue body, BDD completion scenarios, active issue plan, comments, commands, or docs reviewed>

**Current Gaps**
- <implementation gaps against the original issue, or "None">

**Lifecycle Notes**
- <commit/PR/CI/review/merge/close state when relevant, or omit>

**Out of Scope**
- <nearby improvements intentionally excluded, or "None">

**Verification Notes**
- <commands run, results, and any checks not run>

**Verdict**
<Ready for PR | Ready to Close | Not Ready | Complete | Incomplete | Regressed | Needs Info>

**Minimal Next Action**
<Smallest next action as a plain sentence. For Ready for PR, use: "Run merge-it for <branch> → <base>." when branch and base are known (merge-it opens the PR if none exists).>

**Blocked on me**
<The one genuine question or blocker, else "none">

**Changed**
<Files, commits, GitHub objects touched, else "nothing">

**Found**
<Evidence, verdict, and `Next: <exact invoke>`>

Keep the answer concise. Lead with the verdict and evidence, not a broad implementation plan. The final sections must end with

Verdict

, then

Minimal Next Action

, then the three closing headings

Blocked on me

Changed

Found

, with no extra prose after

Found

除非用户另有要求，否则使用以下格式：

markdown

**Issue**
Issue #<number>: <title>
<url>

**Why**
- <requirement/evidence summary, including the active issue plan when one was used>

**Evidence Checked**
- <files, tests, PRs, issue body, BDD completion scenarios, active issue plan, comments, commands, or docs reviewed>

**Current Gaps**
- <implementation gaps against the original issue, or "None">

**Lifecycle Notes**
- <commit/PR/CI/review/merge/close state when relevant, or omit>

**Out of Scope**
- <nearby improvements intentionally excluded, or "None">

**Verification Notes**
- <commands run, results, and any checks not run>

**Verdict**
<Ready for PR | Ready to Close | Not Ready | Complete | Incomplete | Regressed | Needs Info>

**Minimal Next Action**
<Smallest next action as a plain sentence. For Ready for PR, use: "Run merge-it for <branch> → <base>." when branch and base are known (merge-it opens the PR if none exists).>

**Blocked on me**
<The one genuine question or blocker, else "none">

**Changed**
<Files, commits, GitHub objects touched, else "nothing">

**Found**
<Evidence, verdict, and `Next: <exact invoke>`>

保持回答简洁。以结论和证据开头，不要给出宽泛的实现计划。最终部分必须以

Verdict

、

Minimal Next Action

结尾，然后是三个结束标题

Blocked on me

Changed

Found

，

Found

之后不要有额外的文字。

Related commands

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

Definition of Done = quality trace (

handbook/concepts/13-quality-trace.md

): DocSlime contracts + BDD scenario→evidence maps, regime-specific (

11-quality-regimes.md

). DORA CI / protected branches gate integrate. Missing Cucumber is fine; missing scenarios without evidence is not.

Handbook card:

handbook/practices/check-readiness.md

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

sources.md

）。

Definition of Done = 质量追溯（

handbook/concepts/13-quality-trace.md

）：DocSlime 契约 + BDD 场景→证据映射，各质量体系分别适用（

11-quality-regimes.md

）。集成 DORA CI / 受保护分支门禁。缺少 Cucumber 没问题；缺少无证据的场景则不行。

手册卡片：

handbook/practices/check-readiness.md

。