# Self Review

> Code-quality checklist run on Claude's own output before reporting done: unused imports, missing error handling, naming consistency, security issues. Use after completing any code changes.

- Skill: `theophiluschinomona/self-review` (Agent Skill)
- Install (CLI): `npx skillmds@latest add theophiluschinomona/self-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/theophiluschinomona/self-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: TheophilusChinomona (https://skillmd.com/u/theophiluschinomona)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/theophiluschinomona/self-review

---


# Self-Review Skill

## Purpose
Automated code review checklist that Claude runs on its own output before reporting "done." Catches unused imports, missing null checks, inconsistent naming, and other common issues that a human reviewer would flag.

## Activation
- After completing any code creation or modification task
- Before reporting to the user that work is done
- Run AFTER build-check passes (no point reviewing code that doesn't compile)

---

## How It Works

This is a checklist-based technique, not a scanner. After writing code, Claude re-reads its own output and checks each item. No cache needed.

---

## Phase 1: Universal Checks (All Languages)

Run these on every file created or modified:

```
□ No unused imports/usings — every import is used in the file
□ No unused variables — every declared variable is referenced
□ No hardcoded strings that should be constants — magic numbers, URLs, messages
□ No console.log/print statements left from debugging
□ No commented-out code blocks left behind
□ No TODO/FIXME/HACK comments added without being tracked in task-journal
□ Consistent naming — follows project convention (PascalCase, camelCase, snake_case)
□ File naming matches project convention
□ Exports match project convention (default vs named)
□ No duplicate code — if same logic exists elsewhere, consider shared utility
```

---

## Phase 2: Backend Checks

Derive the project's actual invariants from the pattern caches (`.claude/idev/backend-patterns/cache.md`) and the project rules file — do NOT assume any of these are universal. The items below are EXAMPLES of common invariants; replace them with what the caches say this project actually uses.

```
□ Controller/route methods use correct HTTP verb (GET for reads, POST for creates, PUT for updates, DELETE for deletes)
□ Route paths follow project convention (consistent with existing routes)
□ All endpoints have the project's auth attribute/middleware (or inherit from base)
□ Service methods follow the project's error handling pattern
□ Entity has all audit fields the project requires (EXAMPLE: CreatedDate, CreatedBy, UpdatedDate, UpdatedBy)
□ Soft delete uses the project's soft-delete flag, NOT physical delete (EXAMPLE: a RecordStatusId column)
□ Multi-tenancy: tenant filter column checked in all queries, if the project is multi-tenant (EXAMPLE: a ClientId column)
□ DTOs don't expose internal fields
□ Mapping method names are consistent with the project convention
□ No N+1 query patterns (loading related entities in a loop)
```

---

## Phase 3: Frontend Checks

Derive the project's actual invariants from the pattern caches (`.claude/idev/frontend-patterns/cache.md`) and the project rules file. The items below are EXAMPLES of common invariants — adapt to the detected framework, UI library, and styling approach.

```
□ Components use the project's typing convention (EXAMPLE: React FC typing)
□ Props interfaces are defined (not inline anonymous types)
□ Hooks follow naming convention (use* prefix)
□ useQuery/useMutation have proper query keys (if a query library is used)
□ Error states are handled (isError, error display)
□ Loading states are handled (isLoading, skeleton/spinner)
□ Empty states are handled (no data → show empty message)
□ Event handlers are memoized where needed
□ No direct state mutation (always use setter functions)
□ UI library components follow project patterns (size, styling)
□ Styling is consistent with the project's approach (EXAMPLE: Tailwind classes, no inline styles when a utility class exists)
□ Types match the API response shape (check api-contract-validation)
```

---

## Phase 4: Security Checks

```
□ No secrets/credentials in source code
□ No SQL injection vectors (parameterized queries only)
□ No XSS vectors (user input is sanitized before rendering)
□ No command injection (user input not passed to exec/system calls)
□ Auth checks present on all endpoints that need them
□ CORS is not overly permissive
□ No sensitive data in URL query parameters (use POST body)
□ No sensitive data logged to console or error logs
```

---

## Phase 5: How to Run

After completing code changes:

```
1. For each file created/modified, re-read it
2. Run through applicable checklists (universal + language-specific)
3. If issues found:
   a. Fix automatically if straightforward (unused import → remove)
   b. Flag to user if judgment needed (naming choice, architecture decision)
4. Report: "Self-review: N files checked, M issues found and fixed"
   Or: "Self-review: clean, no issues"
```

### When to SKIP self-review:
```
- Quick one-line fixes (typo, single property change)
- Non-code files (.md, .json, .txt, config)
- User explicitly says "skip review"
```

### Depth levels:
```
Quick review: Universal checks only (~30 seconds)
Standard review: Universal + language-specific (~1 minute)
Deep review: All checks including security (~2 minutes)

Default: Standard review
Use deep review for: new features, auth changes, data handling changes
```

---

## Phase 6: Integration

```
Feature creation workflow:
  1. Load lessons-learned → prevention steps
  2. Create files
  3. post-creation-verify → registration checks
  4. build-check → compile
  5. api-contract-validation → FE↔BE match
  6. self-review → code quality check  ← THIS SKILL
  7. Report to user
```

---

## Anti-Patterns

1. Do NOT review every line — focus on the checklist items
2. Do NOT re-read files that weren't changed
3. Do NOT block on style preferences — only flag objective issues
4. Do NOT add features during review (scope creep)
5. Do NOT report trivial issues — fix them silently