grill-diff
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseGrill Diff
Grill Diff（代码差异深度审查）
Diff Scope
差异范围（Diff Scope）
File scope and diff baseline are independent and combine freely (e.g. "against develop src/auth.ts").
- Files: user-specified if listed, otherwise all changed files.
- Baseline: staged > unstaged > user-specified branch > PR URL > current branch vs default branch.
文件范围和差异基准相互独立，可自由组合（例如"对比develop分支的src/auth.ts"）。
- 文件（Files）：若用户指定则按指定列表，否则包含所有已修改文件。
- 基准（Baseline）：优先级依次为：暂存文件（staged）> 未暂存文件（unstaged）> 用户指定分支 > PR URL > 当前分支与默认分支对比。
Review
审查流程（Review）
Ask if there is a related spec or plan file. Read all changed files to build the full picture, then go through files one at a time. Interrogate every aspect of each change.
If a question can be answered by exploring the codebase, specs, or tests, explore yourself instead of asking.
When you spot a finding, consult all 3 specialists. Each sees earlier opinions, then gives opinion + confidence (high / medium / low). Classify:
- Any specialist rated high → present to user
- Highest is medium, or specialists disagree → present to user as "uncertain"
- All rated low → drop silently
After all findings in a file are classified, merge duplicates and link related ones. Present surviving findings one at a time, discussing with the user until reaching shared understanding. Provide your recommended fix for each.
Files with no surviving findings advance silently.
询问是否有相关的规格说明或计划文件。阅读所有已修改文件以构建完整认知，然后逐一审查每个文件。对每项变更的各个方面进行深入核查。
如果问题可通过查阅代码库、规格说明或测试来解答，请自行探索而非询问用户。
当发现问题时，咨询全部3位专家。每位专家会参考之前的意见，然后给出自己的意见及置信度（高/中/低）。分类规则如下：
- 若有任何一位专家评级为高 → 提交给用户
- 最高评级为中，或专家意见不一致 → 标记为"不确定"提交给用户
- 所有专家评级均为低 → 静默忽略
在对一个文件的所有问题完成分类后，合并重复问题并关联相关问题。逐一呈现留存的问题，与用户讨论直至达成共识。针对每个问题提供推荐的修复方案。
无留存问题的文件将直接跳过。
Specialists
专家角色（Specialists）
All 3 are consulted for every finding.
correctness — Correctness & Edge Cases
- Does this code do what it intends to do?
- Are edge cases handled — null, empty, boundary values, error paths?
- Are there race conditions, off-by-one errors, or state inconsistencies?
security — Security
- Is user input validated and sanitized at system boundaries?
- Are secrets kept out of code, logs, and version control?
- Is authentication/authorization checked where needed?
- Are there injection risks — SQL, command, template, or otherwise?
- Are new dependencies introduced? Are they from trusted sources?
scope — Scope & Necessity
- Is this change needed? What breaks if we revert it?
- With spec/plan: Is every spec requirement addressed? Is every change traceable to a spec requirement? Does the implementation match the spec's described behavior?
- Without spec/plan: Is this change doing too much — should it be split?
每发现一个问题都会咨询全部3位专家。
正确性专家（correctness）——正确性与边界情况
- 这段代码是否实现了预期功能？
- 是否处理了边界情况——空值、空集合、边界值、错误路径？
- 是否存在竞态条件、差一错误或状态不一致问题？
安全专家（security）——安全
- 是否在系统边界处对用户输入进行了验证和清理？
- 是否确保密钥未出现在代码、日志和版本控制中？
- 是否在必要位置检查了身份验证/授权？
- 是否存在注入风险——SQL注入、命令注入、模板注入或其他类型？
- 是否引入了新的依赖项？这些依赖项是否来自可信源？
范围专家（scope）——范围与必要性
- 这项变更是否必要？如果回退会有什么影响？
- 有规格/计划时：是否满足了所有规格要求？每项变更是否都可追溯到规格要求？实现是否符合规格描述的行为？
- 无规格/计划时：这项变更是否过度——是否应拆分？