find-bugs

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<EXTREMELY-IMPORTANT> This skill is report-only and must stay evidence-driven.

Non-negotiable rules:

Read the full branch diff before reporting findings.
Verify each finding against surrounding code and framework behavior.
Report only real defects or vulnerabilities, not stylistic opinions.
Keep the workflow read-only. Do not edit application code as part of this skill.
Use the checklist reference to stay systematic, but do not paste the entire checklist into every invocation.

</EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT> 此技能仅用于报告，且必须基于证据驱动。

不可妥协的规则：

报告发现的问题前，先完整阅读分支差异。
结合周边代码和框架行为验证每个发现的问题。
仅报告真实的缺陷或漏洞，不涉及风格层面的意见。
工作流仅为只读模式。不得在此技能中编辑应用代码。
使用检查清单参考来保持系统性，但不要在每次调用时粘贴完整的检查清单。

</EXTREMELY-IMPORTANT>

Find Bugs

查找Bug

Inputs

输入

```
$request
```
: Optional review guidance such as focus area, threat model, or subsystem hint

```
$request
```
：可选的审查指导，例如重点领域、威胁模型或子系统提示

Goal

目标

Produce a credible branch review that:

reads the actual changed code
maps the relevant attack and defect surfaces
verifies findings before reporting
prioritizes real issues by severity
clearly states clean results when nothing significant is found

生成可信的分支审查报告，需满足：

读取实际变更的代码
梳理相关的攻击面和缺陷面
报告前验证发现的问题
按严重性对真实问题排序
未发现重大问题时明确说明审查结果为无异常

Step 0: Resolve review scope

步骤0：确定审查范围

This skill reviews branch changes, not the full repository by default.

Determine:

default branch
whether the review target is the full branch, a commit range, or current diff guidance from the user
whether the user asked for a focus area such as auth, data integrity, concurrency, or secrets

If there are no changes relative to the review base, stop and say so explicitly.

Success criteria: The review scope is explicit and there is actual diff content to inspect.

此技能默认仅审查分支变更，而非整个仓库。

需确定：

默认分支
审查目标是完整分支、提交范围，还是用户提供的当前差异指导
用户是否指定了重点领域，如认证、数据完整性、并发或密钥管理

如果相对于审查基准没有变更，请明确说明并停止审查。

成功标准：审查范围明确，且存在可检查的差异内容。

Step 1: Read the real diff and changed files

步骤1：读取真实差异和变更文件

Inspect the review surface with:

branch diff against the default base
changed file list
changed-file context as needed with
```
Read
```

Rules:

read the actual changed lines, not just
```
--stat
```
if diff output is too large, read file-by-file against base
use
```
Skill
```
only when a nested helper such as
```
codemap
```
materially improves code discovery

Success criteria: Every changed file that matters to the review has been read with enough context to reason about it.

通过以下方式检查审查范围：

与默认基准对比的分支差异
变更文件列表
根据需要使用
```
Read
```
获取变更文件的上下文

规则：

读取实际变更的代码行，而非仅查看
```
--stat
```
输出
如果差异输出过大，逐文件对比基准进行读取
仅当嵌套辅助工具（如
```
codemap
```
）能显著提升代码发现效率时，才使用
```
Skill
```

成功标准：所有与审查相关的变更文件都已读取，且获取了足够的上下文以进行合理分析。

Step 2: Map attack surfaces and defect surfaces

步骤2：梳理攻击面和缺陷面

For each changed file, identify the relevant surfaces:

user inputs
database queries
auth and authorization
session or token handling
external calls
crypto or secret handling
serialization and parsing
filesystem paths and uploads
concurrency or state transitions
edge-case and boundary behavior

Files with low security surface can still contain logic bugs, so do not skip them entirely.

Load

references/review-checklists.md

for the full review matrix.

Success criteria: The changed files are grouped by the risks they actually expose.

针对每个变更文件，识别相关的风险面：

用户输入
数据库查询
认证与授权
会话或令牌处理
外部调用
加密或密钥管理
序列化与解析
文件系统路径与上传
并发或状态转换
边缘情况与边界行为

安全风险面低的文件仍可能存在逻辑bug，因此不要完全跳过这些文件。

加载

references/review-checklists.md

以获取完整的审查矩阵。

成功标准：变更文件根据其实际暴露的风险进行分组。

Step 3: Run the targeted review checklist

步骤3：执行针对性审查检查清单

Use

references/review-checklists.md

to evaluate:

injection
XSS and unsafe rendering
authentication and authorization
session and CSRF handling
race conditions
crypto and secret handling
information disclosure
denial of service and resource exhaustion
business-logic correctness
general logic bugs such as null access, async mistakes, boundary errors, and missing returns

Rules:

do not assume a framework protects a pattern without checking whether the protection actually applies here
do not skip checklist sections just because a file "looks simple"
focus on changed code, but read enough surrounding code to verify the claim

Success criteria: Every meaningful checklist area has been evaluated against the actual changed surface.

使用

references/review-checklists.md

评估以下内容：

注入攻击
XSS与不安全渲染
认证与授权
会话与CSRF处理
竞争条件
加密与密钥管理
信息泄露
拒绝服务与资源耗尽
业务逻辑正确性
通用逻辑bug，如空值访问、异步错误、边界错误和缺失返回值

规则：

不要假设框架会保护某种模式，需检查该保护是否实际适用于当前场景
不要仅因文件“看起来简单”就跳过检查清单的部分内容
重点关注变更代码，但需读取足够的周边代码以验证结论

成功标准：所有有意义的检查清单领域都已针对实际变更范围进行了评估。

Step 4: Verify each candidate finding

步骤4：验证每个候选问题

Before reporting any issue, check:

surrounding function and caller context
whether middleware, helpers, or wrappers already mitigate it
whether existing tests already cover the scenario
whether exploitability or incorrect behavior is real in practice

If you cannot verify the finding confidently, drop it or clearly mark the verification gap.

Do not inflate weak suspicions into findings.

Success criteria: Every reported issue survives a false-positive check.

报告任何问题前，需检查：

周边函数和调用者上下文
中间件、辅助工具或包装器是否已缓解该问题
现有测试是否已覆盖该场景
该问题在实际环境中是否具有可利用性或会导致错误行为

如果无法自信地验证该问题，请放弃报告或明确标记验证缺口。

不要将微弱的怀疑夸大成问题。

成功标准：所有报告的问题都通过了误报检查。

Step 5: Classify and prioritize

步骤5：分类与优先级排序

Assign severity based on actual impact:

```
Critical
```
```
High
```
```
Medium
```
```
Low
```

Prioritize:

exploitable security issues first
then correctness and data-integrity bugs
then lower-risk quality problems that still represent real defects

Load

references/review-checklists.md

for severity guidance.

Success criteria: Findings are ordered by real risk rather than by how easy they were to spot.

根据实际影响分配严重性：

```
Critical
```
（严重）
```
High
```
（高）
```
Medium
```
（中）
```
Low
```
（低）

优先级排序规则：

首先处理可利用的安全问题
其次是正确性和数据完整性bug
最后是风险较低但仍属于真实缺陷的质量问题

加载

references/review-checklists.md

获取严重性指导。

成功标准：问题根据实际风险排序，而非根据发现的难易程度。

Step 6: Report with evidence

步骤6：带证据的报告

For each finding, report:

```
File:Line
```
severity
category
concise problem statement
evidence for why the issue is real
exploit path or failure path when relevant
concrete fix direction

Also report:

files reviewed
checklist coverage summary
any areas not fully verified

If no significant findings exist, say so explicitly.

Success criteria: Another engineer can act on the report without re-deriving the issue from scratch.

针对每个发现的问题，报告以下内容：

```
文件:行号
```
严重性
类别
简洁的问题描述
证明该问题真实存在的证据
相关的利用路径或故障路径（如有）
具体的修复方向

同时报告：

已审查的文件
检查清单覆盖情况总结
任何未完全验证的领域

如果未发现重大问题，请明确说明。

成功标准：其他工程师无需从头推导问题即可根据报告采取行动。

Guardrails

防护规则

Do not edit code as part of this skill.
Do not report style-only issues.
Do not invent findings to appear thorough.
Do not add
```
disable-model-invocation
```
; this skill should remain available for proactive review when the user asks for it.
Do not add
```
paths:
```
; this is a generic workflow skill.
Keep the heavy checklist content in references, not inline in
```
SKILL.md
```
.

不得在此技能中编辑代码。
不得仅报告风格相关问题。
不得为了显得全面而编造问题。
不得添加
```
disable-model-invocation
```
；当用户请求时，此技能应保持可用于主动审查。
不得添加
```
paths:
```
；这是一个通用工作流技能。
将详细的检查清单内容保留在参考文件中，而非内联在
```
SKILL.md
```
中。

When To Load References

何时加载参考文件

```
references/review-checklists.md
```
Use for the detailed security, logic, severity, and reporting checklists.

```
references/review-checklists.md
```
用于获取详细的安全、逻辑、严重性和报告检查清单。

Output Contract

输出约定

Report:

files reviewed
findings by severity
concise detailed findings with evidence
checklist coverage and any verification gaps
explicit clean result if no significant bugs were found

报告需包含：

已审查的文件
按严重性排序的问题
简洁且详细的带证据问题描述
检查清单覆盖情况及任何验证缺口
若未发现重大bug，需明确说明审查结果为无异常