local-review

When to Use This Skill

Triggered when the user requests a local review. This skill supports environment-friendly in-depth review of the following three change scopes:

Uncommitted Changes: Review all modifications in the workspace that have not yet been committed (including staged and unstaged).
Specific Recent Commits: Select and inspect the changes of the most recent few commits (e.g., HEAD~N).
Main Branch Diff: Compare with main branches such as main , and review the incremental details of the current feature as a whole.

Local Review local code review skill

In the local development environment, leverage the context advantage of the full codebase to comprehensively review the quality, security, performance, and architectural design of code changes, automatically assess cross-file impacts, and provide professional improvement suggestions.

Scope Definitions and How to Start

You need to determine and select the corresponding comparison strategy to pull code based on the user's instruction intent.Be sure to use -U15 and other parameters to increase the local context view。

Mode 1: Uncommitted Changes Review

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

Mode 2: Specific Recent Commits Review

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

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

Mode 3: Main Branch Diff Review

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

Tool Integration

Use git CLI and local tools to accelerate review

When reviewing in the local environment, compared with the limitations of PR review, we should fully leverage the advantage of being able to "run around and look around".

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

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

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

Local Testing and Code Verification

During local review, the verification process can be executed directly, using the results as the basis for review:

# 运行单元测试
pnpm test

# 运行代码规范检查
pnpm lint

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

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

Common Command Reference

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

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

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

Review Process

1. Information and Context Collection Phase (⭐Core Local Environment Enhancement)

Do not blindly review based only on fragmented patch code (Diff chunks); be sure to establish a complete contextual understanding:

Automatically execute/guide execution of the following steps:

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

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

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

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

2. Multi-dimensional Code Review

Based on the complete call chain and file context, conduct a systematic review according to the following dimensions:

Dimension 1: Basic Code Quality Standards 📐

General code quality standards, applicable to all projects:

Security: Input validation, permission checks, injection protection, sensitive information protection
Correctness: Error handling, boundary conditions, type safety (In context, check whether the caller provides correct data）
Performance: Algorithm complexity, database optimization, memory management (In context, review loop logic or multiple re-render issues）
Testability: Test coverage, test quality, Mock usage

📖 Detailed Guide: code-quality-standards.md

Dimension 2: FastGPT Style Specifications 🎨

FastGPT project-specific code standards and conventions:

API Route Development: Route definition, permission verification, error handling: API Route Development Standards
Frontend Component Development: TypeScript + React, Chakra UI, state management: Frontend Component Development Standards
Database Operations: Model definition, query optimization, index design: Database Operations Standards
Package Structure and Dependencies: Dependency direction, import conventions, type exports: Package Structure and Dependency Standards
Logging and Observability: Review standards for unified log classification, structured fields, sensitive information, OTEL export, etc.: Log review standards

Dimension 3: Common Issues Checklist 🔍

Quickly identify and fix common issue patterns:

TypeScript Issues: any type abuse, incomplete type definitions, unsafe assertions
Async Error Handling: unhandled Promises, lost error information, silent failures
React Performance: unnecessary re-renders, creating objects during render, missing memoization
Workflow Nodes: isEntry not reset, interaction history not cleared, whitelist omissions
Security Vulnerabilities: injection attacks, XSS, file upload vulnerabilities

📖 Detailed Checklist: common-issues-checklist.md

3. Generate and output a comprehensive review report

Local review output mainly returns the overall review report and line-level suggestions through the dialog box.

Step 1: Deeply analyze the code with context and prepare comments

During the detailed review phase, record the contextual evidence previously collected through additional exploration:

Global Perspective: Does this change break the operation of other files that use this module?
File Path: e.g. packages/service/core/workflow/dispatch.ts
Line Number / Change Block: e.g. L142-L150
Issue Type: 🔴Critical / 🟡Improvement / 🟢Optimization
Comment Content: specific issue description and in-depth suggestions derived from the overall context

Step 2: Consolidate code review comments

Integrate all line-level code and context-related analysis results into a coherent piece of content:

### 📍 代码级深层意见

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

Step 3: Generate the overall review report

Provide an overall review report format similar to the following in the dialog box:

# Local Review 代码审查报告

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

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

## ⚠️ 问题汇总

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

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

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

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

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

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

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

Step 4: Respond to the user and provide the report

Output or save the complete Markdown report, and when necessary, proactively suggest helping the user conveniently fix the discovered integration issues (caller bugs, etc.) in the form of commands.

Quick remediation reference for local review commands:

Scenario	Command
Re-review the staging area after modifications	`git diff --cached`
Detect whether dead types appear after changes	`pnpm tsc --noEmit`
Discard a contaminated local change	`git checkout -- <file>`