Develop Custom Odoo Modules

Turns the assistant into an Odoo custom-module developer covering both Community and Enterprise editions: scaffolding a new module's full folder structure, defining models with correct field types and inheritance, setting up access security, and reviewing pasted code against Odoo conventions. It follows a fixed three-step process: Activate, where the user mentions @odoo-module-developer and describes the module to build; Scaffold, which produces the full folder structure covering __manifest__.py, __init__.py, models, views, and security files; and Review, where the user pastes existing code and gets it checked against Odoo best practices. It walks through a worked example scaffolding a hospital_management module with a hospital.patient model that inherits mail.thread/mail.activity.mixin, complete with a __manifest__.py declaring the Healthcare category, a depends list of base and mail, an LGPL-3 license, and the security/view files registered under data, plus a model file defining a required, chatter-tracked name Char field, a birth_date Date field, a doctor_id Many2one pointing at res.users, and a state Selection field with three named states (draft/New, confirmed/Confirmed, done/Done) defaulting to draft. It documents seven best practices - namespace-prefixed model names, _inherit = ['mail.thread'] for chatter, versioning as {odoo_version}.{major}.{minor}.{patch}, setting author/website in the manifest, never modifying core model files directly, always registering new models in ir.model.access.csv, and using snake_case module folder names - plus four explicit scope limits.

Use it when starting a new custom Odoo module from scratch, extending an existing Odoo model such as adding fields to sale.order, troubleshooting module loading or manifest errors, or implementing onchange, compute, or constraint methods correctly. It does not cover OWL JavaScript components or frontend widget development, routing those to a separate @odoo-xml-views-builder skill, does not generate automated test files, routing those to @odoo-automated-tests, does not cover multi-company or multi-website configuration, and targets Odoo v14 and above - Odoo 13 and below use a different module-loading structure without __manifest__.py auto-loading.

Input is a description of the module or model to build, or existing module code to review. Output is a complete module folder structure with manifest, models, views, and security files, or a best-practices review of pasted code:

hospital_management/
├── __manifest__.py
├── __init__.py
├── models/
│   ├── __init__.py
│   └── hospital_patient.py
├── views/
│   └── hospital_patient_views.xml
├── security/
│   ├── ir.model.access.csv
│   └── security.xml
└── data/

Built for the Odoo framework (odoo.models, odoo.fields, odoo.api), specifically its mail.thread/mail.activity.mixin chatter mixins and ir.model.access.csv security model; complements two sibling skills, @odoo-xml-views-builder for frontend view XML and @odoo-automated-tests for test generation.

Developers building or extending custom Odoo modules for Community or Enterprise deployments who need scaffolding, model definitions, and security setup that follow Odoo's own conventions.