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