shaun0927/codex-superskills/code-review-expert

Code Review Expert

Overview

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

Severity Levels

Workflow

1) Preflight context

• Use git status -sb, git diff --stat, and git diff to scope changes.
• Use rg 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, ask whether to review staged changes or a commit range.
• Large diff (>500 lines): summarize by module first, then review in batches.
• Mixed concerns: group findings by logical feature, not file order only.

2) SOLID and architecture smells

• Load references/solid-checklist.md.
• Check:
• SRP: overloaded modules with unrelated responsibilities
• OCP: adding behavior requires editing core branching logic repeatedly
• LSP: subtype behavior violates caller expectations
• ISP: wide interfaces with mostly-unused methods
• DIP: high-level logic bound to concrete low-level implementations
• When proposing refactors, explain cohesion/coupling impact and provide a minimal safe path.
• Prefer incremental refactor plans over large rewrites.

3) Removal candidates and iteration plan

• Load references/removal-plan.md.
• Identify unused, redundant, or obsolete code.
• Separate safe-delete-now vs defer-with-plan.
• Provide follow-up checkpoints (tests, telemetry, rollout validation).

4) Security and reliability scan

• Load references/security-checklist.md.
• Check for:
• XSS, injection (SQL/NoSQL/command), SSRF, path traversal
• AuthN/AuthZ gaps, tenancy checks
• Secret leakage in code/logs/config
• Rate limiting and unbounded execution risks
• Unsafe deserialization, weak crypto, insecure defaults
• Race conditions (shared state, check-then-act, TOCTOU)
• Call out exploitability and impact.

5) Code quality scan

• Load references/code-quality-checklist.md.
• Check for:
• error handling defects (swallowed exceptions, broad catch, async errors)
• performance regressions (N+1, hot-path cost, missing cache)
• boundary bugs (null/undefined, empty collections, numeric limits, off-by-one)
• Highlight issues likely to cause silent failure or production incidents.

6) Output format

Use this structure:

## Code Review Summary
 
**Files reviewed**: X files, Y lines changed
**Overall assessment**: [APPROVE / REQUEST_CHANGES / COMMENT]
 
---
 
## Findings
 
### P0 - Critical
(none or list)
 
### P1 - High
-**[file:line]** Brief title
  -Description of issue
  -Suggested fix
 
### P2 - Medium
...
 
### P3 - Low
...
 
---
 
## Removal/Iteration Plan
(if applicable)
 
## Additional Suggestions
(optional, non-blocking)

For inline review comments in Codex UI, use:

::code-comment{title="[P1] Short title" body="One-paragraph issue and fix guidance." file="/absolute/or/repo/path.ts" start=42 end=44 priority=1 confidence=0.88}

If no issues are found, explicitly state:

• what was checked
• what was not covered
• residual risks or suggested follow-up tests

7) Next-step confirmation

After findings, ask user how to proceed:

## Next Steps
 
I found X issues (P0: _, P1: _, P2: _, P3: _).
 
1.Fix all
2.Fix P0/P1 only
3.Fix specific items
4.No changes

Important: do not implement changes until user confirmation when running in review-first mode.

Resources

references/