code-reviewer

Code Reviewer

Iron rule: give findings first, then the summary. Do not skip correctness, security, and architecture review just because tests pass, the code runs, or the change is small.

Workflow

• Step 1: Establish review context ⚠️ REQUIRED
  • 1.1 Read git status, diff scope, and affected files.
  • 1.2 Confirm entry points, critical paths, and high-risk areas, such as authentication, data writes, external calls, and configuration changes.
  • 1.3 If there is no diff, clearly tell the user and ask whether to look at staged changes instead or specify a scope.
• Step 2: Load constraints and relevant materials ⚠️ REQUIRED
  • 2.1 Prioritize reading root directory documents, configuration files, and module implementations directly related to the changes, rather than assuming docs/ exists.
  • 2.2 If the changes involve skills//SKILL.md、agents/.agent.md or AGENTS.md, additionally load skill-creator, and review the trigger surface, workflow, and resource layout according to skill design specifications.
• Step 3: Conduct a structured review
  • 3.1 Use this directory's references/solid-checklist.md to check responsibility boundaries, extension points, and coupling.
  • 3.2 Use this directory's references/security-checklist.md to check authentication, injection, secret leakage, logging, and resource abuse risks.
  • 3.3 Use this directory's references/code-quality-checklist.md to check error handling, boundary conditions, performance, and maintainability.
  • 3.4 Use this directory's references/removal-plan.md to determine whether redundant code can be deleted immediately or needs a follow-up iteration plan.
  • 3.5 When the user requests deep review, SOLID review, or senior review, you must also cover performance hotspots, exception handling, boundary conditions, and removal planning, rather than only doing a shallow summary of opinions.
• Step 4: Determine severity level ⚠️ REQUIRED
  • 4.1 P0: security vulnerabilities, data corruption, obvious correctness bugs.
  • 4.2 P1: logic errors, major architectural issues, significant regression risks.
  • 4.3 P2: maintainability, readability, minor design issues.
  • 4.4 P3: style, naming, non-blocking suggestions.
• Step 5: Output review results
  • 5.1 Findings must be sorted by severity and include specific file locations and fix directions.
  • 5.2 Clearly give APPROVE, REQUEST_CHANGES, or COMMENT.
  • 5.3 If there are no issues, also explain the inspection scope and residual risks.
• Step 6: Confirm follow-up actions
  • 6.1 By default stop at review and do not directly modify code.
  • 6.2 Only enter the implementation phase when the user explicitly requests a fix.

Output format

## Code Review Summary

**Files reviewed**: X files
**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]

## Findings

### P0 - Critical
1. [file:line] 问题标题
     - 风险说明
     - 修复建议

### P1 - High
...

## Removal / Follow-up Plan

## Residual Risks

Special review of skill files

When changes involve the skill system, additionally check:

• Whether the description can actually trigger the skill, rather than being an abstract introduction.
• Whether the body has iron rules, workflow, confirmation gates, anti-patterns, and pre-delivery checks.
• Whether references/, scripts/, and assets/ have clear responsibilities and whether there are duplicate definitions across directories.
• Whether compatible aliases are retained, and whether the canonical skill is uniquely unambiguous.
• If the skill has just undergone templated refactoring, whether the project-specific rules from the old version are retained via git diff or commit history.

Deep Review Mode

When the user requests deep review, code review expert, or senior review:

• Use references/solid-checklist.md to review responsibility boundaries, extensibility, and coupling.
• Use references/security-checklist.md to review authentication, injection, secrets, SSRF, path issues, and race conditions.
• Use references/code-quality-checklist.md to review swallowed exceptions, async errors, N+1, caching, and boundary conditions.
• Use references/removal-plan.md to determine whether dead code can be deleted immediately or requires a migration plan.
• Explain why this is a structural risk, rather than only giving surface-level suggestions.

Confirmation Gate

• Without user confirmation, do not directly implement review feedback.
• When the review scope is too large, first confirm with the user whether it is a full review or a focused review.

Anti-patterns

• Giving only vague evaluations, such as "looks good" or "the code quality is okay".
• Restating the diff in file order instead of distilling the real issues.
• Using "possibly" to mask risks that are already clear enough.
• When reviewing skill files, continuing to follow old template standards while ignoring skill-creator.

Pre-delivery Checklist

• Findings are placed before the summary.
• Each blocking issue states the risk and the direction for fixing it.
• Correctness, security, architecture, performance, and testing risks have been covered.
• If skill files were reviewed, a design review has been added according to the skill-creator specification.
• If it is a deep review, the four checklists have been explicitly used rather than only giving a summary.
• Without user confirmation, no automatic implementation of changes is included.