git-code-review
Review uncommitted or committed changes in the current branch and generate a code review report. Use when the user wants to review their changes before or after committing.
- License 许可
- MIT
- 最近更新
- 2026-10-08
- Stars
- ★ 2
- Forks
- 0
01 前言 Front Matter
- name
- git-code-review
- license
- MIT
- metadata
- { "author": "zhaoyi", "version": "1.6", "generatedBy": "1.0.0" }
- description
- Review uncommitted or committed changes in the current branch and generate a code review report. Use when the user wants to review their changes before or after committing.
- compatibility
- Requires git CLI and a git repository.
03 SKILL.md 正文
Review uncommitted or committed changes in the current branch and generate a code review report.
Input: Optionally specify:
- Review scope:
unstaged,staged,unpushed,all - Review focus:
security,performance,style,architecture,all
IMPORTANT: This skill MUST read openspec/project.md before performing the review to understand project-specific conventions and constraints.
重要: 审查报告必须使用中文输出。
Steps
-
Load project conventions
CRITICAL: First read
openspec/project.mdto get:- Technology stack constraints
- Layered architecture rules
- Naming conventions
- Code style requirements
- Design patterns
- Important constraints
Use these conventions as the baseline for the review.
-
Determine review scope
Run
git statusto see all changes.Run
git branch --show-currentto get the current branch name.Use AskUserQuestion tool to ask what to review:
Review scope options:
unstaged- Only unstaged changes (default if no staged changes)staged- Only staged changes (default if staged changes exist)unpushed- All commits not yet pushed to remoteall- All uncommitted changes + unpushed commits
If
unpushedorall:git log origin/<current-branch>..HEAD --onelineto list unpushed commits.
-
Get diff content
For unstaged changes:
git diffFor staged changes:
git diff --cachedFor unpushed commits:
git diff origin/<current-branch>..HEADFor all changes:
git diff HEAD git log origin/<current-branch>..HEAD --onelineRun
git diff --statto get a summary of changes. -
Secret scanning
Use
git diffoutput to scan for potential secrets:- API keys (patterns like
api_key,apikey,API_KEY) - Passwords (
password,passwd,pwd) - Tokens (
token,access_token,refresh_token) - Private keys (
-----BEGIN.*PRIVATE KEY-----) - Database URLs with credentials
- AWS/Azure/GCP credentials
If secrets detected:
- Add to Critical issues section
- Suggest using environment variables or secret management
- Warn about git history (may need
git filter-branchor BFG)
- API keys (patterns like
-
Perform code review based on openspec/project.md
Analyze the changes against the project conventions loaded from
openspec/project.md:5.1 Technology Stack Compliance:
- Java 8 compatibility (no Java 9+ features:
var,record,sealed, pattern matching, text blocks) - Spring Boot annotations usage
- MyBatis/MyBatis-Plus usage (
@TableName) - MapStruct for object conversion
- Lombok annotations (
@Data,@Builder,@Slf4j,@AllArgsConstructor,@NoArgsConstructor) - PageHelper for pagination
- Swagger 2 (
@Api,@ApiOperation,@ApiModelProperty) or OpenAPI 3 (@Schema)
5.2 Layered Architecture Compliance: Check that code follows the strict layering: Web → Biz → Core → Common
- No reverse dependencies (lower layers depending on upper layers)
- No cross-layer dependencies (each layer only depends on direct lower layer)
5.3 Naming Conventions:
Type Pattern Example Controller *ControllerPurWebContractPaymentBaseControllerBizService *BizService/*BizServiceImplContractPaymentBaseBizServiceDomainService *DomainService/*DomainServiceImplContractPaymentBaseDomainServiceMapper @RepositoryContractPaymentBaseMapperManualMapper *ManualMapperContractPaymentBaseManualMapperDO *DOContractPaymentBaseDOModel *ModelContractPaymentBaseModelVO *VOWebContractPaymentConfirmedVORequest *RequestContractPaymentBaseAddRequestConverter *Convert/*ConverterContractPaymentBaseConvertFacadeClient *FacadeClient/*FacadeClientImplIdGeneratorFacadeClientUtils *UtilsAssertUtilsConditionDalRequest *ConditionDalRequestContractPaymentBaseConditionDalRequest5.4 Annotation Usage:
Controller Layer:
@RestController,@RequestMapping@Api+@ApiOperation(Swagger 2) or@Schema(OpenAPI 3)@Slf4j@Authority(permissionCode = ...)or@NonLoginAuthority@Validatedwith JSR-303 annotations- Return type:
YzwResult<T>
BizService Layer:
- Interface:
*BizService - Implementation:
@Service,@Slf4j,*BizServiceImpl - Injection:
@Resource(preferred) or@Autowired
DomainService Layer:
- Interface:
*DomainService - Implementation:
@Service,@Slf4j,*DomainServiceImpl - Write operations:
@Transactional(rollbackFor = Throwable.class) - Injection:
@Autowiredor@Resource
DO Objects:
- Extend
AbstractBaseDO @TableName(MyBatis-Plus)@Data,@ToString(callSuper = true),@EqualsAndHashCode(callSuper = true)- JavaDoc for fields
Model Objects:
- Extend
AbstractBaseBO @Data- JavaDoc for fields
Request Objects:
- AddRequest extends
CreateInfo - UpdateRequest extends
UpdateInfo @Data,@Builder,@AllArgsConstructor,@NoArgsConstructor
5.5 Code Style:
- Import order: Java stdlib → Third-party → Project internal
- No full package name imports (e.g., use
Listnotjava.util.List) - Empty lines between class members and methods
- Use
log.debug(),log.info(),log.error()- NOSystem.out.println()
5.6 Error Handling:
- Use
AssertUtilsfor validation - Throw
BusinessExceptionwithBizErrorCode - Private validation methods:
validateAddXxx(),validateUpdateXxx()
5.7 Pagination:
- Use
PageHelper.startPage(pageNum, pageSize) - Convert to
Page<DO>type - Use
PageConvertUtils.pageResultConvert(PageInfo, List) - Empty result:
PageConvertUtils.getResult(PageInfo)
5.8 Object Conversion:
- MUST use MapStruct (
@MapperwithINSTANCEconstant) - Call pattern:
XxxConvert.INSTANCE.method(...) - NO manual field-by-field conversion
5.9 Collection Handling:
- Use
CollectionUtils.isEmpty()/CollectionUtils.isNotEmpty() - Use
StringUtils(Apache Commons Lang3) for strings
5.10 Transaction Management:
- Write operations MUST have
@Transactional(rollbackFor = Throwable.class) - Read operations: no transaction needed
5.11 Security:
- SQL injection prevention (parameterized queries)
- XSS prevention
- Input validation
- Authentication/Authorization with
@Authority
5.12 Performance:
- N+1 query detection
- Batch query optimization
- Efficient algorithms
- Java 8 compatibility (no Java 9+ features:
-
Check historical reviews
If review reports exist in
openspec/review/:- List previous review reports
- Compare with last review (if same branch)
- Highlight recurring issues
- Show improvement trend
-
Save review report to file (使用中文)
CRITICAL: 不需要询问用户,直接保存。
a. 用 Shell 创建目录(如不存在):
mkdir -p openspec/reviewb. 使用 Write 工具将报告写入openspec/review/YYYY-MM-DD-HH-mm-<branch-name>-review.mdc. 如果同名文件已存在,使用-N后缀:YYYY-MM-DD-HH-mm-<branch-name>-review-N.mdReport structure (中文模板):
# 代码审查报告 **日期:** YYYY-MM-DD HH:mm **分支:** <branch-name> **审查人:** Claude Opus 4.6 **审查范围:** 未暂存 / 已暂存 / 未推送 / 全部 **规范基准:** openspec/project.md ## 概要 - 变更文件数: X - 新增行数: X - 删除行数: X - 审查提交数: X (如果是未推送) - 发现问题数: X (严重: X, 重要: X, 一般: X, 建议: X) ## 严重问题 ? <!-- 必须立即修复的严重问题 --> 1. **[安全] SQL注入风险** - `path/to/file.java:123` ```java // 问题代码片段修复建议: 使用参数化查询
重要问题 ⚠️
<!-- 应该修复的重要问题 -->
一般问题 ?
<!-- 轻微问题或代码风格改进 -->
改进建议 ?
<!-- 可选的改进建议 -->
规范违规 (openspec/project.md)
<!-- 违反项目规范的问题 -->
规范类型 文件 问题描述 命名规范: Controller path/to/file.java 类名应以 'Controller' 结尾 架构规范: 分层 path/to/file.java Core层不应依赖Biz层 已审查文件
文件 变更行数 问题数 严重程度 path/to/file.java +50/-10 2 重要 敏感信息扫描结果
- 未检测到敏感信息 ✅ <!-- 或者 -->
- ⚠️ 在 X 个文件中检测到潜在敏感信息
与上次审查对比
<!-- 如果存在之前的审查记录 -->
- 上次审查日期: YYYY-MM-DD HH:mm
- 已解决问题: X
- 新发现问题: X
- 重复问题: X
修复建议
- 优先修复项
- 后续步骤
亮点肯定 ✨
<!-- 代码中发现的良好实践 -->
-
Output full report to conversation, then prompt for fix proposal (输出报告+询问提案,合并为一条消息)
在同一条消息中完成以下全部内容:
a. 输出完整报告内容到对话(与 Step 7 保存到文件的内容相同) b. 在报告末尾注明:
> 报告已保存到 openspec/review/YYYY-MM-DD-HH-mm-<branch-name>-review.mdc. 如果发现严重或重要问题,在报告输出之后使用 AskUserQuestion tool 询问:"审查发现 X 个严重问题和 Y 个重要问题。是否需要生成 OpenSpec 修复提案?"
选项:
生成修复提案- 使用/opsx:propose生成修复提案暂不生成- 稍后手动处理 d. 如果仅有一般问题和建议,不发起 AskQuestion,消息到此结束。
-
If user chose to generate fix proposal, create proposal and append summary to report (提案生成+摘要回写)
当用户选择"生成修复提案"后:
a. 根据问题类型生成提案名称(kebab-case):
- 安全问题:
fix-security-<issue-type> - 规范违规:
fix-convention-<issue-type> - 性能问题:
fix-performance-<issue-type> - 混合问题:
fix-<主要问题描述>
b. 构建提案描述:
- Why: 说明发现的问题及其影响
- What Changes: 列出需要修复的文件和修改内容
- 引用审查报告路径
c. 调用
/opsx:propose生成修复提案d. 提案生成完成后,必须将提案摘要追加写入已保存的报告文件末尾(Read 报告文件获取当前内容,在末尾追加后重新 Write),追加内容:
## 修复提案 **提案名称:** <change-name> **提案路径:** `openspec/changes/<change-name>/` **生成时间:** YYYY-MM-DD HH:mm ### 提案包含制品 - `proposal.md` - 提案文档 - `design.md` - 设计文档 - `specs/` - 规格文档 - `tasks.md` - 实施任务 ### 后续操作 运行 `/opsx:apply` 开始实施修复。e. 在对话中告知用户:提案已生成,摘要已追加到报告文件中,运行
/opsx:apply开始实施修复。如果只有一般问题或建议:
- 不自动提示生成提案
- 用户可手动运行
/opsx:propose生成提案
- 安全问题:
Output On Success (中文输出)
## 代码审查完成
**分支:** <branch-name>
**审查范围:** <scope>
**规范基准:** openspec/project.md
**报告路径:** openspec/review/YYYY-MM-DD-HH-mm-<branch-name>-review.md
### 问题统计
| 严重程度 | 数量 |
|----------|------|
| 严重 | X |
| 重要 | X |
| 一般 | X |
| 建议 | X |
### 规范违规统计
| 类型 | 数量 |
|------|------|
| 命名规范 | X |
| 架构规范 | X |
| 代码风格 | X |
### 敏感信息扫描
✅ 未检测到敏感信息
<!-- 或者 -->
⚠️ 在 X 个文件中检测到潜在敏感信息 - 详情见报告
### 严重问题(必须在提交前修复)
1. **[安全] SQL注入** - `path/to/file.java:123`
2. ...
### 后续步骤
1. 修复严重问题
2. 修复规范违规
3. 审查重要问题
4. 重新运行代码审查: `/git-code-review`
Output With Fix Proposal (用户同意生成提案后的最终输出)
## 修复提案已生成
**提案名称:** fix-<issue-name>
**提案路径:** openspec/changes/fix-<issue-name>/
**提案摘要已追加到报告文件中:** openspec/review/YYYY-MM-DD-HH-mm-<branch-name>-review.md
### 提案包含制品
- `proposal.md` - 提案文档
- `design.md` - 设计文档
- `specs/` - 规格文档
- `tasks.md` - 实施任务
运行 `/opsx:apply` 开始实施修复。
严重程度说明
| 严重程度 | 图标 | 判定标准 | 处理建议 |
|---|---|---|---|
| 严重 | ? | 安全漏洞、Bug、破坏性变更、敏感信息泄露 | 必须在提交前修复 |
| 重要 | ⚠️ | 规范违规、性能问题、SOLID原则违反 | 应在合并前修复 |
| 一般 | ? | 代码风格、命名、注释 | 建议修复 |
| 建议 | ? | 最佳实践、优化建议 | 可选修复 |
Review Focus Areas
When user specifies focus areas, prioritize:
security- Focus on security vulnerabilities + secret scanningperformance- Focus on performance issues + N+1 queriesstyle- Focus on code style and conventionsarchitecture- Focus on layered architecture and design patternsall- Full review (default)
Guardrails
- ALWAYS read
openspec/project.mdbefore reviewing - Always ask for review scope first (Step 2 is the ONLY place to use AskQuestion before the report)
- Always run secret scanning
- ALWAYS save review report to
openspec/review/— do NOT ask, just save and also output to conversation - 审查报告必须使用中文输出
- Use severity levels consistently
- Check against project-specific conventions from openspec/project.md
- Provide actionable recommendations with file paths and line numbers
- Include code snippets in issue descriptions
- Include positive highlights to encourage good practices
- Never auto-fix issues without user confirmation
- Compare with previous reviews for trend analysis
- AskQuestion 使用约束:整个流程最多使用两次 AskQuestion —— Step 2(选择审查范围)和 Step 8c(仅当存在严重或重要问题时询问是否生成提案)。不要在其他步骤额外询问。
- Step 7 仅保存文件,Step 8 才输出到对话:严格分离"保存"和"展示"两个动作,避免重复或遗漏。
- 生成修复提案时:
- 仅在发现严重或重要问题时提示生成提案
- 提案名称使用 kebab-case 格式
- 提案描述必须包含审查报告路径
- 生成的提案应包含具体的修复步骤
- 提案生成后必须将摘要追加到已保存的报告文件末尾
Error Handling
- If
openspec/project.mdnot found: Warn user and use default conventions - If no changes to review: Inform user and exit
- If diff is too large (>5000 lines): Review file by file and summarize
- If review directory creation fails: Show error and suggest manual creation
- If secret scanning fails: Continue review and note the failure
Convention Checklist (from openspec/project.md)
| Category | Check |
|---|---|
| Java Version | Java 8 compatible |
| Layering | Web → Biz → Core → Common, no reverse deps |
| Naming | Controller/BizService/DomainService/DO/Model/VO/Request |
| Annotations | @RestController/@Service/@Transactional/@Data/@Builder |
| Transaction | @Transactional(rollbackFor = Throwable.class) on writes |
| Pagination | PageHelper.startPage() + PageConvertUtils |
| Conversion | MapStruct with INSTANCE, no manual conversion |
| Error | AssertUtils + BusinessException + BizErrorCode |
| Logging | log.debug/info/error, no System.out |
| Imports | Java stdlib → Third-party → Project internal |
| Collections | CollectionUtils.isEmpty/isNotEmpty |
| Strings | StringUtils (Apache Commons) |
04 同仓库更多 Skills
opsx-dev-pipeline
OpenSpec + Git 需求开发全流程。
git-merge-branch
Merge current branch to a target branch. Use when the user wants to merge their current branch to another branch (e.g., qa, master, develop).
git-commit-push
Commit and push code changes to the remote repository. Use when the user wants to commit their changes and push to remote.
file-code-review
Review specified files or code snippets against project conventions and generate a code review report. Use when the user wants to review specific files (e.g., "review this file", "审查这个文件") or code blocks (e.g., "review this code", "审查这段代码") without git context. Supports single file, multiple files, or pasted code snippets.
openspec-propose
Propose a new change with all artifacts generated in one step. Use when the user wants to quickly describe what they want to build and get a complete proposal with design, specs, and tasks ready for implementation.
openspec-explore
Enter explore mode - a thinking partner for exploring ideas, investigating problems, and clarifying requirements. Use when the user wants to think through something before or during a change.