بنقرة واحدة
yy-review
审核 git 变动文件或用户指定范围内的代码质量。 用于:用户要求审核代码、代码 review、检查代码质量时触发。 不用于:用户要求直接修改代码、询问代码问题、生成提交信息或运行构建测试。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
审核 git 变动文件或用户指定范围内的代码质量。 用于:用户要求审核代码、代码 review、检查代码质量时触发。 不用于:用户要求直接修改代码、询问代码问题、生成提交信息或运行构建测试。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
创建符合国人审美的网页界面设计。当用户需要设计网页、组件、页面或应用界面时使用。 专注于简洁、精致、和谐的设计风格,生成可直接使用的前端代码。 不用于审核已有 UI 代码、优化现有组件实现,也不用于生成纯后端代码或非 Web 端 UI。
用于撰写技术文章、技术教程、经验总结类长文。 当用户明确要写技术文章、技术博客、技术教程、踩坑记录、优化案例时触发。
创建或更新 AI 全栈 Web 项目的 PRD 产品需求文档。 用于用户明确要求生成 PRD、补充 PRD 内容、或更新现有 PRD 时触发。 不用于生成普通技术文档、API 文档或仅修改代码的场景。
管理项目的分层记忆系统,包括 work-log 更新、新记忆生成、容量检查和归档。 由用户手动执行本技能后触发记忆更新,不用于普通查询或非提交场景。
在目标项目中一键启用分层记忆管理系统,生成规则、技能和记忆库结构。 仅在用户明确要求为项目添加记忆功能时使用,不用于查询记忆、更新现有记忆或初始化普通配置文件。
创建基于当前技能 `scripts/` 参考工程的 Node.js + TypeScript 脚本项目骨架,或按同一结构补齐空白/轻量脚本项目。 当用户需要快速落地命令行脚本、批处理脚本或文件处理流水线时触发,不用于后端服务、前端项目、单文件脚本片段或成熟项目重构。
| name | yy-review |
| description | 审核 git 变动文件或用户指定范围内的代码质量。 用于:用户要求审核代码、代码 review、检查代码质量时触发。 不用于:用户要求直接修改代码、询问代码问题、生成提交信息或运行构建测试。 |
通用代码审核技能。对 git 变动文件或用户指定范围内的代码进行审核,优先审查变更行及必要上下文,按严重程度输出问题描述、影响和修复建议。
按目标文件所属子项目的角色与主要语言/框架自动路由:通用层规则 + 匹配到的语言/框架专项层规则叠加适用,冲突时专项层优先;未匹配到专项规则时,仅使用通用层规则。
核心原则:默认只审核,不修改代码;只有用户明确要求修复时,才进入代码修改流程。
不应触发:
为后续分组路由建立"子项目路径 → { 角色, 主要语言/框架 }"的映射。本步骤只识别、不委托。
输出一个映射表,每一项形如:
前端 / 后端 / 客户端 / 脚本 / 混合 之一;当一个子项目同时承担多种角色(如 SSR、前后端一体)时记为 混合Vue3、Vue2、React、Node.js、Rust、Python、Go、Java/Kotlin 等;可同时记录多个monorepo 中的多个子项目分别建立映射;单一项目只建立一条根目录映射。
按以下顺序判定,前一来源已能给出明确结论时不再向下查找:
README.md / AGENTS.md:从中提取项目角色与所用语言/框架。子项目级文档的描述优先于根目录文档当文档描述与实际代码明显矛盾(例如文档说"Vue 项目"但已迁到 React,或新增了 server/ 目录但 README 未更新)时,以实际代码为准;同时在步骤 7 的最终审核结果中标注"项目类型与文档描述不一致",便于用户感知文档过时风险。
按以下规则获取需要审核的文件。
决策分支:
默认使用以下命令获取 git 变更:
git diff --name-only HEAD
git diff --cached --name-only
支持的文件范围:
作为通用代码审核技能,默认收录所有可读的纯文本源文件,包括但不限于:
.js、.ts、.vue、.py、.go、.rs、.java、.kt、.cs、.php、.rb、.swift、.c、.cpp、.dart、.scala、.lua、.sql 等).css、.scss、.less、.html、.tsx、.jsx).json、.yaml、.toml、.sh、.ps1、Dockerfile、Makefile、.tf)以上仅为示例。未列出但属于源代码、配置或脚本类的纯文本文件同样在收录范围内;具体语言/框架的审核规则由步骤 1、3 的路由结果决定,未匹配到专项规则时仅使用通用层规则。
默认排除以下文件和目录:
node_modules/、dist/、build/、coverage/、.next/、.nuxt/、.output/、target/、Cargo.lockpackage-lock.json、pnpm-lock.yaml、yarn.lock、*.min.js、*.generated.*.gitignore 匹配的文件和目录(含嵌套 .gitignore)覆盖规则:用户显式指定的文件路径优先级高于上述默认排除——即使该文件被 .gitignore 匹配或属于上述排除类型,只要用户显式指定,仍纳入审核。
将步骤 2 收集到的目标文件按所属子项目的角色与语言分组,并对每个分组独立决定是否委托给专项审核技能。委托发生在文件分组层面,而非整个审核任务层面,避免全栈项目中识别到前端角色后忽略其他角色或语言的文件。
对每个目标文件按以下顺序判定所属分组:
角色 + 主要语言/框架 归到对应分组(如 Vue3 前端组、Node.js 后端组、Rust 后端组)混合(例如同一 package.json 既是前端又是 Node 服务端、或 Vue SSR 项目)时,按文件后缀进一步细分:
.vue / .jsx / .tsx / .css / .scss / .less / 主要在前端目录下的 .js / .ts → 该子项目的前端语言分组.js / .ts / 含 Node 内置模块导入或服务端框架导入 → 该子项目的 Node.js 分组.json、.yaml、.toml、.sh 等):归入其所在子项目映射对应的分组;无法归类时进入通用组分组结果可能为:单一分组(典型纯语言项目),或多个分组(典型全栈/monorepo 项目)。
对每个文件分组按以下决策分支处理:
yy-frontend-review:将该分组的文件委托给 yy-frontend-reviewresources/<language>.md"流程审核委托执行时,仅传入对应分组的文件清单,被委托技能不得越界审核其他分组的文件。各分组的审核结果在步骤 7 输出时合并。
无论文件归属哪个分组、是否委托给专项技能,都先对全部目标文件统一执行一次快速通道检查:
[FastTrack]文件路径:行号 + 问题类型 去重排序后输出优先审查 diff 变更行,并按需读取上下文。
决策分支:
上下文读取规则:
对未在步骤 3 委托给专项技能的分组,按以下规则在本技能内审核。已委托给专项技能的分组遵循专项技能的审核维度,不在此处重复。
审核规则采用"通用 + 专项"分层结构,按目标文件的语言或项目类型动态路由:
resources/<language>.md(如 resources/vue3.md、resources/rust.md);规则文件名采用语言或框架的小写名resources/ 中找到对应专项规则文件时,仅使用通用层规则规则冲突处理:
.vue 文件优先用 vue3.md)当委托子代理执行专项技能审查时,优先按文件分组调度,而非按维度分组调度:
文件路径:行号 + 问题类型 两个维度去重。快速通道发现的缺陷与子代理结果重复时,以快速通道结果为准此调度策略优先级高于被委托技能自身的调度方案。当两者冲突时,以本规则为准。
报告口径:
审核执行规则:
catch 块中用于记录异常的 console.warn 不视为问题。| 场景 | 处理方式 |
|---|---|
| 删除文件 | 只评估删除是否影响引用、路由、导出、配置或测试,不审查已删除内容 |
| 重命名文件 | 按新路径和实际 diff 审查,必要时检查引用路径是否同步更新 |
| 大型文件 | 优先审查 diff hunk;超过 1000 行时按相关函数或模块分段读取 |
| 仅文档改动 | 只检查明显错误、无效链接、命令错误和与代码不一致的说明 |
| 仅格式化改动 | 不报告业务问题,除非格式化引入语法或运行时风险 |
| 配置文件改动 | 重点检查语法、环境差异、安全暴露和构建行为变化 |
| 新增模块或入口 | 检查路由、导航、权限、导出、类型、配置、文档和依赖接入是否同步完成 |
| 无法确认的问题 | 标记为“需人工确认”,说明原因和建议确认方式 |
决策分支:
输出要求:
文件路径:行号 格式,使用相对于项目根目录的路径typescript、javascript、rust)README.md / AGENTS.md)与实际代码冲突,需在审核结果开头追加一条提示,说明哪个子项目的角色或语言与文档描述不一致,便于用户感知文档过时风险通过格式:
## 审核结果:通过
### 问题统计
- 审核文件数:N
- 严重:0 个
- 中等:0 个
- 轻微:Z 个
### 轻微问题
[如无轻微问题,写“未发现轻微问题。”]
不通过格式:
## 审核结果:不通过
### 问题统计
- 审核文件数:N
- 严重:X 个
- 中等:Y 个
- 轻微:Z 个
### 问题详情
#### 严重问题
1. **问题类型**:[类型]
- **位置**:文件路径:行号
- **描述**:[问题说明]
- **影响**:[可能造成的后果]
- **代码片段**:
```语言
[相关代码]
```
- **修复建议**:[具体可执行建议]
#### 中等问题
[同上]
#### 轻微问题
[同上,可简化代码片段]
### 修复优先级
1. 先修复严重问题。
2. 再修复中等问题。
3. 轻微问题可按团队规范决定是否处理。
允许执行的操作:
禁止主动执行的操作: