用途
gjalla-code-review 是一个代码评审技能，用于在合并或提交之前评审代码变更（diff 或 PR），判断其是否达到可发布标准。适用场景是评审自己或他人的变更，例如在 commit、merge 之前。
主要能力
该技能要求以“标准极高的团队负责人”视角来评审代码。关注点包括：简单、设计优雅、易于维护的代码；满足预期与验证标准的代码；经过充分测试、健壮、安全、可用于生产的代码；以及在终端用户、公司与功能之间取得平衡的代码。
评审方法强调先看“目标与现实”，在阅读 diff 找缺陷之前先回答三个问题：目标是什么（来自 PR 描述、关联规范或提交信息，用一句话概括）？实际构建的机制是什么？这两者是否填补同一个缺口，且实现是否合理、安全？资料指出，一个变更可能干净、有测试、结构良好，却仍然不是被要求的东西。
评审还会根据变更内容，代入多种相关角色的视角，例如：擅长代码正确性/死代码/DRY 的资深软件工程师；寻找意大利面式代码、追求最小但有效且符合架构最佳实践的架构师；擅长用户体验、用户声音与审计工作流中混淆、重复和不完整的产品经理；关注质量、缺陷、边界情况与可维护性的 QA 工程师；负责实施与价值交付的客户成功经理；关注数据访问/隐私/安全/漏洞的安全分析师。资料要求每次评审必须包含架构师和安全分析师视角，但不要求使用所有列出的角色，也不限于这些角色，应根据变更上下文选择最有帮助、最具对抗性、最能填补缺口的视角。
每个视角都要完整评审 diff，使用二阶思考（这些变更会带来什么附带、隐含或二阶影响？）并以全新眼光审视。始终适用的质量视角是：是否最小、优雅、有效、不过度工程化、可维护。
使用方式
评审后按严重程度分组输出发现：
- Blocking：合并前必须修复（正确性、安全、数据丢失）。
- Should fix：当前值得处理的质量/可维护性问题。
- Nit：可选的润色。
每条发现需包含：file:line、问题所在、具体的修复建议。并说明已验证了什么、未能验证什么。
评审至干净：有发现的评审不是流程终点而是中间环节。非干净的评审要求在修复落地后，以全新视角进行另一轮完整评审，直到某一轮返回干净结果（没有阻断或必须修复的变更；最多 5 轮）。资料强调“全新视角”是字面意思：如果 agent 支持子代理，每轮应生成一个全新上下文的评审者，而不是重读自己的工作——自我修复后再自我评审等于自己给自己批作业。无法做到时应披露：在标记中添加 --evidence review_mode=self。需在工作笔记中保留每轮的简短记录：发现了什么、改了什么、该轮是否干净。如果达到轮次上限仍未有干净的一轮，不要无限循环也不要悄悄继续：如实记录最后一轮，并把未解决的发现上报给人类。
适用场景与原则
适用于在提交或合并前评审代码变更。评审原则包括：既评审已存在的代码，也评审缺失的内容——危险的缺陷通常是未处理的 case，而不是写错的那一行；要具体，没有位置和修复建议的发现就是噪音；只批准自己理解的内容，无法判断是否正确时应说明，而不是盖章通过；报告结论前先验证，怀疑发现缺陷时应复核来源、数据流等再下结论；可能评审的是朝向目标的局部实现，这没问题，有时用户和 agent 是增量工作的，应在报告中注明，它可能是有意为之因而并非致命；在推理之前先确认所读内容是当前的，过期的 checkout、遗留的 worktree 或缓存的产物会产生自信但错误的评审。
限制
资料未提供该技能支持的平台、安装命令、收费或价格信息，暂未提供。资料也未提供具体可调用的参数、配置方式或与其他工具的集成细节，暂未提供。