name	code-review
description	对项目代码执行全量质量检查，覆盖格式、命名、引用、注释、逻辑、风格、边界、文档八大维度，生成结构化 Markdown 报告。当用户要求代码审查、代码质量检查、查找代码问题时使用。
disable-model-invocation	true

Code Review

对项目代码执行全量质量检查，覆盖格式、命名、引用、注释、逻辑、风格、边界、文档八大维度，生成结构化 Markdown 报告。只生成报告，不自动修复。

开始前

向用户确认检查范围（如 src/、lib/、app/）和主要语言
扫描项目结构，识别：
- 源代码目录
- 文档文件（README、ARCHITECTURE 等）
- 配置文件（package.json、pyproject.toml、tsconfig.json 等）
- 已有 lint 工具配置（eslint、ruff、prettier 等）
根据语言和已有工具决定检查策略

检查维度

1. 命名

语义准确性：变量名是否反映用途
风格统一：遵循语言/项目命名规范（如 Python snake_case、JS camelCase）
全局/局部变量：全局变量是否有清晰前缀或模块隔离
缩写滥用：无意义缩写（tmp、x、d）

2. 格式

缩进一致性
行宽（建议 120 字符）
空白行使用
import/require 顺序与分组
字符串引号风格统一

3. 未使用引用

未使用的 import/require
未使用的函数 / 类
未使用的变量 / 常量
死代码（不可达分支）

4. 注释

风格统一
通俗易懂（避免重复代码字面意思）
隐患标记（TODO、FIXME、HACK、# type: ignore、@ts-ignore）
完成度标记
过时注释（注释与实际代码行为不符）

5. 逻辑

边界条件处理
异常处理质量（不吞异常、不裸 except）
分支完备性
类型安全
资源泄漏风险

6. 风格

函数长度
模块职责单一
嵌套深度
重复代码（DRY 原则）
错误信息清晰度

7. 职责边界

函数单一职责：一个函数只做一件事
类/模块边界：职责是否清晰、是否存在越界调用
层级隔离：上层是否直接访问下层内部实现（如 UI 直接操作数据库）
依赖方向：是否存在反向依赖或循环依赖
接口暴露：公开接口是否最小化，内部实现是否被不当暴露

8. 文档

README 是否反映最新功能
架构文档是否与代码结构一致
模块级文档是否完整
新增配置项是否有示例

执行流程

第一步：自动检查

如果项目有 lint 工具配置，运行并收集结果
使用 grep 搜索隐患标记（TODO、FIXME、HACK、# type: ignore、@ts-ignore 等）
如果项目有自己的检查脚本，可调用

第二步：手动审查

逐模块阅读代码，检查上述七个维度
记录每个问题的文件路径、行号、上下文、严重程度

第三步：交叉验证

对比自动检查结果与手动发现
去重：同一问题被两种方式都发现的，合并为一条
补充：手动发现但脚本未覆盖的语义问题单独列出
确认：脚本报告的格式化问题，验证是否为误报

第四步：报告生成

按维度分类整理问题，每个维度内按严重程度排序
每个问题包含：位置、描述、严重程度、代码片段、建议
生成摘要统计（各维度问题数量、严重程度分布）
输出到 docs/code-review-report.md（如 docs/ 不存在则输出到根目录）

严重程度

🔴 Critical：可能导致 bug 或安全问题的逻辑问题
🟡 Suggestion：影响可读性 / 可维护性的风格或命名问题
🟢 Nice to have：建议性优化点（注释补充、文档更新）

输出报告格式

# Code Review Report

**日期**: YYYY-MM-DD
**范围**: <检查的目录>
**语言**: <主要语言>
**问题总数**: N（🔴 X，🟡 Y，🟢 Z）

## 摘要

| 维度 | Critical | Suggestion | Nice to have | 合计 |
|------|----------|------------|--------------|------|
| 命名 | ...      | ...        | ...          | ...  |

## 1. 命名

### 🔴 [简要描述]
- **文件**: `path/to/file.ext:行号`
- **代码**: ```language
  代码片段

问题: ...
建议: ...

2. 格式

...


## 反模式

- 禁止自动修复任何问题
- 禁止编造代码中不存在的问题
- 禁止在 skill 中使用项目特定路径或语言假设
- 禁止给出模糊建议——每条建议必须可执行

## 完成检查清单

标记审查完成前确认：
- [ ] 八个维度均已检查
- [ ] 自动工具已运行（如有）
- [ ] 手动审查已完成
- [ ] 交叉验证已完成
- [ ] 报告已写入 `docs/code-review-report.md`
- [ ] 报告包含摘要统计
- [ ] 每个问题都有位置、描述、严重程度、代码片段、建议

Más de este repositorio

mismo repositorio

commit-msg

Port127/novel-material

分析 git 变更并生成规范的 commit message，遵循 Conventional Commits 格式和中文结构化正文。自动过滤 AI 供应商文案。仅当用户明确说出"使用 commit-msg"时触发。

2026-06-303

my-create-skill

Port127/novel-material

引导创建符合团队约定的 SKILL.md 文件。仅当用户明确说出"使用 my-create-skill"或"启动 my-create-skill"时触发。不适用于任何隐式场景。

2026-06-213

plan-first

Port127/novel-material

复杂任务前先规划执行策略，明确步骤、依赖、风险。仅当用户明确说出"使用 plan-first"或"启动 plan-first"时触发。不适用于任何隐式场景。

2026-06-213

skill-discovery

Port127/novel-material

以 agent 对话为主扫描源，git 提交和反馈归档为验证补充，发现可复用的高频模式。不预设模式类型，让模式自然浮现，所有候选由用户判断价值。仅当用户明确说出"使用 skill-discovery"或"启动 skill-discovery"时触发。不适用于任何隐式场景。

2026-06-213

nm-search

Port127/novel-material

使用 nm-search 或启动 nm-search 时，用于检索小说素材参考；不适用于未显式点名该 Skill 的普通搜索请求。

2026-06-213

code-review-change

Port127/novel-material

分析指定改动的上下游影响，追踪调用链，发现潜在缺陷和隐患。仅当用户明确说出"使用 code-review-change"或"启动 code-review-change"时触发。不适用于任何隐式场景。

2026-06-163

name	code-review
description	对项目代码执行全量质量检查，覆盖格式、命名、引用、注释、逻辑、风格、边界、文档八大维度，生成结构化 Markdown 报告。当用户要求代码审查、代码质量检查、查找代码问题时使用。
disable-model-invocation	true

Code Review

开始前

向用户确认检查范围（如 src/、lib/、app/）和主要语言
扫描项目结构，识别：
- 源代码目录
- 文档文件（README、ARCHITECTURE 等）
- 配置文件（package.json、pyproject.toml、tsconfig.json 等）
- 已有 lint 工具配置（eslint、ruff、prettier 等）
根据语言和已有工具决定检查策略

检查维度

1. 命名

语义准确性：变量名是否反映用途
风格统一：遵循语言/项目命名规范（如 Python snake_case、JS camelCase）
全局/局部变量：全局变量是否有清晰前缀或模块隔离
缩写滥用：无意义缩写（tmp、x、d）

2. 格式

缩进一致性
行宽（建议 120 字符）
空白行使用
import/require 顺序与分组
字符串引号风格统一

3. 未使用引用

未使用的 import/require
未使用的函数 / 类
未使用的变量 / 常量
死代码（不可达分支）

4. 注释

风格统一
通俗易懂（避免重复代码字面意思）
隐患标记（TODO、FIXME、HACK、# type: ignore、@ts-ignore）
完成度标记
过时注释（注释与实际代码行为不符）

5. 逻辑

边界条件处理
异常处理质量（不吞异常、不裸 except）
分支完备性
类型安全
资源泄漏风险

6. 风格

函数长度
模块职责单一
嵌套深度
重复代码（DRY 原则）
错误信息清晰度

7. 职责边界

函数单一职责：一个函数只做一件事
类/模块边界：职责是否清晰、是否存在越界调用
层级隔离：上层是否直接访问下层内部实现（如 UI 直接操作数据库）
依赖方向：是否存在反向依赖或循环依赖
接口暴露：公开接口是否最小化，内部实现是否被不当暴露

8. 文档

README 是否反映最新功能
架构文档是否与代码结构一致
模块级文档是否完整
新增配置项是否有示例

执行流程

第一步：自动检查

如果项目有 lint 工具配置，运行并收集结果
使用 grep 搜索隐患标记（TODO、FIXME、HACK、# type: ignore、@ts-ignore 等）
如果项目有自己的检查脚本，可调用

第二步：手动审查

逐模块阅读代码，检查上述七个维度
记录每个问题的文件路径、行号、上下文、严重程度

第三步：交叉验证

对比自动检查结果与手动发现
去重：同一问题被两种方式都发现的，合并为一条
补充：手动发现但脚本未覆盖的语义问题单独列出
确认：脚本报告的格式化问题，验证是否为误报

第四步：报告生成

按维度分类整理问题，每个维度内按严重程度排序
每个问题包含：位置、描述、严重程度、代码片段、建议
生成摘要统计（各维度问题数量、严重程度分布）
输出到 docs/code-review-report.md（如 docs/ 不存在则输出到根目录）

严重程度

🔴 Critical：可能导致 bug 或安全问题的逻辑问题
🟡 Suggestion：影响可读性 / 可维护性的风格或命名问题
🟢 Nice to have：建议性优化点（注释补充、文档更新）

输出报告格式

# Code Review Report

**日期**: YYYY-MM-DD
**范围**: <检查的目录>
**语言**: <主要语言>
**问题总数**: N（🔴 X，🟡 Y，🟢 Z）

## 摘要

| 维度 | Critical | Suggestion | Nice to have | 合计 |
|------|----------|------------|--------------|------|
| 命名 | ...      | ...        | ...          | ...  |

## 1. 命名

### 🔴 [简要描述]
- **文件**: `path/to/file.ext:行号`
- **代码**: ```language
  代码片段

问题: ...
建议: ...

2. 格式

...


## 反模式

- 禁止自动修复任何问题
- 禁止编造代码中不存在的问题
- 禁止在 skill 中使用项目特定路径或语言假设
- 禁止给出模糊建议——每条建议必须可执行

## 完成检查清单

标记审查完成前确认：
- [ ] 八个维度均已检查
- [ ] 自动工具已运行（如有）
- [ ] 手动审查已完成
- [ ] 交叉验证已完成
- [ ] 报告已写入 `docs/code-review-report.md`
- [ ] 报告包含摘要统计
- [ ] 每个问题都有位置、描述、严重程度、代码片段、建议