Review Odoo code for correctness, security, performance, and version-specific standards (Odoo 16, 17, 18, or 19). Use when reviewing Odoo modules, diffs, or pull requests; produce a scored report with weighted criteria.
Installation
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Review Odoo code for correctness, security, performance, and version-specific standards (Odoo 16, 17, 18, or 19). Use when reviewing Odoo modules, diffs, or pull requests; produce a scored report with weighted criteria.
Odoo Code Review
Objective
Review Odoo code changes against clear criteria, identify risks, and score using a weighted scale from an Odoo-expert perspective — using the reference pack that matches the target Odoo version.
Resolve the target Odoo version
Before reviewing, resolve ODOO_VERSION (one of 16.0, 17.0, 18.0, 19.0) in this order. Stop at the first one that succeeds:
Explicit argument passed to the agent invocation (e.g. odoo_version: "19.0").
Project config, in this order:
.odoo-version file at the repo root (contents: e.g. 19.0).
odoo_version key in .claude/odoo.json.
odoo.version key in package.json or tool.odoo.version in pyproject.toml.
Manifest heuristic — scan workspace __manifest__.py files for the 'version' key. Use the dominant major version (e.g. 18.0.1.0.0 → 18.0).
Fallback — default to 19.0 (latest supported) and note the assumption in the review output so the user can correct it.
Derive ODOO_MAJOR from ODOO_VERSION by stripping .0 (e.g. 18.0 → 18). All guide paths below use these placeholders.
Supported versions: 16.0, 17.0, 18.0, 19.0. If resolution yields anything else, stop and tell the user the version is out of scope.
Pre-review Requirements
Read skills/odoo-${ODOO_VERSION}/SKILL.md as the master index for the resolved version's guides.
Read skills/odoo-${ODOO_VERSION}/references/api-highlights.md for the version-distinguishing rules (what changed, what to flag, what's allowed).
Read relevant guides from skills/odoo-${ODOO_VERSION}/references/ based on change scope:
Rules below are version-neutral unless they reference api-highlights.md. Always combine this checklist with the version-specific highlights for the resolved ODOO_VERSION.
ORM & Model Methods (30%)
❌ DO NOT use search() inside a loop (N+1 anti-pattern)
✅ Use search_read() when dict output needed
✅ Use read_group() for aggregate queries
✅ Use IN domain instead of search in loop: [('order_id', 'in', orders.ids)]
✅ Batch create([{...}, {...}]) for multiple records
✅ Use recordset.write() instead of loop
✅ Use recordset.unlink() instead of loop
✅ @api.model_create_multi on create() overrides (see api-highlights.md for version-specific enforcement)
Views & XML (15%)
Use the list tag appropriate to ODOO_VERSION (see api-highlights.md: <tree> in 16/17, <list> in 18+).
Use the attrs syntax appropriate to ODOO_VERSION: legacy attrs= / states= are valid in 16, but rejected in 17+ where direct expressions are required.
Inheritance via xpath / position — the nested list tag must match the version.
Avoid duplicate name= attributes in records.
Fields (15%)
Monetary with currency_field
Many2one with ondelete
Computed field with store=True if filtered/searched
Aggregation parameter: group_operator= (v16/17) vs aggregator= (v18+) — see api-highlights.md.
Decorators (10%)
@api.depends with complete dotted paths
@api.constrains for invariants
@api.ondelete(at_uninstall=False) instead of overriding unlink() for validation
@api.model_create_multi for batch create
Performance (10%)
Avoid N+1 in loops
Prefer read_group() / search_read() over per-record fetches
Use prefetch_fields thoughtfully
Transactions (5%)
savepoint around recoverable failures
Handle UniqueViolation explicitly
Advisory locks for cross-record serialization
Security (5%)
Specific exceptions: UserError, ValidationError, AccessError
No bare except Exception
sudo() used narrowly with justification
Controllers (3%)
Correct auth= (user, public, none)
csrf=False only with justification
type='json' vs type='http' matches the client
Mixins (3%)
mail.thread with proper tracking fields
mail.activity.mixin for activities
mail.alias.mixin with alias fields
Testing (2%)
Tests for new functionality
Proper use of @tagged
Query count assertions for hot paths
Manifest & Data (2%)
All dependencies declared
External deps listed
Hooks wired correctly
noupdate="1" for reference data
Scoring
Weight each section per the percentages above. Total out of 100. Report:
Score per section with brief justification.
Blocking issues (must fix before merge).
Non-blocking suggestions.
Explicitly name the resolved ODOO_VERSION at the top of the report.
Deep Dive Checks
When reviewing, thoroughly check (references below use ${ODOO_MAJOR} — substitute the resolved value):
Does @api.depends have complete dependencies?
Check dotted paths: partner_id.email instead of just partner_id
