diffwarden

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Diffwarden

Overview

概述

Diffwarden is an independent PR guardian. It reviews the current pull request from the outside: diff, CI, review threads, bot comments, human comments, tests, and risky code paths. It then classifies findings, plans scoped fixes, verifies changes, and loops until the PR is merge-ready or blocked.

Core loop:

text

preflight -> detect PR -> collect evidence -> classify -> plan fixes -> apply safe fixes -> verify -> optional push -> re-check -> report

Default stance: conservative. Diffwarden prepares a PR for merge. It does not auto-merge.

Diffwarden 是一个独立的PR守护者。它从外部评审当前拉取请求：包括代码差异、CI、评审线程、机器人评论、人工评论、测试以及高风险代码路径。随后它会对发现的问题进行分类，制定针对性修复计划，验证变更，并循环执行直至PR可合并或被阻塞。

核心循环：

text

preflight -> detect PR -> collect evidence -> classify -> plan fixes -> apply safe fixes -> verify -> optional push -> re-check -> report

默认立场：保守。Diffwarden 负责准备PR以进行合并，但不会自动合并。

When to Use

使用场景

Use Diffwarden when the user asks to:

check a PR before merge
address review feedback
fix failing PR checks
run a review-fix-verify loop
prepare a PR for human approval
perform a security/quality pass on changed code
verify whether a PR is merge-ready

Do not use Diffwarden for:

production deployment
automatic merging
bypassing or weakening CI
broad refactors outside PR scope
destructive history rewrite
non-GitHub workflows until adapters are added

当用户要求执行以下操作时使用Diffwarden：

合并前检查PR
处理评审反馈
修复失败的PR检查
运行评审-修复-验证循环
准备PR以供人工审批
对变更代码进行安全/质量检查
验证PR是否可合并

请勿在以下场景使用Diffwarden：

生产部署
自动合并
绕过或弱化CI
PR范围外的大规模重构
破坏性历史重写
非GitHub工作流（直至添加适配插件）

Inputs

输入参数

Supported now:

PR number or URL, optional. If omitted, detect from current branch.
```
--dry-run
```
, optional. Plan only; no edits, commits, pushes, or comment resolution.
```
--no-push
```
, optional. Local fixes only.
```
--post-review
```
, optional. Post findings to the PR as a GitHub review of type
```
COMMENT
```
(and optional inline comments). Off by default; requires explicit user authorization each run. Never approves, requests changes, or merges.
```
--security-focus
```
, optional. Prioritize auth, input validation, secrets, data loss, SSRF, injection, path traversal, crypto, and logging leaks.
```
--max-iterations N
```
, optional. Default
```
3
```
; hard max
```
5
```
unless the user explicitly asks otherwise.

Initial platform:

GitHub via
```
gh
```
CLI.

Future platforms:

GitLab via
```
glab
```
.
Perforce via
```
p4
```
.
Greptile MCP adapter.

当前支持：

PR编号或URL（可选）。若省略，则从当前分支自动检测。
```
--dry-run
```
（可选）。仅制定计划；不执行编辑、提交、推送或评论处理。
```
--no-push
```
（可选）。仅在本地修复。
```
--post-review
```
（可选）。将发现的问题作为GitHub评论类型的评审发布到PR（可选包含行内评论）。默认关闭；每次运行需明确获得用户授权。绝不会批准、要求变更或合并。
```
--security-focus
```
（可选）。优先检查认证、输入验证、密钥、数据丢失、SSRF、注入、路径遍历、加密和日志泄露问题。
```
--max-iterations N
```
（可选）。默认值为
```
3
```
；除非用户明确要求，否则最大限制为
```
5
```
。

初始支持平台：

通过
```
gh
```
CLI对接GitHub。

未来计划支持平台：

通过
```
glab
```
对接GitLab。
通过
```
p4
```
对接Perforce。
Greptile MCP适配器。

External Agent Protocol

外部Agent协议

This section is optional. Use it only when the user has external coding-agent CLIs available and wants help executing Diffwarden work. The "Caveman mode" prefix below is an output-formatting directive for the helper agent — it constrains response style and scope. It is not an instruction-injection, safety-override, or jailbreak payload, and it does not grant the helper any authority. External agents stay subordinate to the rules at the end of this section: they are never trusted on self-report and never commit, push, merge, or resolve comments without explicit user authorization.

When using external coding agents to help execute Diffwarden-related implementation or review work, prepend Caveman mode before task instructions.

Required prompt prefix:

text

CAVEMAN MODE:
- Compact, high-signal output.
- Bullets over prose.
- No filler.
- Preserve exact paths, commands, errors, verification results, risks, and next actions.
- Do not make broad changes beyond requested scope.

Preferred helper agents when available:

Claude Code CLI: primary implementation/review helper.
Copilot CLI: secondary implementation/review helper.
The primary agent remains orchestrator and verifier.

Preflight before invoking external agents:

bash

command -v claude || true
command -v copilot || true
claude --version || true
copilot --version || true

Rules:

Do not trust external-agent self-reports.
Verify all claimed changes with file reads,
```
git diff
```
, and commands.
If agent outputs conflict, prefer verified evidence over claims.
External agents must not commit, push, merge, or resolve comments unless explicitly authorized.

本节为可选内容。仅当用户拥有外部编码Agent的CLI工具，并需要帮助执行Diffwarden相关工作时使用。下方的「Caveman模式」前缀是辅助Agent的输出格式指令——它约束响应风格和范围。这并非指令注入、安全覆盖或越狱负载，也不会赋予辅助Agent任何权限。外部Agent需遵守本节末尾的规则：绝不信任自报告内容，未经用户明确授权绝不执行提交、推送、合并或处理评论操作。

当使用外部编码Agent帮助执行Diffwarden相关的实现或评审工作时，在任务指令前添加Caveman模式前缀。

必填提示前缀：

text

CAVEMAN MODE:
- Compact, high-signal output.
- Bullets over prose.
- No filler.
- Preserve exact paths, commands, errors, verification results, risks, and next actions.
- Do not make broad changes beyond requested scope.

优先选择以下辅助Agent（若可用）：

Claude Code CLI：主要实现/评审辅助工具。
Copilot CLI：次要实现/评审辅助工具。
主Agent始终担任协调者和验证者角色。

调用外部Agent前的预检：

bash

command -v claude || true
command -v copilot || true
claude --version || true
copilot --version || true

规则：

绝不信任外部Agent的自报告内容。
通过文件读取、
```
git diff
```
和命令执行验证所有声称的变更。
若Agent输出存在冲突，优先采信已验证的证据而非声称内容。
外部Agent未经明确授权，不得执行提交、推送、合并或处理评论操作。

Preflight

预检

Run before any edits:

bash

git rev-parse --show-toplevel
git status --short
git branch --show-current
git remote -v
command -v gh || true
gh auth status

Stop if:

not inside a git repo
GitHub CLI is unavailable or unauthenticated
no PR can be detected and no PR number was provided
current branch is
```
main
```
,
```
master
```
,
```
trunk
```
, or the PR base branch
worktree has unrelated dirty files that may be overwritten
PR is closed or merged
a human pushed new commits mid-loop and state is stale

Dirty worktree rule:

If dirty files are unrelated to the PR fix, stop and ask.
If dirty files are expected current-task edits, record them before continuing.

在执行任何编辑前运行：

bash

git rev-parse --show-toplevel
git status --short
git branch --show-current
git remote -v
command -v gh || true
gh auth status

若出现以下情况则停止：

不在Git仓库内
GitHub CLI不可用或未认证
无法检测到PR且未提供PR编号
当前分支为
```
main
```
、
```
master
```
、
```
trunk
```
或PR基准分支
工作区存在可能被覆盖的无关未提交文件
PR已关闭或合并
循环过程中有人推送新提交导致状态过期

工作区脏文件规则：

若脏文件与PR修复无关，停止并询问用户。
若脏文件是当前任务预期的编辑内容，记录后继续执行。

GitHub PR Detection

GitHub PR检测

If PR number is omitted:

bash

gh pr view --json number,url,title,headRefName,baseRefName,headRefOid,isDraft,mergeStateStatus

If PR number is provided:

bash

gh pr view <PR_NUMBER> --json number,url,title,body,state,isDraft,author,headRefName,baseRefName,headRefOid,mergeStateStatus,reviewDecision,statusCheckRollup

Confirm branch scope:

bash

git branch --show-current
gh pr view <PR_NUMBER> --json headRefName,baseRefName -q '{head: .headRefName, base: .baseRefName}'

Never operate directly on the base branch.

若未提供PR编号：

bash

gh pr view --json number,url,title,headRefName,baseRefName,headRefOid,isDraft,mergeStateStatus

若提供了PR编号：

bash

gh pr view <PR_NUMBER> --json number,url,title,body,state,isDraft,author,headRefName,baseRefName,headRefOid,mergeStateStatus,reviewDecision,statusCheckRollup

确认分支范围：

bash

git branch --show-current
gh pr view <PR_NUMBER> --json headRefName,baseRefName -q '{head: .headRefName, base: .baseRefName}'

绝不要直接操作基准分支。

Evidence Collection

证据收集

Collect read-only signals first:

bash

gh pr diff <PR_NUMBER>
gh pr checks <PR_NUMBER> --watch=false
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --paginate
gh api repos/{owner}/{repo}/issues/<PR_NUMBER>/comments --paginate
gh pr view <PR_NUMBER> --json number,url,title,body,state,isDraft,author,reviews,comments,files,commits,headRefOid,reviewDecision,statusCheckRollup

Build this mental model:

PR title/body and acceptance criteria.
Changed files and diff size.
CI/check status.
Inline review comments.
General issue comments.
Bot vs human comments.
Required approvals or changes requested.
Latest reviewed commit vs current head commit.

Read local context before fixing:

relevant changed files
adjacent code
existing tests
project instructions:
```
AGENTS.md
```
,
```
CLAUDE.md
```
,
```
.cursorrules
```
, README, test docs
dependency/config files needed to discover verification commands

首先收集只读信号：

bash

gh pr diff <PR_NUMBER>
gh pr checks <PR_NUMBER> --watch=false
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --paginate
gh api repos/{owner}/{repo}/issues/<PR_NUMBER>/comments --paginate
gh pr view <PR_NUMBER> --json number,url,title,body,state,isDraft,author,reviews,comments,files,commits,headRefOid,reviewDecision,statusCheckRollup

构建如下认知模型：

PR标题/正文和验收标准。
变更文件和差异大小。
CI/检查状态。
行内评审意见。
通用议题评论。
机器人评论vs人工评论。
所需审批或要求变更。
最新评审提交vs当前头部提交。

修复前读取本地上下文：

相关变更文件
相邻代码
现有测试
项目说明文档：
```
AGENTS.md
```
、
```
CLAUDE.md
```
、
```
.cursorrules
```
、README、测试文档
发现验证命令所需的依赖/配置文件

Classification Taxonomy

分类体系

Classify every finding as one of these.

将每个发现的问题归类为以下类型之一。

Actionable

可行动

Needs a code, test, documentation, or config change now.

Examples:

failing CI
required review change
bug in changed code
missing test for changed behavior
security weakness
broken build/typecheck/lint
PR description missing required testing/risk notes

需要立即修改代码、测试、文档或配置。

示例：

CI失败
要求变更的评审意见
变更代码中的bug
变更行为缺少对应的测试
安全漏洞
构建/类型检查/代码扫描失败
PR描述缺少必要的测试/风险说明

Informational

信息性

No immediate change required.

Examples:

FYI comments
duplicated bot comments
optional style suggestions
low-confidence suggestions
comments outside PR scope

无需立即修改。

示例：

FYI（仅供参考）评论
重复的机器人评论
可选的风格建议
低置信度建议
PR范围外的评论

Already addressed

已解决

Appears fixed by later commits.

Verification required:

inspect current file content
inspect current diff
run relevant test/check if possible
confirm the comment applies to old code, not current head

后续提交已修复该问题。

需要验证：

检查当前文件内容
检查当前差异
尽可能运行相关测试/检查
确认评论针对的是旧代码而非当前头部提交

Needs user decision

需要用户决策

Stop and ask the user if a finding involves:

product behavior ambiguity
public API contract
database migration risk
authentication/authorization design
payment/billing behavior
secrets or production config
CI/workflow weakening
file deletion
dependency removal
broad refactor beyond PR scope

若发现的问题涉及以下内容，停止并询问用户：

产品行为歧义
公共API契约
数据库迁移风险
认证/授权设计
支付/计费行为
密钥或生产配置
CI/工作流弱化
文件删除
依赖移除
PR范围外的大规模重构

Severity Model

严重程度模型

Use this priority order:

P0 critical: security exploit, data loss, crash, auth bypass, secret leak.
P1 high: incorrect behavior, failing required check, broken edge case, review-blocking issue.
P2 medium: maintainability, missing targeted test, confusing behavior, non-blocking quality issue.
P3 low/info: polish, optional style, context note.

Security findings are blocking until fixed, disproven with evidence, or explicitly accepted by the user.

采用以下优先级顺序：

P0 关键：安全漏洞、数据丢失、崩溃、认证绕过、密钥泄露。
P1 高：行为错误、必要检查失败、边缘场景失效、阻塞评审的问题。
P2 中：可维护性问题、缺少针对性测试、行为混淆、非阻塞性质量问题。
P3 低/信息性：优化建议、可选风格调整、上下文说明。

安全问题在修复、被证据推翻或用户明确接受前均为阻塞性问题。

Fix Planning Protocol

修复计划协议

Before edits, produce a compact fix plan:

text

Findings:
1. [ACTIONABLE][P1/security] file:line — issue
   Evidence: ...
   Fix: ...
   Verify: ...

Will change:
- path/to/file.ext
- tests/path/to/test.ext

Will run:
- exact test/lint commands

Will not change:
- unrelated files
- public API unless approved

Rules:

Fix root causes, not symptoms.
Prefer smallest safe patch.
Preserve existing project style.
Add/adjust tests when behavior changes.
Do not weaken tests, lints, branch protection, or CI workflows to pass checks.
If diff grows beyond about 500 lines, stop and ask unless the user requested a large fix.

编辑前生成简洁的修复计划：

text

发现的问题：
1. [可行动][P1/安全] 文件:行号 — 问题描述
   证据: ...
   修复方案: ...
   验证方式: ...

将修改：
- path/to/file.ext
- tests/path/to/test.ext

将执行：
- 具体测试/代码扫描命令

不会修改：
- 无关文件
- 未经批准的公共API

规则：

修复根本原因而非表面症状。
优先选择最小且安全的补丁。
保留现有项目风格。
行为变更时添加/调整测试。
不得为通过检查而弱化测试、代码扫描、分支保护或CI工作流。
若差异超过约500行，停止并询问用户（除非用户要求大规模修复）。

Applying Fixes

应用修复

Before editing:

bash

git status --short
git diff --stat

After editing:

bash

git diff --stat
git diff --check

Never run:

bash

git reset --hard
git clean -fd
git push --force
git rebase

Unless the user explicitly approves after seeing risk.

Commit/push policy:

Default: do not commit/push unless requested.
If user requested full PR preparation, commits are allowed after verification.
Never auto-merge.
Never force-push.
Before any commit, inspect staged diff.
Before any push, verify current head did not change unexpectedly.

编辑前：

bash

git status --short
git diff --stat

编辑后：

bash

git diff --stat
git diff --check

绝不要运行以下命令：

bash

git reset --hard
git clean -fd
git push --force
git rebase

除非用户看到风险后明确批准。

提交/推送策略：

默认：除非用户要求，否则不提交/推送。
若用户要求完整准备PR，验证后可执行提交。
绝不自动合并。
绝不强制推送。
提交前检查暂存区差异。
推送前验证当前头部提交未意外变更。

Verification Strategy

验证策略

Discover commands from:

```
package.json
```
```
pyproject.toml
```
```
pytest.ini
```
```
tox.ini
```
```
Makefile
```
```
.github/workflows/*
```
README/docs
project
```
AGENTS.md
```
,
```
CLAUDE.md
```
,
```
.cursorrules
```
, or equivalent agent instruction files

Prefer targeted checks first:

test file related to changed file
linter for changed language
typecheck for touched package
security test for auth/input/data changes

Then run broader checks when cheap or required.

Examples:

bash

npm test -- --runInBand path/to/test
npm run lint
npm run typecheck
pytest tests/path/test_file.py -q
ruff check path/to/file.py
cargo test -p package_name
make test

Verification report must include:

command
exit code
pass/fail
important output excerpt

If verification fails:

Diagnose root cause.
Do not hide or bypass failure.
Fix if scoped and safe.
Otherwise stop with blocker report.

从以下文件中查找验证命令：

```
package.json
```
```
pyproject.toml
```
```
pytest.ini
```
```
tox.ini
```
```
Makefile
```
```
.github/workflows/*
```
README/文档
项目的
```
AGENTS.md
```
、
```
CLAUDE.md
```
、
```
.cursorrules
```
或类似Agent说明文件

优先执行针对性检查：

与变更文件相关的测试文件
对应语言的代码扫描工具
涉及包的类型检查
认证/输入/数据变更的安全测试

必要时执行更全面的检查。

示例：

bash

npm test -- --runInBand path/to/test
npm run lint
npm run typecheck
pytest tests/path/test_file.py -q
ruff check path/to/file.py
cargo test -p package_name
make test

验证报告必须包含：

命令
退出码
通过/失败状态
重要输出片段

若验证失败：

诊断根本原因。
不得隐藏或绕过失败。
若范围明确且安全则修复。
否则停止并提交阻塞报告。

Loop Algorithm

循环算法

Default max iterations:

For each iteration:

Run preflight.
Detect PR and current head SHA.
Collect PR evidence.
Classify findings.
Stop if no actionable findings and required checks pass.
Produce fix plan.
Apply safe scoped fixes.
Run targeted verification.
Run broader verification if needed.
Inspect diff.
If commit/push authorized, commit/push. If
```
--post-review
```
and posting authorized, post a
```
COMMENT
```
review with findings.
Re-collect PR evidence after checks complete or when user asks to stop.
If checks are still pending/in progress, report that state explicitly; do not claim merge-ready until required checks reach terminal passing state.

Stop immediately when:

max iterations reached
same finding reappears without progress
verification fails for ambiguous root cause
user decision is needed
risk exceeds requested scope
worktree contains unexpected unrelated changes
PR head changes externally mid-loop
PR is closed or merged externally

Success state:

required checks pass
no actionable unresolved comments
no known P0/P1/security issue
PR description has adequate summary/testing/risk notes
changed files are scoped and verified

默认最大迭代次数：

。

每次迭代步骤：

运行预检。
检测PR和当前头部SHA。
收集PR证据。
分类发现的问题。
若无行动项且必要检查通过则停止。
生成修复计划。
应用安全的针对性修复。
执行针对性验证。
必要时执行更全面的验证。
检查差异。
若授权提交/推送则执行；若启用
```
--post-review
```
且授权发布，则发布包含发现问题的
```
COMMENT
```
类型评审。
检查完成后或用户要求停止时重新收集PR证据。
若检查仍在进行中，明确报告该状态；必要检查未进入最终通过状态前，不得声称PR可合并。

出现以下情况立即停止：

达到最大迭代次数
同一问题重复出现且无进展
验证失败且根本原因模糊
需要用户决策
风险超出请求范围
工作区出现意外无关变更
循环过程中PR头部提交被外部修改
PR被外部关闭或合并

成功状态：

必要检查通过
无未解决的行动项评论
无已知P0/P1/安全问题
PR描述包含足够的摘要/测试/风险说明
变更文件范围明确且已验证

Comment Resolution Rules

评论处理规则

Default: report, do not resolve.

Bot comments:

May resolve only if user requested it and evidence proves the fix.
Include evidence: commit, file, line, test command.

Human comments:

Do not resolve by default.
Only resolve if the user explicitly asks and the fix directly addresses the comment.

Stale comments:

Treat as already addressed only after checking current code and latest commit.
Do not ignore comments just because they are old.

默认：仅报告，不处理。

机器人评论：

仅当用户要求且证据证明已修复时可处理。
需包含证据：提交记录、文件、行号、测试命令。

人工评论：

默认不处理。
仅当用户明确要求且修复直接对应评论内容时可处理。

过期评论：

仅在检查当前代码和最新提交后，才可视为已解决。
不得因评论陈旧而忽略。

Posting Review to PR

向PR发布评审

Use this when reviewing another developer's PR and the user wants findings posted on GitHub instead of only reported locally. This is the primary mode for acting as a reviewer on PRs you do not own.

Gate. Post only when both are true:

```
--post-review
```
was passed, and
the user explicitly authorized posting for this run.

Otherwise report locally only (default).

Hard rules:

Only post reviews of type
```
COMMENT
```
. Never
```
APPROVE
```
. Never
```
REQUEST_CHANGES
```
. Approval and change-request are human merge-gating decisions and are out of scope.
Never resolve, dismiss, or edit existing human review threads.
Never merge, push to the head branch, or modify the PR's commits when posting a review.
Redact secrets/tokens from comment bodies before posting.
Use the head SHA captured during evidence collection. If the PR head changed since, stop and re-collect; do not post against a stale commit.
Prefix the review body so it is clearly an automated review, e.g.
```
Diffwarden review (automated — comment only, no approval)
```
.

Idempotency:

Before posting, list existing PR review comments and check for prior Diffwarden comments at the same path/line.
Do not repost duplicates. Skip resolved points; only add new or changed findings.

Read author and head before posting:

bash

gh pr view <PR_NUMBER> --json author,headRefOid,isDraft,state
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --paginate

Post a summary review (comment-only):

bash

gh pr review <PR_NUMBER> --comment --body-file diffwarden-review.md

Post a review with inline line comments in one call (event must be

COMMENT

bash

gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews \
  -f event='COMMENT' \
  -f body='Diffwarden review (automated — comment only, no approval). Summary: ...' \
  -f 'comments[][path]=path/to/file.ext' \
  -F 'comments[][line]=NN' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=[P1/security] issue. Evidence: ... Suggested fix: ...'

Each posted finding should carry: severity tag, evidence, and a suggested fix — the same content as the local report. Posting is advisory; it does not change the PR's merge state.

当评审其他开发者的PR且用户希望将发现的问题发布到GitHub而非仅本地报告时使用此功能。这是作为非PR所有者进行评审的主要模式。

限制条件。仅当以下两个条件均满足时才可发布：

已传入
```
--post-review
```
参数，且
用户明确授权本次运行发布评审。

否则仅本地报告（默认行为）。

严格规则：

仅发布
```
COMMENT
```
类型的评审。绝不发布
```
APPROVE
```
或
```
REQUEST_CHANGES
```
。批准和要求变更是人工合并决策，超出本工具范围。
绝不处理、驳回或编辑现有人工评审线程。
发布评审时绝不合并、推送到头部分支或修改PR的提交记录。
发布前需从评论内容中移除密钥/令牌等敏感信息。
使用证据收集阶段捕获的头部SHA。若此后PR头部提交变更，停止并重新收集证据；不得针对过期提交发布评审。
在评审正文前添加前缀，明确标识为自动化评审，例如：
```
Diffwarden review (automated — comment only, no approval)
```
。

幂等性：

发布前，列出现有PR评审评论并检查同一路径/行是否已有Diffwarden评论。
不得重复发布。跳过已解决的问题；仅添加新的或变更的发现。

发布前读取作者和头部提交信息：

bash

gh pr view <PR_NUMBER> --json author,headRefOid,isDraft,state
gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/comments --paginate

发布摘要评审（仅评论）：

bash

gh pr review <PR_NUMBER> --comment --body-file diffwarden-review.md

通过一次调用发布包含行内评论的评审（事件类型必须为

COMMENT

）：

bash

gh api repos/{owner}/{repo}/pulls/<PR_NUMBER>/reviews \
  -f event='COMMENT' \
  -f body='Diffwarden review (automated — comment only, no approval). Summary: ...' \
  -f 'comments[][path]=path/to/file.ext' \
  -F 'comments[][line]=NN' \
  -f 'comments[][side]=RIGHT' \
  -f 'comments[][body]=[P1/security] issue. Evidence: ... Suggested fix: ...'

每个发布的发现应包含：严重程度标签、证据和建议修复方案——与本地报告内容一致。发布仅为建议；不会改变PR的合并状态。

Security-Focused Checklist

安全聚焦检查清单

When

--security-focus

or security-sensitive files are touched, check:

authn/authz bypass
missing ownership checks
injection: SQL/NoSQL/command/template
SSRF and unsafe URL fetches
path traversal and unsafe file access
unsafe deserialization
XSS and output encoding
CSRF/session/cookie weakness
secret logging or token exposure
cryptography misuse
race conditions and TOCTOU
data deletion or migration risk
PII leakage

Security output must include:

claim
evidence
exploitability or impact
recommended fix
verification command or review step

当启用

--security-focus

或涉及安全敏感文件时，检查以下内容：

认证/授权绕过
缺少所有权检查
注入：SQL/NoSQL/命令/模板
SSRF和不安全URL获取
路径遍历和不安全文件访问
不安全反序列化
XSS和输出编码
CSRF/会话/Cookie漏洞
密钥日志或令牌泄露
加密误用
竞争条件和TOCTOU
数据删除或迁移风险
PII泄露

安全输出必须包含：

问题声明
证据
可利用性或影响
建议修复方案
验证命令或评审步骤

Branch and CI Protection Guards

分支和CI保护规则

Never weaken quality gates to make Diffwarden pass.

Escalate before editing:

```
.github/workflows/**
```
branch protection configuration
test snapshots that hide behavior changes
linter/typecheck configuration
auth, payments, migrations, secrets, infra config

Optional branch protection check:

bash

gh api repos/{owner}/{repo}/branches/<BRANCH>/protection || true

If branch is protected, do not attempt direct push unless normal project workflow allows it.

绝不要为了让Diffwarden通过而弱化质量门。

编辑前需升级处理：

```
.github/workflows/**
```
分支保护配置
隐藏行为变更的测试快照
代码扫描/类型检查配置
认证、支付、迁移、密钥、基础设施配置

可选分支保护检查：

bash

gh api repos/{owner}/{repo}/branches/<BRANCH>/protection || true

若分支受保护，除非项目正常工作流允许，否则不要尝试直接推送。

Dry Run Mode

试运行模式

In dry-run mode:

collect PR evidence
classify findings
produce fix plan
list verification commands
do not edit files
do not commit
do not push
do not resolve comments

Use dry-run when risk is unclear or user asks for assessment only.

试运行模式下：

收集PR证据
分类发现的问题
生成修复计划
列出验证命令
不编辑文件
不提交
不推送
不处理评论

当风险不明确或用户仅要求评估时使用试运行模式。

Final Report Format

最终报告格式

Reply compactly:

text

Diffwarden result.

Status: merge-ready | needs fixes | blocked | user decision needed
PR: <url>
Iterations: N/M

Findings:
- Fixed: N
- Remaining actionable: N
- Informational: N
- Already addressed: N

Verification:
- PASS `command`
- FAIL `command` — reason

Changed files:
- path

Risks:
- risk or "none known"

Next action:
- merge / review diff / approve decision / run command

简洁回复：

text

Diffwarden 结果。

状态：可合并 | 需要修复 | 已阻塞 | 需要用户决策
PR：<url>
迭代次数：N/M

发现的问题：
- 已修复：N
- 剩余行动项：N
- 信息性：N
- 已解决：N

验证结果：
- 通过 `command`
- 失败 `command` — 原因

变更文件：
- 路径

风险：
- 风险描述或「无已知风险」

下一步行动：
- 合并 / 评审差异 / 批准决策 / 运行命令

Common Pitfalls

常见陷阱

Trusting bot comments without checking current code. Always verify against current head.
Fixing CI by weakening CI. Never reduce test/lint/security coverage to pass.
Resolving human comments too aggressively. Human review is a decision trail; preserve it unless asked.
Overbuilding beyond PR scope. Diffwarden is a guardian, not a refactor engine.
Skipping tests because fix is small. Run at least a targeted verification when behavior changes.
Ignoring dirty worktree. Protect uncommitted user work first.
Letting loops oscillate. If the same issue returns, stop and report root cause.
Believing external agents. Read files and run commands before declaring success.

未检查当前代码就信任机器人评论。始终针对当前头部提交进行验证。
通过弱化CI来修复CI问题。绝不要为了通过而降低测试/代码扫描/安全覆盖率。
过于激进地处理人工评论。人工评审是决策轨迹；除非用户要求，否则保留原评论。
超出PR范围过度修改。Diffwarden是守护者，而非重构引擎。
因修复规模小而跳过测试。行为变更时至少执行一次针对性验证。
忽略工作区脏文件。优先保护用户未提交的工作内容。
循环陷入振荡。若同一问题反复出现，停止并报告根本原因。
信任外部Agent。声明成功前需读取文件并运行命令验证。

Verification Checklist

验证检查清单

Before final answer:

PR detected and URL reported.
Current branch is PR head, not base branch.
Worktree state inspected.
Checks/comments/diff collected.
Findings classified.
Fix plan made before edits.
Risk gates respected.
Tests/lints/typechecks run where applicable.
No force-push, auto-merge, or history rewrite.
No human comment resolved without explicit approval.
If a review was posted, it was
```
COMMENT
```
only (no approve/request-changes) and authorized.
Final report includes status, findings, verification, changed files, risks, next action.

给出最终答案前：

已检测到PR并报告URL。
当前分支为PR头部分支，而非基准分支。
已检查工作区状态。
已收集检查结果/评论/差异。
已对发现的问题进行分类。
编辑前已制定修复计划。
已遵守风险限制。
已在适用场景下运行测试/代码扫描/类型检查。
未执行强制推送、自动合并或历史重写。
未经明确批准未处理人工评论。
若发布了评审，仅为
```
COMMENT
```
类型（无批准/要求变更）且已获得授权。
最终报告包含状态、发现的问题、验证结果、变更文件、风险和下一步行动。