SKILL.md

When to Activate

  • User asks to review a pull request or specific code changes
  • User wants a code quality audit on a file, module, or entire codebase
  • User asks to check code against project rules before merging
  • User requests feedback on their implementation or architecture decisions
  • User invokes the /codi-code-review slash command directly

Skip When

  • User wants the bug fixed, not reviewed — use codi-debugging
  • User wants new code written — use codi-plan-writer or codi-plan-execution
  • User needs a dedicated security audit — use codi-security-scan
  • User needs coverage measurement — use codi-test-suite
  • User wants refactoring suggestions without finding bugs — use codi-refactoring

Review Process

Step 1: Identify Changes

[CODING AGENT] Run git diff (or git diff --staged) to identify all changed files. If reviewing a PR, use git diff main...HEAD.

List each changed file with the type of change (added, modified, deleted).

Step 2: Read Context

[CODING AGENT] For each changed file:

  • Read the full file (not just the diff) to understand context
  • Read imported modules and interfaces referenced by the changes
  • Check if tests exist for the changed code

Step 3: Analyze Against Rules

[CODING AGENT] Check each change against the project’s rules in .codi/rules/:

  • Security: secrets exposure, input validation, injection risks
  • Error handling: unhandled errors, missing cleanup, silent failures
  • Testing: new code without tests, changed behavior without updated tests
  • Architecture: circular dependencies, wrong abstraction level, file size
  • Performance: N+1 queries, unnecessary re-renders, missing pagination
  • Code style: naming, function length, commented-out code

Step 4: Check Correctness

[CODING AGENT] Beyond rules, verify:

  • Logic errors: off-by-one, null handling, edge cases
  • API contract: does the implementation match the interface?
  • Concurrency: race conditions, shared mutable state
  • Backward compatibility: breaking changes to public APIs
  • Test quality: do tests cover the actual behavior change, not just exist? Are assertions meaningful?
  • Accessibility: do UI changes maintain keyboard navigation, ARIA labels, and semantic HTML?

Step 5: Format Findings

[CODING AGENT] Organize findings by severity:

Critical — Must fix before merge:

  • Security vulnerabilities
  • Data loss or corruption risks
  • Logic errors that cause incorrect behavior

Warning — Should fix, creates risk:

  • Missing error handling
  • Missing tests for new behavior
  • Performance concerns under load

Suggestion — Optional improvement:

  • Naming clarity
  • Code structure or readability
  • Simplification opportunities

For each finding include:

  • File path and line number
  • What the issue is
  • Why it matters
  • Suggested fix (code snippet when helpful)

Step 6: Summary

[CODING AGENT] End with:

  • Total findings count by severity
  • Overall assessment: approve, request changes, or needs discussion
  • Files that need the most attention

Available Agents

For specialized analysis, delegate to these agents:

  • codi-code-reviewer — Severity-ranked review with confidence filtering. Prompt at ${CLAUDE_SKILL_DIR}[[/agents/code-reviewer.md]]
  • codi-security-analyzer — Deep OWASP vulnerability analysis. Prompt at ${CLAUDE_SKILL_DIR}[[/agents/security-analyzer.md]]
  • codi-performance-auditor — Performance anti-pattern detection. Prompt at ${CLAUDE_SKILL_DIR}[[/agents/performance-auditor.md]]

Requesting a Review

Code reviews are not optional. Request a review after each implementation task completes (in codi-plan-execution workflow), after completing a major feature, and always before merging to main.

When to request:

  • After codi-plan-execution completes all tasks — dispatch a full-changeset review
  • After completing a significant feature or bug fix
  • Before invoking codi-branch-finish

What to provide to the reviewer:

  • Starting commit SHA: git log --oneline | tail -1 | awk '{print $1}'
  • Current commit SHA: git rev-parse HEAD
  • Implementation summary: what was built and why
  • Reference to the design spec (docs/ path)
  • Specific areas of concern if any

Acting on feedback:

  • CRITICAL/HIGH: fix immediately, do not proceed to codi-branch-finish
  • MEDIUM: fix before merge; document in PR if deferring
  • LOW: note in PR description; fix if trivial

Receiving a Code Review

When feedback ARRIVES on YOUR work, this is no longer the right skill — switch to codi-receiving-code-review, which enforces the iron law (external feedback is suggestions to evaluate, not orders to follow), the forbidden-phrase list, and the 4-step READ → VERIFY → DECIDE → RESPOND workflow.

  • codi-security-scan — Dedicated security audits beyond code review scope
  • codi-test-suite — Verify test coverage for reviewed changes
  • codi-brainstorming — Design before the code being reviewed was written
  • codi-plan-execution — Requests reviews after each task via this skill
  • codi-receiving-code-review — Sibling skill for the consuming side: how to evaluate and respond to feedback on YOUR work
  • codi-branch-finish — Runs a final review before merge options