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

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:

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

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