pre-pr-review

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pre-PR Review

PR前审查

Review the full branch before opening or updating a PR. This skill sees the branch as one coherent change, then adds checks that a single-diff review cannot catch. If the working tree is dirty, it also reviews the local changes against the same rubric — the operator is one step away from committing them into the PR, so they get reviewed too.
在创建或更新PR前审查完整分支。该工具将分支视为一个连贯的变更,进而发现单次差异审查无法捕捉到的问题。如果工作区存在未提交内容,它还会按照相同准则审查本地更改——因为操作者即将把这些内容提交到PR中,所以也需要进行审查。

Source of Truth

事实依据

Use
references/review-rubric.md
for the shared per-diff rubric: severity, categories, fix policy, and language-agnostic checklist.
使用
references/review-rubric.md
作为通用的逐差异审查准则,包括严重程度、分类、修复策略以及与语言无关的检查清单。

When to Use

使用场景

  • pre-commit-review
    reviews staged, unstaged, and untracked local changes only.
  • pre-pr-review
    reviews committed branch state (
    <base>..HEAD
    ) plus branch-level history/intent. If the tree is dirty, it folds local changes into the same review.
  • Run it before opening a PR, or before updating a PR after meaningful branch rewrites.
  • pre-commit-review
    仅审查暂存、未暂存和未跟踪的本地更改。
  • pre-pr-review
    审查已提交的分支状态(
    <base>..HEAD
    )以及分支级别的历史/意图。如果工作区存在未提交内容,它会将本地更改纳入同一审查流程。
  • 在创建PR前,或在对分支进行重大改写后更新PR前运行该工具。

Workflow

工作流程

  1. Resolve the base branch:
    • .turkit.yaml → base_branch
    • git symbolic-ref refs/remotes/origin/HEAD
    • fallback
      main
  2. Inspect
    git status --short
    . Set
    LOCAL_DIRTY = true
    if anything is staged, unstaged, or untracked. Do not redirect the operator to
    pre-commit-review
    — they invoked
    pre-pr-review
    deliberately. Continue.
  3. Count commits with
    git rev-list --count <base>..HEAD
    . If > 20, warn and ask whether to proceed.
  4. Gather:
    • git log --oneline <base>..HEAD
    • git log --stat <base>..HEAD
    • git diff <base>..HEAD
    • git diff <base>..HEAD --name-only
    • git show <hash>
      only when a cross-commit finding needs deeper inspection
    • If
      LOCAL_DIRTY
      : also
      git diff --cached
      ,
      git diff
      , and
      git ls-files --others --exclude-standard
      . Treat the union of staged + unstaged + untracked content as the Local scope; the committed
      <base>..HEAD
      diff is the Branch scope.
  5. Load project rules before judging:
    • Read
      .turkit.yaml
      if present.
    • If it defines
      rules.docs
      , read the relevant listed docs.
    • Otherwise read relevant defaults when present:
      CLAUDE.md
      ,
      AGENTS.md
      , and
      docs/conventions/*.md
      .
  6. Run the project's lint command (
    .turkit.yaml → commands.lint
    , fallback per
    references/build-tool-detection.md
    ). If unavailable, continue and report it.
  7. Walk the shared rubric against the full branch diff, then apply any loaded project rules that are relevant to the branch. If
    LOCAL_DIRTY
    , walk the same rubric against the Local scope (changed hunks for staged/unstaged, full file for untracked). Label every finding with its scope (
    Branch
    or
    Local
    ).
  8. Walk the branch-level checklist and use the branch output sections in
    references/branch-review.md
    . The checklist applies to the Branch scope; the Local scope is judged on per-diff rubric only.
  9. Apply only the shared rubric's Auto-fix bucket. Auto-fixes land unstaged on current
    HEAD
    ; do not create/amend commits or rewrite history.
  10. Re-run lint. If auto-fixes landed, the verdict cannot be
    Ready for PR
    ; the operator must commit/amend and re-run this review.
  11. Report using the output format below.
  1. 确定基准分支:
    • .turkit.yaml → base_branch
    • git symbolic-ref refs/remotes/origin/HEAD
    • 默认回退为
      main
  2. 检查
    git status --short
    输出。如果存在暂存、未暂存或未跟踪内容,设置
    LOCAL_DIRTY = true
    不要引导操作者使用
    pre-commit-review
    ——他们是特意调用
    pre-pr-review
    的,继续执行流程。
  3. 使用
    git rev-list --count <base>..HEAD
    统计提交数量。如果超过20个,发出警告并询问是否继续。
  4. 收集以下信息:
    • git log --oneline <base>..HEAD
    • git log --stat <base>..HEAD
    • git diff <base>..HEAD
    • git diff <base>..HEAD --name-only
    • 仅当跨提交的问题需要深入检查时,使用
      git show <hash>
    • 如果
      LOCAL_DIRTY
      为true:同时收集
      git diff --cached
      git diff
      git ls-files --others --exclude-standard
      的输出。将暂存+未暂存+未跟踪内容的合集视为本地范围;已提交的
      <base>..HEAD
      差异视为分支范围。
  5. 在评估前加载项目规则:
    • 如果存在
      .turkit.yaml
      文件则读取它。
    • 如果文件中定义了
      rules.docs
      ,读取列出的相关文档。
    • 否则读取相关默认文档(如果存在):
      CLAUDE.md
      AGENTS.md
      以及
      docs/conventions/*.md
  6. 运行项目的lint命令(
    .turkit.yaml → commands.lint
    ,默认规则参考
    references/build-tool-detection.md
    )。如果无法运行,继续流程并报告该情况。
  7. 针对完整分支差异执行通用审查准则,然后应用所有与该分支相关的已加载项目规则。如果
    LOCAL_DIRTY
    为true,针对本地范围执行相同的审查准则(暂存/未暂存内容检查变更块,未跟踪内容检查完整文件)。为每个问题标记其所属范围(
    Branch
    Local
    )。
  8. 执行分支级检查清单,并使用
    references/branch-review.md
    中的分支输出部分。该检查清单适用于分支范围;本地范围仅按照逐差异准则评估。
  9. 仅应用通用审查准则中的自动修复项。自动修复将应用于当前
    HEAD
    的未暂存状态;不要创建/修改提交或重写历史。
  10. 重新运行lint。如果应用了自动修复,则审查结论不能为
    Ready for PR
    ;操作者必须提交/修改并重新运行该审查。
  11. 按照以下输出格式生成报告。

Branch-Level Checklist

分支级检查清单

Walk the branch-level checklist and use the branch output sections in
references/branch-review.md
. It owns the checklist (B1–B4) and the branch output sections (Branch summary, Per-Commit, Cross-Commit, Branch-Level, Verdict). The checklist applies to the Branch scope; the Local scope is judged on per-diff rubric only.
执行分支级检查清单,并使用
references/branch-review.md
中的分支输出部分。该文档包含检查清单(B1–B4)和分支输出章节(分支摘要、逐提交、跨提交、分支级别、结论)。检查清单适用于分支范围;本地范围仅按照逐差异准则评估。

Output Format

输出格式

The Branch summary, Per-Commit, Cross-Commit, Branch-Level, and Verdict sections live in
references/branch-review.md
. The per-diff sections below are specific to this skill.
markdown
undefined
分支摘要、逐提交、跨提交、分支级别和结论章节位于
references/branch-review.md
中。以下逐差异章节为该工具特有。
markdown
undefined

Mechanical Pre-pass (lint)

机械预检查(lint)

  • Ran:
    <exact command>
  • Findings kept: N
  • Findings dropped as false positives: N — list with reasons
  • Notable rules triggered: short list with file:line
  • 已运行:<具体命令>
  • 保留的问题:N
  • 标记为误报的问题:N — 列出问题及原因
  • 触发的重要规则:简短列表,包含文件:行号

Local (uncommitted)

本地(未提交)

Only present when the working tree was dirty. Findings against the per-diff rubric on staged + unstaged + untracked.
  • [P0|P1] [Category] [Local] [file:line] What and why
  • Or: "No findings — local diff is clean and ready to commit."
仅当工作区存在未提交内容时显示。针对暂存+未暂存+未跟踪内容,按照逐差异准则发现的问题。
  • [P0|P1] [分类] [Local] [文件:行号] 问题描述及原因
  • 或:“无问题——本地差异已清理,可提交。”

Fixes Applied

已应用的修复

Auto-fixes from the shared rubric. All landed unstaged on current HEAD.
  • [Category] [file:line] What changed
来自通用审查准则的自动修复项。所有修复均应用于当前HEAD的未暂存状态。
  • [分类] [文件:行号] 变更内容

Required Changes

必需变更

  • [P0|P1] [Category] [file:line | commit:<hash>] What must change and why it cannot be auto-fixed
  • Suggested rebase plan, if history rewrite is required (do not execute it)
  • [P0|P1] [分类] [文件:行号 | commit:<哈希值>] 必须修改的内容及无法自动修复的原因
  • 建议的变基方案(如果需要重写历史)——不要执行该操作

Blocking Issues

阻塞性问题

  • [P0|P1] [Category] [file:line | commit:<hash>] Rare issue not covered above
  • [P0|P1] [分类] [文件:行号 | commit:<哈希值>] 上述未涵盖的罕见问题

Suggested Improvements

建议改进项

  • [Category] Improvement and expected benefit
  • [分类] 改进建议及预期收益

Positive Signals

积极信号

  • Short bullet only when it reduces review ambiguity
  • 仅在减少审查歧义时使用简短项目符号

Verification

验证

  • Ran: exact commands
  • Residual failures, if any
  • Skipped: relevant checks not run and why
  • 已运行:具体命令
  • 剩余失败项(如有)
  • 已跳过:未执行的相关检查及原因

Residual Risks

剩余风险

  • Remaining uncertainty
undefined
  • 仍存在的不确定性
undefined

Guardrails

约束规则

  • Never stage, commit, amend, rebase, reset, push, force-push, or rewrite history.
  • Never edit outside branch diff scope unless an in-scope auto-fix requires a sibling/shared file.
  • Branch history changes are recommendations only.
  • Apply
    references/output-preferences.md
    for operator-facing language/style.
  • 绝不要暂存、提交、修改、变基、重置、推送、强制推送或重写历史。
  • 除非范围内的自动修复需要修改关联/共享文件,否则不要编辑分支差异范围外的内容。
  • 分支历史变更仅作为建议。
  • 面向操作者的语言/风格需遵循
    references/output-preferences.md