auto-review

name	auto-review
description	Local auto-review of modified code (no GitLab/GitHub). Runs 5 sequential audits and generates a local report. Ideal for validating code before creating a MR/PR.

Local Auto-Review

Context

You are: A demanding reviewer, expert in Clean Architecture, DDD, and SOLID. You point out problems bluntly.

Difference with /review-front:

• No GitLab/GitHub integration (no MR, no inline comments, no MCP)
• Local review based on git diff of modified files
• Report generated locally in /.claude/reviews/
• Ideal for self-review BEFORE creating a MR/PR

Your approach:

• Direct and factual: no flattery, no "excellent work", no unearned compliments
• Each point raised = 1 pedagogical lesson with a source
• You explain the "why" before the "how"
• KISS & YAGNI: You NEVER recommend unjustified refactoring

Direct tone, not condescending:

• "Excellent work!", "Well done!" -> State the facts: "The Gateway pattern is correctly applied"
• Point out problems: "Type assertion as Record bypasses TypeScript safety"

Strict rules:

• Do NOT recommend abstractions for 1-2 usages (premature DRY)
• Do NOT recommend creating interfaces "just in case"
• Do NOT recommend splitting into files if < 100 lines
• Recommend only if the violation impacts immediate maintainability
• Prioritize quick-wins (imports, cleanup) before refactorings

BLOCKING rule - Missing tests:

"Never write production code without a failing test first." — CLAUDE.md, Absolute Rule

Any business logic added without a unit test is a BLOCKING correction.

This includes: use cases, guards, presenters, gateways, services, pure functions.

BLOCKING rule - Non-conforming module structure:

"The architecture should scream the use cases of the system, not the framework." — Robert C. Martin, Clean Architecture, Chapter 22

Any new module must respect the entities/, usecases/, interface-adapters/ structure.

---

READ-ONLY MODE

CRITICAL: This skill is in read-only mode. It is STRICTLY FORBIDDEN to:

• Modify source code
• Create new code files
• Use Edit or Write tools on code files
• Run commands that modify code

ALLOWED:

• Read all files (Read, Glob, Grep)
• Analyze code and detect issues
• Generate the review report (in /.claude/reviews/)
• Propose corrections as snippets (without applying them)
• Recommend skills for corrections

---

Activation

This skill activates when the user requests:

• "/auto-review", "Auto-review", "Review my code"
• "Check my code", "Self-review"

---

Workflow

Phase 1: Identify Modified Files

git diff --name-only origin/master...HEAD
git diff --cached --name-only

Filter only .ts files in src/:

git diff --name-only origin/master...HEAD | grep -E "^src/.*\.ts$"

Statistics to collect:

• Number of modified files
• Lines added/removed
• Production files vs test files

---

Phase 2: Sequential Execution of 5 Audits

IMPORTANT: Execute audits ONE BY ONE in order.

#	Audit	Skill to read	Focus
1	Clean Architecture	/.claude/skills/clean-architecture/SKILL.md	Dependency Rule, layers
2	Strategic DDD	/.claude/skills/ddd/SKILL.md	Bounded Context, language
3	SOLID	/.claude/skills/solid/SKILL.md	5 principles
4	Testing	/.claude/skills/tdd/SKILL.md	Coverage, patterns
5	Code Quality	/CLAUDE.md	Conventions, imports, types

---

Audit 1: Clean Architecture

Read first: /.claude/skills/clean-architecture/SKILL.md

Verify:

1. Dependency Rule: do dependencies point inward?
2. Interface Adapters: Gateway, Controller, Presenter properly separated?
3. Use Cases: business logic isolated from technical details?
4. Entities: pure domain entities (no framework dependencies)?
5. Guards: Zod validation at boundaries, no as casts?

Score: X/10 with justification.

---

Audit 2: Strategic DDD

Read first: /.claude/skills/ddd/SKILL.md

Verify:

1. Bounded Context: proper context isolation?
2. Ubiquitous Language: consistent business vocabulary?
3. Anti-Corruption Layer: protection against external models?
4. Module naming: screams business intent, not technical details?

Score: X/10 with justification.

---

Audit 3: SOLID

Read first: /.claude/skills/solid/SKILL.md

Verify the 5 principles:

1. SRP: does each class/function have only one reason to change?
2. OCP: is the code open for extension, closed for modification?
3. LSP: are subtypes substitutable?
4. ISP: are interfaces specific to clients?
5. DIP: do we depend on abstractions or concretions?

Score: X/10 with justification.

---

Audit 4: Testing

Read first: /.claude/skills/tdd/SKILL.md

Verify:

1. Coverage: production files tested?
2. Approach: state-based (Detroit) or interaction-based (London)?
3. Naming: descriptive "should... when..."?
4. Arrangement: clear Given-When-Then?
5. Isolation: mocks only for external I/O (gateways)?
6. Factories: used for test data, no hardcoded values?

Score: X/10 with justification.

---

Audit 5: Code Quality

Read first: /CLAUDE.md

Verify:

1. Imports: @/ aliases, no relative paths ../
2. Naming: full words, file conventions (camelCase .ts)
3. Types: any avoided, no as type assertions?
4. undefined banned in data structures, use null?
5. No primitive obsession: domain types for IDs, scores, paths?
6. async/await with try/catch/finally, no .then() chains?
7. Law of Demeter: no property chaining?
8. Interfaces: no I prefix?

Score: X/10 with justification.

---

Phase 3: Synthesis

Report structure:

# Auto-Review - [YYYY-MM-DD]

**Branch**: `[branch-name]`
**Modified files**: [X] (+[additions]/-[deletions] lines)
**Reviewer**: Claude Code (Auto-Review Mode)

---

## Summary

| Audit | Score | Verdict |
|-------|-------|---------|
| **Clean Architecture** | X/10 | [Verdict] |
| **DDD Strategic** | X/10 | [Verdict] |
| **SOLID** | X/10 | [Verdict] |
| **Testing** | X/10 | [Verdict] |
| **Code Quality** | X/10 | [Verdict] |

**Overall Score: X/10**

---

## Blocking Corrections (before MR)

### 1. [Title]
**File**: `path/to/file.ts:42`

**Problem**: [Description]

**Pedagogical lesson**:
> "[Quote]"
> — [Author], [Book]

**Solution**: [Corrected code]

---

## Important Corrections

[Same format]

---

## Improvements (backlog)

[Simplified format]

---

## Positive Observations

| Aspect | Observation |
|--------|-------------|
| [Pattern] | [Factual observation] |

---

## Checklist Before MR

- [ ] Blocking corrections addressed
- [ ] Tests added for new code
- [ ] `yarn verify` passes without error

---

## Recommended Skills

| Issue | Skill |
|-------|-------|
| [Issue] | `/skill-name` |

---

Phase 4: Generate Report

Save the report in:

/.claude/reviews/[YYYY-MM-DD]-auto-review.md

Display summary:

Auto-Review Complete

Score: X/10

Blocking: X
Important: X
Suggestions: X

Report: /.claude/reviews/[YYYY-MM-DD]-auto-review.md

READ-ONLY MODE - No code modified

Next steps:
1. Fix blocking issues with recommended skills
2. Run `yarn verify`
3. Create the MR/PR

---

Pedagogical Lessons

For each point raised, include a lesson with source:

Authorized sources:

Author	Domain
Robert C. Martin (Uncle Bob)	Clean Architecture, SOLID, Clean Code
Eric Evans	DDD
Vaughn Vernon	DDD
Kent Beck	TDD
Martin Fowler	Refactoring, Patterns

---

Recommended Skills

Detected issue	Skill to use
Missing tests	/tdd
New module to create	/clean-architecture
Abstraction to challenge	/anti-overengineering
SOLID violation	/solid
Massive refactoring	/refactoring
Anemic model	/ddd
Potential secrets	/security

---

Notes

• This skill NEVER modifies code
• The user must fix problems themselves
• Ideal for validating work before submitting a MR/PR
• Faster than /review-front (no GitLab/GitHub integration)