Menu
跑一次全面的代码评审
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
oh-my-kimi 的目录入口，包含面向 Kimi CLI 的 agent、skill、hook 与 MCP 套件，衍生自 oh-my-* 谱系。
面向密钥、注入、authz/authn、不安全 IO、依赖与数据外泄风险的安全评审
证据驱动的追踪通道，在 Kimi 的 Agent 工具中编排互相竞争的 tracer 假设
LLM Wiki —— 跨会话持续累积的 markdown 知识库（Karpathy 模型）
面向作家的 agentic 记忆系统 —— 跟踪人物、关系、场景与主题
跑只读的深度仓库分析，返回一份带置信度排序的综合结论，附具体文件引用、清晰区分证据与推断。当用户说 'analyze'、'investigate'、'why does'、'what's causing'，或在提任何改动方案之前需要跨文件的有据解释时使用。
| name | code-review |
| description | 跑一次全面的代码评审 |
带严重程度评级地做一次质量、安全、可维护性的彻底代码评审。
下列情形触发该 skill：
并行委派给 code-reviewer 与 architect 两条 lane 做双线评审：
识别变更
git diff 找出变更文件启动并行评审 lane
code-reviewer lane —— 负责规格符合、安全、代码质量、性能、可维护性方面的发现architect lane —— 负责 devil's-advocate / 设计权衡视角评审类别
严重程度评级
架构状态契约
具体建议
最终综合
code-reviewer 的建议与 architect 状态合成一条最终结论code-reviewer 建议为 REQUEST CHANGES，最终建议为 REQUEST CHANGEScode-reviewer lanedelegate(
role="code-reviewer",
tier="THOROUGH",
prompt="CODE REVIEW TASK
Review code changes for quality, security, and maintainability.
This is the code/spec/security lane. Do not absorb architectural ownership.
Scope: [git diff or specific files]
Review Checklist:
- Security vulnerabilities (OWASP Top 10)
- Code quality (complexity, duplication)
- Performance issues (N+1, inefficient algorithms)
- Best practices (naming, documentation, error handling)
- Maintainability (coupling, testability)
Output: Code review report with:
- Files reviewed count
- Issues by severity (CRITICAL, HIGH, MEDIUM, LOW)
- Specific file:line locations
- Fix recommendations
- Approval recommendation (APPROVE / REQUEST CHANGES / COMMENT)"
)
delegate(
role="architect",
tier="THOROUGH",
prompt="ARCHITECTURE / DEVIL'S-ADVOCATE REVIEW TASK
Review the same code changes from the architecture/tradeoff perspective.
Scope: [git diff or specific files]
Focus:
- System boundaries and interfaces
- Hidden coupling or long-term maintainability risks
- Tradeoff tension the main reviewer might miss
- Strongest counterargument against approving as-is
Output:
- 架构状态：CLEAR / WATCH / BLOCK
- 每个顾虑的 file:line 证据
- 具体权衡或设计建议"
)
Run both lanes in parallel, then synthesize them with the deterministic rules above.
code-reviewer agent 应当咨询 Codex 做交叉验证。
优先用 native code-reviewer agent 咨询，或 CLI 支持的 ask_codex 接口。仅当已启用时才用可选的 MCP 兼容 ask 工具。咨询工具不可用时回退到 code-reviewer agent。
注意： Codex 调用最长可能耗时 1 小时，咨询前请考虑评审时限。
代码评审报告
============
已评审文件数：8
问题总数：12
架构状态：WATCH
CRITICAL（0）
------------
（无）
HIGH（0）
---------
（无）
MEDIUM（7）
----------
1. src/api/auth.ts:42
问题：邮件归一化逻辑重复，没有复用共享 helper
风险：不同认证路径的校验规则可能漂移
修复：让两条路径都走共享的归一化 helper
2. src/components/UserProfile.tsx:89
问题：派生权限在每次渲染时重新计算
风险：资料刷新时产生可避免的额外工作
修复：缓存派生权限列表，或在上游计算
3. src/utils/validation.ts:15
问题：表单层和服务端层的校验消息分别定义
风险：面向用户的校验提示可能不一致
修复：在两个调用点共用同一个校验消息 helper
LOW（5）
-------
...
架构观察项
----------
- src/review/orchestrator.ts:88
顾虑：评审结果汇总依赖隐式顺序，而不是显式 blocker 契约
状态：WATCH
建议：在扩展评审者之前，先定义确定性的合并门禁
综合结论
--------
- code-reviewer 建议：COMMENT
- architect 状态：WATCH
- 最终建议：COMMENT
建议：COMMENT
在把变更视为可合并之前，先处理所有 WATCH 顾虑。
code-reviewer lane 检查项：
architect lane 检查项：
CLEAR、WATCH 或 BLOCK 之中BLOCK 顾虑都说明了为什么不能给出可合并结论APPROVE —— code-reviewer 返回 APPROVE 且 architect 状态为 CLEAR
REQUEST CHANGES —— code-reviewer 返回 REQUEST CHANGES 或 architect 状态为 BLOCK
COMMENT —— code-reviewer 返回 COMMENT 且 architect 状态为 CLEAR，或 architect 状态为 WATCH，或仅剩 LOW/MEDIUM 的改进项
Good： 工作流已经有清晰的下一步，用户说 continue。沿着当前分支继续，而不是重启或重复同一个问题。
Good： 用户只改变输出形态或下游交付步骤（例如 make a PR）。保留此前不冲突的工作流约束，把更新在局部应用。
Bad： 用户说 continue，工作流却重启发现流程，或在缺失校验 / 证据被收集之前就停下。
与 Team：
/team "review recent auth changes and report findings"
跨多个专精 agent 协同执行评审。
与 Ralph：
/ralph code-review then fix all issues
在显式 Ralph 路径上，评审发现应直接流向自动修复跟进，无需再问权限。普通的 code-review 本身保持只读，不承诺自动修复。
与 Ultrawork：
/ultrawork review all files in src/
跨多文件并行代码评审。