local-pr-review

name	local-pr-review
description	当用户请求对本地未提交的代码（或本地分支特定 commit 等）进行代码审查时触发该 skill，对本地变更进行审查。

When to Use This Skill

当用户请求本地审查时触发。本技能支持对以下三种变更范围进行环境友好的深度审查：

1. 未提交的变更 (Uncommitted): 审查工作区中所有尚未提交的修改（包括已暂存和未暂存）。
2. 特定的历史 Commit (Recent Commits): 选定检查最近几次 commit（如 HEAD~N）的改动情况。
3. 主干差异对比 (Main Branch Diff): 与 main 等主干分支对比，整体审查当前特性的增量细节。

Local Review 本地代码审查技能

在本地开发环境中，利用全量代码库的上下文优势，全面审查代码变更的质量、安全性、性能和架构设计，并自动评估跨文件影响，提供专业的改进建议。

审查范围与启动方式 (Scope Definitions)

你需要根据用户的指令意图，判断并选择对应的比对策略来拉取代码。务必使用 -U15 等参数增加局部上下文视野。

模式 1：未提交审查 (Uncommitted Changes)

# 获取工作区未暂存及已暂存的混合全量 diff
git diff HEAD -U15

模式 2：特定历史 Commit 审查 (Recent Commits)

# 审查最后一次 commit
git diff HEAD~1 HEAD -U15

# 审查最近 3 次的整体 commit 变更 (数字可根据用户指令替换)
git diff HEAD~3 HEAD -U15

模式 3：主干差异审查 (Main Branch Diff)

# 审查当前特性分支相较于 main 主干的所有的增量代码
git diff main...HEAD -U15

工具集成

使用 git CLI 与本地工具加速审查

在本地环境审查时，相较于 PR 审查的局限点，我们要极大发挥能“到处跑、到处看”的优势。

# 获取已修改的文件列表及状态
git status -s

# 将宽泛上下文的 diff 存入临时文件便于分析
git diff -U15 > /tmp/local_changes.diff

# 跨文件依赖与上下文搜索（寻找受修改影响的引用方）
git grep "修改的函数名或类型"

本地测试与验证代码

本地审查时可以直接执行验证流程，以结果作为审查依据：

# 运行单元测试
pnpm test

# 运行代码规范检查
pnpm lint

# 运行类型检查以捕获变更导致的隐藏/全局类型错误
pnpm tsc --noEmit

# 启动开发服务器通过 UI 进行直观验证
pnpm dev

常见命令参考

# 获取具体的 diff 内容
git diff --name-only
git diff <file_path>

# 追溯某段代码的演进历史
git blame <file_path>

# 获取最近的 commit 记录
git log -n 5 --oneline

审查流程

1. 信息与上下文收集阶段 (⭐本地环境核心增强)

切勿仅凭零碎的补丁代码（Diff chunks）盲目审查，务必建立完整的上下文认知：

自动执行/指导执行以下步骤:

# 1. 确认当前的修改状态及涉及的文件
git status

# 2. 获取具有充足上下文的变更细节（-U15 或更大）
git diff -U15

# 3. 阅读全量文件（上下文增强）：
# 对于重点修改的文件，不要只看 diff，而是查看整个源文件，理解数据流向和全貌。
cat <file_path>

# 4. 分析跨文件影响（上下文追踪）：
# 如果改动涉及到变量名变更、导出方法的增删改、Props 类型更改，
# 必须使用本地搜索查出其在项目中的所有调用点：
git grep "<Edited_Target>"

2. 多维度代码审查

基于完整的调用链和文件上下文，按照以下维度进行系统性审查:

维度 1: 基本代码质量标准 📐

通用的代码质量标准,适用于所有项目:

• 安全性: 输入验证、权限检查、注入防护、敏感信息保护
• 正确性: 错误处理、边界条件、类型安全（结合上下文，看传参方是否提供了正确数据）
• 性能: 算法复杂度、数据库优化、内存管理（结合上下文，审查循环逻辑或多次重渲染问题）
• 可测试性: 测试覆盖、测试质量、Mock 使用

📖 详细指南: code-quality-standards.md

维度 2: FastGPT 风格规范 🎨

FastGPT 项目特定的代码规范和约定:

• API 路由开发: 路由定义、权限验证、错误处理: API 路由开发规范
• 前端组件开发: TypeScript + React、Chakra UI、状态管理: 前端组件开发规范
• 数据库操作: Model 定义、查询优化、索引设计: 数据库操作规范
• 包结构与依赖: 依赖方向、导入规范、类型导出: 包结构与依赖规范
• 日志与可观测性: 统一日志分类、结构化字段、敏感信息、OTEL 导出等审查标准: 日志review 标准

维度 3: 常见问题检查清单 🔍

快速识别和修复常见问题模式:

• TypeScript 问题: any 类型滥用、类型定义不完整、不安全断言
• 异步错误处理: 未处理 Promise、错误信息丢失、静默失败
• React 性能: 不必要的重渲染、渲染中创建对象、缺少 memoization
• 工作流节点: isEntry 未重置、交互历史未清理、白名单遗漏
• 安全漏洞: 注入攻击、XSS、文件上传漏洞

📖 详细清单: common-issues-checklist.md

3. 生成并输出综合审查报告

本地审查输出主要通过对话框返回整体审查报告和行级建议。

步骤 1: 结合上下文深度分析代码并准备评论

在详细审查阶段，记录之前通过额外探索收集的上下文论据：

• 全局视野：这个改动是否打破了使用该模块的其他文件的运行？
• 文件路径: 如 packages/service/core/workflow/dispatch.ts
• 行号 / 变更块: 如 L142-L150
• 问题类型: 🔴严重 / 🟡改进 / 🟢优化
• 评论内容: 具体的问题描述和基于整体上下文推导出的深层建议

步骤 2: 汇总代码审查评论

将所有的行级代码和上下文关联分析结果整合成一份连贯的内容：

### 📍 代码级深层意见

#### `packages/service/core/workflow/dispatch.ts`
- **L142**: 🔴 **严重跨文件隐患**: 这里更改了返回值格式，但通过 `git grep` 追踪发现调用方的接收逻辑（如 `file_B.ts L30`）未进行相应的适配，将导致生产环境崩溃。
    **建议**: 修改本处的兼容逻辑，或一并更新相关的调用方代码：
    ```typescript
    // 提供结合了调用关系的修复代码
    ```
- **L150**: 🟡 **逻辑重构优化**: 结合该文件的大环境，该段正则其实在多个地方共享，建议提取到外部公共目录中复用。

步骤 3: 生成整体审查报告

在对话框中提供类似以下的整体审查报告格式：

# Local Review 代码审查报告

## 📊 审查面与追踪范围
- **本地变更类型**: 未暂存 / 已暂存 / 与某分支差异
- **变更统计**: +{additions} -{deletions} 行
- **涉及直接修改文件**: {files.length} 个
- **延伸上下文排查文件**: {context_files.length} 个（评估了相关的外链影响）

## ✅ 亮点与优点
{列出做得好的地方}

## ⚠️ 问题汇总

### 🔴 严峻环境问题 ({count} 个,必须修复)
{简要列出每个严重问题，并指向下文的详细行级评论}

### 🟡 建议与重构项 ({count} 个)
{简要列出每个建议}

### 🟢 局部优化选项 ({count} 个)
{简要列出优化建议}

---
{在此处插入包含上下文增强分析内容的 "📍 代码级深层意见"}
---

## 🧪 本地测试验证策略
{基于本次上下文排查所发现的影响范围，给出建议：例如某个隐性关联页面的渲染测试等}

## 💬 总体评价
- **代码质量**: ⭐⭐⭐⭐☆ (4/5)
- **安全性**: ⭐⭐⭐⭐⭐ (5/5)
- **性能**: ⭐⭐⭐⭐☆ (4/5)
- **全栈协调性**: ⭐⭐⭐⭐☆ (4/5) (反映修改对全局代码影响程度的好坏)

## 🚀 审查结论
{建议: 可以提交 / 修改后提交 / 建议将调用方文件的修复一起囊括}

步骤 4: 响应用户并提供报告

输出或保存完整的 Markdown 报告，必要时提出主动帮用户把发现的联调问题（调用方 bug 等）以命令形式进行顺手修复的建议。

本地审查命令快速补救参考:

场景	命令
修改后需重新审查暂存区	git diff --cached
检测改动后是否出现死类型	pnpm tsc --noEmit
放弃某个被污染的本地改动	git checkout -- <file>