review

review 技能概览

review 技能能做什么

review 是一个用于预上线 PR 评审的 skill，用来在代码合并前对比 base branch 的 diff。它面向的不只是“给个泛泛建议”的评审场景，而是更关注具体的结构性风险，比如 SQL 安全、信任边界违规、条件性副作用、shell 注入以及 enum 是否完整。

适合谁使用

当你准备合入代码、要回复“review this PR”，或者希望在不同 repo 之间保持一致的 review for PR Review 流程时，就该用这个 review skill。它尤其适合需要快速识别真实缺陷、同时避免只围绕样式问题喋喋不休的 agent。

它为什么不同

这个 skill 对评审顺序和严重程度有明确偏好：会先推动关键安全检查，再看低严重度问题，并且支持针对测试、安全、性能、可维护性等领域的专门 review 路径。相比笼统的“扫一遍 diff”，review guide 更能给出可执行的结论。

适用范围与限制

它最适合有清晰 git diff、且 base branch 具有实际意义的代码改动。对于高层设计评审、产品文案修改，或者用户只是想要一句夸奖或摘要的场景，它就没那么合适。如果你只需要一个轻量意见，而不是“先找可修复问题”的 review，那么通用 prompt 可能就够了。

如何使用 review skill

安装并触发它

使用 npx skills add garrytan/gstack --skill review 安装。这个 skill 的触发语义包括 “review this PR”、“code review”、“check my diff” 和 “pre-landing review” 之类的表达，所以输入时尽量写清楚变更内容和比较基准。

给 skill 一个真实的 review 目标

最好的 review usage 不是空泛提问，而是一个能感知 diff 的请求。好的输入通常会包含 repo、branch 和评审意图：

• “Review this PR against origin/main; focus on safety, merge risk, and anything that would block landing.”
• “Review the diff in packages/billing for SQL injection, race conditions, and API contract breaks.”

先看这些文件

要做实际的 review install 验证，先从 SKILL.md 开始，然后看 checklist.md、design-checklist.md 和 greptile-triage.md。如果你要改造这套流程，还应该检查 TODOS-format.md 和 specialists/ 目录，弄清楚哪些问题会被分流给子 agent，哪些由主清单处理。

按 skill 预期的流程来用

这个 repo 的设计核心是双阶段 review：先做关键安全检查，再看信息性问题。一个合格的 prompt 应该要求输出可执行结果，并附上文件/行号引用和修复建议，而不只是“找 bug”。如果你知道变更涉及哪个领域，也要写进去，这样 skill 才能优先走对应的 specialist 路径。

review skill 常见问题

review 比普通 prompt 更好吗？

在你需要可重复的 PR review 行为时，答案是肯定的。普通 prompt 可能会漏掉范围规则、升级顺序或 specialist 分流逻辑，而 review skill 会把这些直接固化进工作流，减少“先看什么”的猜测。

review skill 适合新手吗？

大体上是适合的，前提是用户能描述 branch 或 PR。新手会受益于引导式 checklist，但他们仍然需要提供真实 diff 和足够上下文，才能区分预期行为和回归问题。

什么时候不该用 review？

不要把它用在无代码问题、头脑风暴，或者没有具体变更集的抽象架构讨论上。如果你只想快速做个 sanity check，又不需要逐行发现问题，那它也不是最合适的选择。

我应该对 review for PR Review 期待什么？

你应该期待的是简洁、以修复为导向、并按严重程度排序的评论。这个 skill 的目标是找出阻止合入的问题，而不是复述整个 repo，或者写一段庆祝式总结。

如何改进 review skill

给出更锋利的输入

最强的 review skill 输入会明确 base branch、风险最高的子系统，以及你希望遵循的标准。不要只说“review my PR”，而要像这样说：“review feature/payment-retry against origin/main; prioritize data safety, idempotency, and any behavior change that could break clients.”

加上会改变判断的上下文

如果这次改动本身就带有风险，请直接说明。如果某种模式在项目 policy 里是允许的，也要提前讲清楚。这样可以减少误报，也能让 review 聚焦真实权衡，而不是反复争论已经定下来的决定。

直接说清楚你要的输出格式

如果你想要面向合入的输出，就要求给出 file:line、严重程度和具体修复方案。如果你只想看阻塞项，也要明确说出来。如果你希望覆盖到 specialist 路径，就直接提需求，避免 review 只停留在第一轮。

第一轮之后继续迭代

先用第一轮 review 修掉明显问题，再对更新后的 diff 重新运行 review。质量提升最大的地方，通常是把 scope 讲清楚、把对比 branch 收紧，以及把你最关心的风险区域准确喂给 skill。