菜单
代码评审技能，提供架构红线检查、AST 安全校验、SSE 通信规范、Zod schema 验证等评审维度。 当 `/review` 命令需要加载评审清单、执行 Fix-First 三级处理、或输出分级报告时触发。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
当 Godot 代码中存在通过 get_node()、get_parent() 或直接引用产生的紧耦合依赖时使用。 检测耦合模式并将其转换为基于 Signal 的通信方式。组件变得独立、可测试且可复用。 在改进架构的同时精确保留原有行为。
当 Godot 代码中存在相互冲突的操作导致未定义行为时使用。检测同一属性在多处设置 （_ready、_process、代码+编辑器）、同一 Signal 多次连接、冲突的物理模式、 竞争的动画等问题。自动通过明确的所有权归属解决冲突。
用于创建带有自定义面板、停靠栏和工具的 Godot 编辑器插件。生成 plugin.cfg 配置、 EditorPlugin 脚本模板、自定义编辑器 UI 组件，并集成 ProjectSettings。按照 Godot 4.x 最佳实践创建完整的插件结构。
当 Godot 代码中存在硬编码的游戏数据（如 const 数组、字典或内嵌值）时使用。检测内联数据 如敌人属性、物品定义、关卡配置等。自动提取为 .tres Resource 文件，使数据在编辑器中 可见、易于修改，并支持数据驱动的设计。
当构建 Godot 功能时，代码使用 .new() 创建节点而非使用场景时触发。 检测 Timer.new()、Area2D.new()、Sprite2D.new() 等代码创建的对象。 自动生成 .tscn 场景文件，更新父脚本使用 @onready 引用，并创建可复用的组件库。
当 Godot 项目在编辑器（.tscn）和代码（.gd）之间存在位置冲突、相机跟随背景、 或运行时位置与编辑器预览不匹配时使用。编排所有 3 个位置同步子技能： sync-static-positions、sync-camera-positions 和 sync-parallax。 每个操作针对特定的位置冲突类型。
基于 SOC 职业分类
| name | code-review |
| description | 代码评审技能，提供架构红线检查、AST 安全校验、SSE 通信规范、Zod schema 验证等评审维度。 当 `/review` 命令需要加载评审清单、执行 Fix-First 三级处理、或输出分级报告时触发。 |
| user-invokable | false |
| metadata | {"pattern":"composite[reviewer + pipeline]","version":"1.0.0","author":"vibe-game-creator","tags":["review","code-quality","architecture","checklist"]} |
本 skill 为
/review命令提供评审清单和 Fix-First 处理流程。不直接面向用户调用， 由/review命令在 Step 2 加载。
NO REVIEW WITHOUT EVIDENCE. 不说"probably tested"或"likely handled"——要么引用 具体代码行证明安全，要么标记为 unverified。
加载 references/checklist.md，获取四大维度的检查项。
如果文件不存在，STOP 并报告错误。 不得无清单评审。
对 diff 执行两轮检查：
Pass 1 — CRITICAL（阻塞级）：
| 维度 | 检查焦点 |
|---|---|
| L1~L4 边界 | 前端是否直接调用 LLM？Agent 是否绕过 Orchestrator？DB 操作是否绕过 db 层？ |
| AST 安全校验 | AI 生成代码是否经过 AST 校验？是否有 eval/Function 构造器？ |
| SSE 通信规范 | SSE 事件格式是否正确？错误处理是否完整？断线重连是否实现？ |
| 竞态条件 | 共享状态是否有竞态？异步操作是否有序？ |
| 数据安全 | 用户输入是否经过验证？Zod schema 是否覆盖边界？ |
Pass 2 — INFORMATIONAL（建议级）：
| 维度 | 检查焦点 |
|---|---|
| Zod Schema | 跨包类型是否使用 Zod 定义？parse 是否在边界处调用？ |
| Vue 组件规范 | 是否使用 Composition API？是否遵循 Pinia 状态管理？ |
| 魔法数字 / 硬编码 | 是否有未提取的常量或硬编码字符串？ |
| 死代码 | diff 中是否引入了未使用的导入、函数或变量？ |
| 测试缺口 | 新功能是否缺少对应测试？修复是否缺少回归测试？ |
| 文档陈旧 | 代码变更是否导致文档（docs/arch/、README.md 项目结构、AGENTS.md 架构表述等）过期？ |
Enum 完整性检查（需读取 diff 之外的代码）：当 diff 引入新的枚举值、状态常量或类型 时，使用搜索工具查找所有引用同类值的文件，确认新值是否被处理。
在进入 Fix-First 流程之前，必须满足以下条件：
- Pass 1 和 Pass 2 均已完成
- 每个发现都有证据（代码行引用或日志）
- 不存在"probably"/"likely"等未验证断言
未满足时：回去补充证据，不得跳过。
每个发现必须获得处理——不只是报告。
| 级别 | 条件 | 处理方式 |
|---|---|---|
| AUTO-FIX | 机械性修复、无歧义、不影响逻辑 | 直接修复，输出一行摘要 |
| ASK | 需要判断或有多种修复路径 | 批量提问让用户选择 |
| BLOCK | 严重架构违规、安全漏洞 | 阻塞，必须修复后才能继续 |
[AUTO-FIXED] [文件:行号] 问题 → 修复内容
已自动修复 N 项，M 项需要确认：
1. [CRITICAL] apps/server/src/xxx.ts:42 — 问题描述
修复建议：具体方案
→ A) 修复 B) 跳过
2. [INFORMATIONAL] apps/web/src/xxx.vue:88 — 问题描述
修复建议：具体方案
→ A) 修复 B) 跳过
建议：修复全部——原因说明。
🚫 [BLOCK] apps/web/src/xxx.ts:15 — 前端直接调用 LLM API
架构红线：前端不得直接调用 LLM，必须通过 L2 SSE 通道。
此问题必须修复后才能合入。
在输出最终评审报告前，逐项验证：
反合理化："This looks fine" 不是有效结论。要么引用证据证明确实 fine，要么标记为未验证。
## 📋 代码评审报告
**分支**：feature/xxx → master
**范围**：N 个文件变更，+X/-Y 行
### Scope Check
[CLEAN / DRIFT DETECTED / REQUIREMENTS MISSING]
意图：[CURRENT_PLAN.md 中的计划]
实际交付：[diff 实际内容]
### 评审摘要
Pre-Landing Review: N issues (X critical, Y informational)
### CRITICAL 发现
| # | 文件:行号 | 问题 | 处理 | 状态 |
|---|----------|------|------|------|
| 1 | ... | ... | AUTO-FIX / ASK / BLOCK | ✅ / ⏳ / 🚫 |
### INFORMATIONAL 发现
| # | 文件:行号 | 问题 | 处理 | 状态 |
|---|----------|------|------|------|
| 1 | ... | ... | AUTO-FIX / ASK | ✅ / ⏳ |
### 文档陈旧检查
[如有代码变更导致文档过期，列出并建议运行 `/done` 同步]
### 评审就绪状态
- Code Review: ✅ PASS / ❌ FAIL (N blocking issues)
- Design Review: ✅ PASS / ⏭️ SKIPPED (无前端变更) / ❌ FAIL
仅当 diff 触及 apps/web/ 目录时启动：
apps/web/ 下的文件变更web-design-guidelines skill 的 review 模式若无前端变更：跳过设计评审，不输出任何信息。
references/checklist.md — 四大维度详细检查项web-design-guidelines skill — 前端设计规范检查debug-runbook skill — 评审中发现的问题可参考排查