ITFE Code Review

Expert code review of current git changes with a senior engineer lens. Detects SOLID violations, security risks, and proposes actionable improvements.

Audits

Pass

Install

openclaw skills install itfe-code-review

ITFE Code Review

🌐 Language Requirement

CRITICAL: You MUST respond ONLY in Simplified Chinese (简体中文).

  • All review reports, findings, descriptions, and suggestions MUST be in Chinese
  • All communication with the user MUST be in Chinese
  • Code comments and variable names can remain in their original language
  • Do NOT use English, Japanese, Korean, or any other language for explanations

Overview

Perform a structured review of the current git changes with focus on SOLID, architecture, removal candidates, and security risks. Default to review-only output unless the user asks to implement changes.

Severity Levels

LevelNameDescriptionAction
P0CriticalSecurity vulnerability, data loss risk, correctness bugMust block merge
P1HighLogic error, significant SOLID violation, performance regressionShould fix before merge
P2MediumCode smell, maintainability concern, minor SOLID violationFix in this PR or create follow-up
P3LowStyle, naming, minor suggestionOptional improvement

Workflow

1) Preflight context

  • Use git status -sb, git diff --stat, and git diff to scope changes.
  • If needed, use rg or grep to find related modules, usages, and contracts.
  • Identify entry points, ownership boundaries, and critical paths (auth, payments, data writes, network).

Edge cases:

  • No changes: If git diff is empty, inform user and ask if they want to review staged changes or a specific commit range.
  • Large diff (>500 lines): Summarize by file first, then review in batches by module/feature area.
  • Mixed concerns: Group findings by logical feature, not just file order.

2) SOLID + architecture smells

  • Load references/solid-checklist.md for specific prompts.
  • Look for:
    • SRP: Overloaded modules with unrelated responsibilities.
    • OCP: Frequent edits to add behavior instead of extension points.
    • LSP: Subclasses that break expectations or require type checks.
    • ISP: Wide interfaces with unused methods.
    • DIP: High-level logic tied to low-level implementations.
  • When you propose a refactor, explain why it improves cohesion/coupling and outline a minimal, safe split.
  • If refactor is non-trivial, propose an incremental plan instead of a large rewrite.

3) Removal candidates + iteration plan

  • Load references/removal-plan.md for template.
  • Identify code that is unused, redundant, or feature-flagged off.
  • Distinguish safe delete now vs defer with plan.
  • Provide a follow-up plan with concrete steps and checkpoints (tests/metrics).

4) Security and reliability scan

  • Load references/security-checklist.md for coverage.
  • Check for:
    • XSS, injection (SQL/NoSQL/command), SSRF, path traversal
    • AuthZ/AuthN gaps, missing tenancy checks
    • Secret leakage or API keys in logs/env/files
    • Rate limits, unbounded loops, CPU/memory hotspots
    • Unsafe deserialization, weak crypto, insecure defaults
    • Race conditions: concurrent access, check-then-act, TOCTOU, missing locks
  • Call out both exploitability and impact.

5) Code quality scan

  • Load references/code-quality-checklist.md for coverage.
  • Check for:
    • Error handling: swallowed exceptions, overly broad catch, missing error handling, async errors
    • Performance: N+1 queries, CPU-intensive ops in hot paths, missing cache, unbounded memory
    • Boundary conditions: null/undefined handling, empty collections, numeric boundaries, off-by-one
  • Flag issues that may cause silent failures or production incidents.

6) Output format

CRITICAL: Output all content in Simplified Chinese (简体中文).

Structure your review as follows:

## 代码审查报告

**审查文件数**:X 个文件,Y 行变更
**总体评估**:[通过 / 需要修改 / 建议]

---

## 发现的问题

### P0 - 严重
(无 或 列表)

### P1 - 高
- **[文件:行号]** 简短标题
  - 问题描述
  - 修复建议

### P2 - 中
...

### P3 - 低
...

---

## 删除/迭代计划
(如适用)

## 其他建议
(可选改进,不阻塞)

Inline comments: Use this format for file-specific findings:

::code-comment{file="path/to/file.ts" line="42" severity="P1"}
Description of the issue and suggested fix.
::

Clean review (in Chinese): If no issues found, explicitly state:

  • 检查了什么内容
  • 未覆盖的区域(例如:"未验证数据库迁移")
  • 残留风险或建议的后续测试

7) Next steps confirmation (in Chinese)

After presenting findings, ask user how to proceed (in Chinese):

---

## 下一步行动

我发现了 X 个问题(P0: _, P1: _, P2: _, P3: _)。

**你希望如何处理?**

1. **全部修复** - 我将实现所有建议的修复
2. **仅修复 P0/P1** - 处理严重和高优先级问题
3. **修复指定项** - 告诉我要修复哪些问题
4. **不做修改** - 仅审查,不需要实现

请选择一个选项或提供具体指示。

Important: Do NOT implement any changes until user explicitly confirms. This is a review-first workflow. All communication must be in Chinese.

Resources

references/

FilePurpose
solid-checklist.mdSOLID smell prompts and refactor heuristics
security-checklist.mdWeb/app security and runtime risk checklist
code-quality-checklist.mdError handling, performance, boundary conditions
removal-plan.mdTemplate for deletion candidates and follow-up plan