Skill: Critical Review

When to use this skill

• After every implementation - Validate work quality
• Before a significant commit - Ensure no technical debt is introduced
• Before a release - Full audit of modified code
• When in doubt - Objectively evaluate an approach

Available templates

Template	Usage
templates/quick_checklist.md	Quick validation checklist
templates/review_report.md	Detailed review report

Critical posture

Fundamental rule: Never accept mediocre code. Be your own harshest critic.

Questions to ask SYSTEMATICALLY

1. Code quality

• Is the code readable by another developer without explanation?
• Is there duplicate code that could be factored?
• Are variable/function names explicit?
• Is cyclomatic complexity reasonable?
• Do functions do one thing only (SRP)?

2. Error handling

• Are all error cases handled properly?
• Are there hidden .unwrap()?
• Are error messages informative?
• Are errors propagated correctly?

3. Tests

• Do tests cover nominal AND edge cases?
• Are tests independent from each other?
• Do tests document expected behavior?
• Would tests fail if the code was broken?

4. Architecture

• Does the code respect DDD architecture?
• Are there dependencies in the wrong direction (domain → infrastructure)?
• Is coupling minimal between modules?
• Is the code easily testable?

5. Performance

• Are there unnecessary allocations in hot paths?
• Are data structures appropriate?
• Are there blocking operations in async code?

Evaluation grid

After each implementation, self-evaluate honestly:

Criterion	Score	Description
Readability	1-5	Does the code read like prose?
Robustness	1-5	Does it handle all edge cases?
Testability	1-5	Are tests complete and relevant?
Maintainability	1-5	Could another dev modify it easily?
Performance	1-5	Is the code efficient?

Minimum acceptable score: 3/5 on each criterion

Red flags to detect

Critical code smells

// ❌ RED FLAG: unwrap without context
let value = some_option.unwrap();

// ❌ RED FLAG: potential hidden panic
let index = vec[user_input];

// ❌ RED FLAG: f64 for money
let total: f64 = price * quantity;

// ❌ RED FLAG: excessive clone
for item in collection.clone() { ... }

// ❌ RED FLAG: function too long (>50 lines)
fn do_everything() { /* 200 lines */ }

// ❌ RED FLAG: comment explaining obscure code
// This does X because Y (code should be self-explanatory)

Architectural anti-patterns

Anti-pattern	Symptom	Solution
God class	File >500 lines	Decompose into modules
Spaghetti	Circular dependencies	Invert dependencies
Anemic domain	Entities without behavior	Enrich domain model
Leaky abstraction	Implementation details exposed	Encapsulate correctly

Critical review checklist

Before considering work as complete:

Mandatory

• No .unwrap() in production
• No f64 for monetary calculations
• Tests pass and are relevant
• Clippy without warnings
• Documentation up to date

Recommended

• Review diff before commit
• Re-read after a break
• Manual test of happy path

Critical report format

After a review, document findings:

## Critical Review - [Feature/Module]

### Positive points
- ...

### Points to improve
- **P0 (blocking)**: ...
- **P1 (important)**: ...
- **P2 (desirable)**: ...

### Technical debt identified
- ...

### Score: X/5

Reference

For an in-depth analysis of the complete project, see: .agent/CRITICAL_ANALYSIS_PROMPT.md