メニュー
对指定范围的代码进行结构化审计并输出重构建议书。当用户请求代码审计、质量检查、重构建议、或输入'审计'、'review'、'代码质量'等关键词时触发。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
当 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。 每个操作针对特定的位置冲突类型。
| name | refactor-audit |
| description | 对指定范围的代码进行结构化审计并输出重构建议书。当用户请求代码审计、质量检查、重构建议、或输入'审计'、'review'、'代码质量'等关键词时触发。 |
| user-invokable | true |
| metadata | {"pattern":"reviewer","version":"1.1.0","author":"vibe-game-creator","tags":["code-quality","audit","refactor"]} |
对指定范围的代码库进行系统化审计，输出结构化的「代码重构建议书」，并支持逐条应用修复。
用户可通过以下方式触发：
| 输入示例 | 行为 |
|---|---|
审计 apps/web/src/stores | 聚焦扫描指定目录 |
全局审计 | 扫描 apps/ + packages/ 下所有包 |
审计 --dimension coupling | 按维度筛选（见下方维度表） |
修复 [ID] | 对建议书中的某一项生成修复代码 |
如果用户未指定范围，主动询问：
请告诉我要审计的范围：
- 全局 — 扫描
apps/+packages/下所有包- 指定目录 — 例如
apps/web/src/stores、apps/server/src/services、packages/shared-types/src- 指定维度 — 例如「只看耦合问题」「只看类型安全」
在开始审计前，必须读取以下规则文件作为审计基准：
.agents/rules/monorepo_guide.md — 跨包边界、依赖方向、共享类型.agents/rules/quality-typescript-coding.md — TypeScript 编码准则.agents/rules/quality-simplicity.md — 简洁性原则AGENTS.md 中的 Architecture Constraints — 四层架构红线⚠️ 首次审计前，先加载 references/gotchas.md 了解常见误判场景（如测试代码、Vue SFC、type-only import 等），避免产出无效建议。
逐文件扫描目标范围，按以下 6 个审计维度 检查问题。加载 modules/dimensions.md 获取各维度的详细检查规则。
| 维度 | 代号 | 检查要点 |
|---|---|---|
| 跨包耦合 | coupling | 违反依赖方向、私有路径引用、前端直接 import 后端 |
| 类型安全 | type-safety | any 逃逸、缺少 Zod 校验、共享类型未同步 |
| 状态管理 | state | 绕过 Pinia actions 直接修改 state、缺少 Service 层 |
| 代码重复 | duplication | ≥2 处重复逻辑未提取、工具函数内联在业务模块 |
| 复杂度 | complexity | 函数过长、嵌套过深、职责不单一 |
| 架构红线 | redline | 违反四层架构约束（前端调 LLM、绕过 Orchestrator 等） |
审计完成后需要完成两件事，加载 modules/output-format.md 获取完整模板和写入规范：
按 modules/output-format.md 中的「对话输出模板」格式，在对话中展示完整的审计摘要、问题分布和详细任务单。
将审计发现的每条问题转化为 CURRENT_PLAN.md 中的待办事项，作为新的里程碑追加到文件中：
replace_in_file 在 CURRENT_PLAN.md 的 ## ⚠️ 遗留待办 之前插入新的里程碑章节- [ ] checkbox 格式，方便后续逐条打勾modules/output-format.md 中的「CURRENT_PLAN.md 写入模板」当用户输入 修复 R-XXX 时，本步骤属于 /execute 开发执行阶段，必须读取并遵循 .agents/commands/execute.md 中的完整流程（含单元测试维护、E2E 检查、验收文档同步）。
在 /execute 框架下，本 skill 负责以下代码修改步骤：
兼容别名：
apply fix for task R-XXX、fix R-XXX等英文指令同样生效。
| 等级 | 含义 | 处理要求 |
|---|---|---|
| P0 | 违反架构红线或导致运行时故障 | 必须立即修复 |
| P1 | 违反编码准则或影响可维护性 | 当前迭代内修复 |
| P2 | 代码异味或优化建议 | 择机处理 |