findscripter 何时使用
- 有明确代码改动（diff、PR、补丁、粘贴的代码片段）需要审查时使用。
- 目标是找：正确性 bug（逻辑、边界、并发、错误处理、空值）、复用/简化机会、可读性问题，并给出可落地的修改建议。
- 触发词：代码审查、review、找 bug、重构建议、code review。
不该用的边界：
- 纯依赖/许可证/CVE 体检 → 用
dependency-auditor。 - 没有具体改动、只是问"怎么写"或要从零生成代码 → 不属于审查，直接写代码。
- 跑测试、构建、性能压测、部署验证 → 本技能只做静态审阅，不执行代码。
- 大段无关旧代码：只审查改动及其直接影响面，不重写整个文件。
步骤 / 指令
1. 取改动范围
- 优先 git diff（未提交：`git diff`；已提交：`git diff <base>...<head>` 或 `git show <sha>`）。
- 无 git 时，仅审查用户提供的片段，并读其上下文（被改函数、调用方、相关类型定义）。
2. 建立上下文（仅读必要文件）
- 读被改函数/方法的完整体，而非只看 diff 行。
- 读改动涉及的接口/类型、关键调用方，确认契约未被破坏。
3. 按维度逐项扫描（按优先级）
a. 正确性：逻辑错误、off-by-one、边界/空集合、null/undefined、类型不符、
错误的运算符/比较、异常未处理或吞掉、资源未释放、并发/竞态、
用户输入未校验、回退分支缺失、注释与实现不一致。
b. 复用/简化：重复逻辑可抽取、已有工具函数未用、可删的死代码、
过度抽象或可内联、复杂条件可化简。
c. 可读性：命名、魔法值、函数过长/嵌套过深、缺失关键注释（仅 why 类）。
4. 每条发现给出结构化条目：
- [严重度] 文件:行号 — 问题一句话
- 原因：为什么是问题（触发条件/后果）
- 建议：可直接采用的修改（给出替换代码或精确改法）
5. 严重度分级
- Blocker：会导致错误结果/崩溃/数据损坏/安全问题，必须改。
- Major：边界/隐患/明显坏味道，建议改。
- Minor：可读性/风格，可选。
6. 汇总输出
- 先列 Blocker 与 Major，再列 Minor。
- 无问题则明确说"未发现正确性问题"，不要编造。
- 不确定的发现标注"待确认"并说明假设，不冒充事实。
规则：
- 单一职责：只审查，不顺手提交、不擅自改文件（除非用户要求
--fix类操作）。 - 每条发现必须可定位（文件:行号）且可执行（带具体改法）。
- 优先 Blocker/Major；Minor 适度，避免噪声淹没要点。
- 不评论用户未改动的代码，除非改动直接破坏了它。
示例
最小审查提示词：
审查以下 diff，按 正确性 / 复用简化 / 可读性 三类输出。
每条：[严重度] 文件:行号 — 问题；原因；可执行建议（给替换代码）。
先 Blocker/Major 后 Minor；无正确性问题请明说，勿编造。
<贴入 git diff 内容>
取改动：
git diff # 未提交改动
git diff main...HEAD # 分支相对 main 的改动
git show <sha> # 某次提交
输出条目样例：
[Blocker] src/auth.py:42 — `if token == None` 用 == 比较 None
原因：自定义对象可能重载 __eq__，导致误判；空 token 会绕过校验。
建议：改为 `if token is None:`
[Major] src/list.js:88 — 循环内重复调用 fetchUser(id)，N+1 请求
原因：每次迭代发一次网络请求，列表大时显著变慢。
建议：循环前批量 `fetchUsers(ids)`，再用 Map 取值。
[Minor] src/list.js:12 — 变量 `d` 含义不明
建议：重命名为 `deadline`。
注意事项
- 不执行/不测试代码：只做静态推理；需要跑起来验证行为时，交给执行类技能或提示用户。
- 不臆造行号与文件名；定位以实际 diff/文件为准。
- 区分"确定 bug"与"风格偏好"，别把主观风格标成 Blocker。
- 安全相关（注入、鉴权、密钥硬编码、反序列化）一律按 Blocker 处理并显式指出。
- 改动很大时分批审，先核心逻辑文件，避免一次性产出过长且失焦。
- 给建议要可直接采用：提供替换代码或精确改法，不要只说"建议优化"。
互见
- requires：无。
- related：
dependency-auditor（依赖/许可证/已知漏洞专项体检；本技能聚焦改动代码本身的正确性与质量，依赖层面的风险转交它）。 - combines_with：无。