odoo-ai-skills

Customizing or extending a STANDARD Odoo business app — sale (quotation → order → delivery → invoice), stock / inventory (pickings, moves, reservation, lots), account / accounting (invoices, bills, taxes, posting), mrp / manufacturing (BoM, production, components), purchase (RFQ → PO → receipt → bill), or hr (employees, time-off). Use whenever the work touches one of these domains, even if the user doesn't say the word "skill" — any time you'd otherwise GUESS which method to override, which hook builds the next document, or how the sale→stock→account chain fires. Also holds COUNTRY/REGIME playbooks — currently Vietnamese accounting compliance (VAS, TT200→TT99 2026, e-invoice, VAT/CIT calendar, statutory reports). Each app here is a STARTING MAP of the key models, the methods to read first, and the right extension hook — NOT ground truth. Confirm every name against the running instance with the `odoo-introspect` skill before you write a line.

Authoring or customizing Odoo 17/18/19 QWeb reports — the printable PDF/HTML documents (invoices, sale orders, pickings, custom certificates). Use when creating an ir.actions.report, writing or inheriting a QWeb report template, adding a report.<module>.<name> parser to feed extra data, fixing paperformat / margins / page breaks, translating a report per partner language, or debugging "my changes don't show / wrong template / values undefined in the PDF". Don't guess the template id or whether a parser exists — find the existing report with the `odoo-introspect` skill first, then inherit. NOT for the dynamic financial-statement grids under Accounting → Reporting (P&L, balance sheet, tax reports) — those are the `account.report` engine: use `odoo-statutory-reports`.

Entry point and router for doing Odoo development with an AI agent. Start here whenever a task touches an Odoo codebase and you're not sure which specific skill applies — it maps the task to the right one (introspection, models & overrides, module scaffolding, views, OWL frontend, security, testing, reports, data/sequences, migration, deploy, or domain playbooks), even if the user never says the word "skill". The rule shared by every skill in this suite: Odoo composes each model at runtime from the installed addon graph, so READ GROUND TRUTH FROM THE RUNNING INSTANCE FIRST, then build — never guess fields, MRO, super() chains, view arch, or security. Targets Odoo 17/18/19.

Building or customizing DYNAMIC financial statements with Odoo's account.report engine (Enterprise `account_reports`) — P&L, balance sheet, cash-flow, tax reports, and country statutory formats (VAS, HGB, PCG, …). Use when defining account.report / account.report.line / account.report.expression records, choosing an engine (domain / aggregation / account_codes / custom handler), fixing wrong totals or period semantics (date_scope), writing a `_report_custom_engine_*` method, versioning a report for a new accounting regime, verifying a statutory report is complete/balanced, or exporting multi-sheet data packs a grid can't hold. NOT for QWeb PDF documents (invoices, pickings) — that's `odoo-reports`.

Isolated feature development for a LIVE Odoo dev environment using git worktree — build/test on the running instance while committing to a clean branch cut from production, without touching prod or the active dev branch. Use whenever a feature must not land on the current dev/uat branch yet (pending approval/training), when the Odoo container mounts the main working tree (so you can't just switch branches), when syncing changes between a worktree branch and the live working copy, or when packaging ORM-created records into an addon that must install identically on a clean DB (post_init_hook adopt-vs-create + clean-install test ritual).

Migrate Odoo custom modules and databases between major versions, currently specialized for Odoo 18 -> 19. Use this skill WHENEVER the user mentions upgrading Odoo, migrating a module/addon to a new version, "port to 19", version bump, breaking changes between Odoo versions, writing migration scripts (pre/post/end-migrate), OpenUpgrade, upgrade.odoo.com, or fixing a module that fails to install after an upgrade — even if they don't use the word "migration". Also trigger when a traceback clearly comes from version-incompatible code (removed model/field/xmlid, tree->list, _sql_constraints, type='json' routes).

Writing Odoo upgrade/migration scripts — when a module bump needs code beyond what the ORM does on -u, and how to write it. Use whenever renaming a field or model, changing a field's type, backfilling a new required field, merging or moving data, dropping obsolete columns, recomputing a changed stored compute, or asking "will -u handle this automatically or will I lose data?". Covers the migrations/<version>/ pre-/post-/end- layout, the migrate(cr, version) hook, odoo.upgrade.util / openupgradelib helpers, and version bumps. Read the live field inventory from odoo-introspect before assuming a column's name or type.

Shipping data with an Odoo module — XML/CSV data files, seeded records, ir.sequence numbering, and configuration via res.config.settings / ir.config_parameter. Use whenever adding records to data/ or demo/, writing <record>/<field> XML, wiring external IDs (ref/eval/command tuples), setting noupdate, ordering the __manifest__ data list, generating document numbers, or chasing "my edit reverts on -u" / "duplicate seeded record" bugs. Don't guess what's already seeded or whether a record is protected — read ground truth from ir.model.data via odoo-introspect's metadata script first.

Diagnosing a failing Odoo instance — reading tracebacks and server logs, decoding errors (KeyError / "Field does not exist", MissingError, AccessError, ValidationError / UserError, CacheMiss, registry/loading failures, "Invalid view definition" XML errors), turning on dev mode (--dev=all/xml/qweb/reload), dropping into pdb / odoo-bin shell, scoping log output (--log-handler), logging SQL, tracing what actually runs at runtime, capturing runtime VALUES (args/locals/self at a breakpoint + exception post-mortem stack via state_capture), and interactive step-through with debugpy/DAP. Use whenever an Odoo stack trace, failed -i/-u, blank or 500 page, "works locally not in prod", a wrong-at-runtime value, or "why did it raise" shows up, or before you guess which addon or layer caused it. Read the running instance instead of guessing. Targets Odoo 17/18/19.

Running and deploying Odoo — odoo.conf options, odoo-bin flags, multi-worker + reverse-proxy (nginx websockets), Docker/compose, CI test runs, and DB+filestore backup/restore. Use whenever writing or debugging odoo.conf (addons_path, workers, gevent_port, proxy_mode, limits, dbfilter), choosing odoo-bin flags (-c/-d/-i/-u/--stop-after-init/--dev), setting up dev/staging/prod, wiring nginx for longpolling/websockets, dockerizing Odoo + Postgres, running tests in CI, or backing up/restoring. Verify the config the server actually loaded — don't guess which file or flags are in effect.

Customizing or extending Odoo server-side — adding/modifying fields, overriding model methods (create/write/compute/onchange/constrains/unlink), extending core addons, choosing the right inheritance mode, or deciding where an override should land in the MRO. Use whenever working on an Odoo codebase, even if the user doesn't say "skill" — any time you would otherwise GUESS at Odoo's field inventory, ORM API, method resolution order, super() chain, or which hook to extend. Read ground truth first (via the odoo-introspect skill), then make the smallest safe patch and prove it with the odoo-testing gate. Targets Odoo 17/18/19.

Use when: "how does X work in Odoo", "where is Y documented", "Odoo docs for Z", "ORM API reference", "what does this decorator do", "field type options", or any Odoo developer documentation lookup. Builds a local TF-IDF index once from the official odoo/documentation repo; queries it offline, linking canonical odoo.com URLs. Always subordinate to live instance introspection.

Read Odoo ground truth from the running instance BEFORE writing any customization — field inventory, method resolution order (MRO) + super() chain, view/button wiring, security (ACL + record rules), the auto-trigger surface, and the real runtime call graph. Use this FIRST whenever you'd otherwise GUESS at Odoo internals: which fields already exist, what a method's super() chain is, where a form button leads, which record rules apply, what `_get_report_values` feeds a report, or "what actually fires when I confirm this order". Odoo composes each model at runtime from the installed addon dependency graph, so none of this is knowable from memory or source-grep — only from the live registry. Produces four JSON layers via `odoo-bin shell` scripts, or one `odoo-ai all <model>` command; RPC fallback for Odoo Online/SaaS. The foundation every other Odoo skill builds on. Version floor: Odoo 17/18, through Odoo 19 (current LTS).

Creating a new Odoo module/addon from scratch, or fixing a module that won't install — __manifest__.py (depends, the data load order, assets bundles), __init__ wiring, directory layout (models/views/security/data/static/wizard/ report/controllers), and the model + ir.model.access.csv + menu/action/view skeleton that makes a module actually appear. Use whenever scaffolding an Odoo addon, adding the first model to a module, wiring a new .py into __init__, or deciding which addons to `depends` on — even if the user never says "skill". `depends` is not cosmetic: it fixes which MRO layer your overrides land at, so read the recommended depends from the `odoo-introspect` skill (model_brief) before writing it. Never guess the structure.

Building or extending the Odoo 17/18/19 web client — OWL 2 components, custom field widgets (widget="..."), view widgets, client actions, systray items, patching core web components, ORM/notification/dialog/action services, and the assets bundles that load them. Use whenever writing JavaScript/XML under static/src, wiring a widget into a view, or debugging "my component renders nothing / props are undefined / the template isn't found". OWL is where LLM memory is most stale (v16→v17→v18 renamed half the field API) — do NOT write a hook, service, registry category, or field-prop name from memory. Read the real addon source first, then write.

Making Odoo fast — recordset hygiene (no query-in-loop, search-once-with-in, mapped/filtered/sorted), the ORM cache & prefetching, stored vs non-stored computed fields (write amplification, exhaustive @api.depends), database indexes (index=True and typed indexes), _read_group aggregation, batch create/write, and justified raw SQL with correct cache invalidation. Use whenever an Odoo page/list/report/cron is slow, an N+1 query pattern appears, you're about to add store=True or an index, or you're writing a loop that search()es or browses one record at a time. Measure real SQL counts from the running instance — don't guess. Targets Odoo 17/18/19.

Reviewing Odoo code before it merges — your own AI-generated patch or someone else's PR. Use after writing or generating an Odoo change and before commit, or when asked to review/audit an Odoo module, diff, or addon. Catches the Odoo-specific defects AI confidently ships that lint and "it ran for me as admin" miss: blanket sudo() / privilege bypass, missing ACL or record rules, N+1 recordset loops, incomplete @api.depends on stored computes, patching core instead of a separate addon, wrong inheritance mode / MRO layer, deprecated v≤16 syntax (attrs/states/<tree>/name_get), guessed field & method names, unwired __init__ / manifest, data-loss-on-upgrade renames, and public routes with the wrong auth. Pairs with odoo-testing (review finds it, tests prove it). Read ground truth from the running instance to confirm a suspicion — don't guess whether a field or rule exists. Targets Odoo 17/18/19.

Authoring or debugging Odoo access control — ACL (ir.model.access.csv), record rules (ir.rule), groups (res.groups + implied_ids), field-level groups, sudo(), with_user / with_company, and multi-company row isolation. Use whenever a change "works for admin but fails for a normal user", an AccessError or "you are not allowed to" appears, a new model needs permissions, you're about to reach for sudo(), or you'd otherwise GUESS which groups grant what or why a user sees too many / too few rows. Effective access is composed at runtime from every installed addon — read the real ACL + rule dossier first, never guess. Targets Odoo 17/18/19.

Proving an Odoo customization works before merge — writing and running Python tests for models, method overrides, computed fields, onchange, constraints, security, and cross-addon flows. Use after any server-side change (new field, overridden create/write, compute/constrains, ACL or record-rule edit) and when deciding the base class, at_install vs post_install tags, or how to test non-admin / multi-company / batch / onchange behavior. A patch isn't done until a test fails before it and passes after. The test gate for the odoo-dev skill. Targets Odoo 17/18/19.

Authoring or editing Odoo view XML — form, list, kanban, search, pivot, graph, calendar, activity, gantt — and view inheritance (inherit_id, xpath, position, <attribute>). Use whenever writing a view, adding a field/button/page/filter to an existing view, fixing field visibility, or migrating old view XML, even if the user never says "skill". Covers the v17/18 breaking syntax LLMs get wrong: `attrs` and `states` are REMOVED — use direct `invisible=` / `readonly=` / `required=` / `column_invisible=` with Python expressions; the list root is `<list>` (was `<tree>`); chatter is `<chatter/>`. Before editing any view, dump the inheritance-resolved arch + existing buttons/modifiers with the `odoo-introspect` skill (entrypoints) so your xpath targets actually exist — a wrong xpath fails silently.

Building Odoo 17/18 PUBLIC web — HTTP controllers (http.route), the website (pages, QWeb website templates, snippets), the portal (/my, document access), and frontend interactivity. Use whenever writing anything under controllers/, a route an external system or browser hits, a website page/template, a portal document view, or public JS in web.assets_frontend — even if the user never says "skill". This is the PUBLIC frontend (controllers + website + portal + the v17/18 publicWidget→Interactions shift), distinct from the backend web client (that's odoo-owl). Routes run with real auth and CSRF and against real record rules — read the wiring and security from the running instance first, never guess the route, the template id, or who can reach it. Targets Odoo 17/18/19.

Use when the user wants END-USER usage documentation / how-to guides for an Odoo flow — "viết hướng dẫn sử dụng", "tạo tài liệu hướng dẫn cho nhân viên", "làm guide thao tác", "document how to <do X> in Odoo", "screenshot/step-by-step guide", "user manual cho luồng <model>". The AGENT drives the real Odoo UI live through an MCP browser tool (claude-in-chrome / Playwright MCP) — observing each page semantically (accessibility tree), clicking by visible label, screenshotting and narrating — grounded by Odoo metadata + RPC so it stays correct, and proven by reading the resulting state at the backend. Then it renders a Markdown guide (guide.md + screenshots/, or self-contained HTML). Deterministic, ground-truth-first, re-runnable — NOT a blind hand-written selector script. Default: dev/UAT (sandbox) db. NOT for QWeb PDF business documents — that is odoo-reports.

Produce a report, analysis, audit, RCA, review, or summary as a standalone HTML file with ONE consistent design. Use whenever the user asks for output "as HTML" / "report html" / "bằng html" / "làm report html" / "xuất báo cáo html" / "báo cáo html", or wants an audit/review/analysis/findings rendered as a shareable HTML page instead of plain markdown. It standardizes presentation only — you still write the content. NOT for Odoo QWeb PDF/HTML business documents (invoices, pickings, certificates) — that is the `odoo-reports` skill. This is the local-tooling report layout for findings and write-ups.

Check what Odoo ALREADY ships natively BEFORE writing any custom code — the step that comes before introspection. Use whenever a task would add a field, model, wizard, report, scheduled job (cron), or automation, or would override a core flow method — any time you'd otherwise reinvent something Odoo provides out of the box (auto-numbering → ir.sequence; periodic job → ir.cron; react-to-change → automation rule / computed field; audit log / reminders → mail.thread / activities; "create the invoice/payment" → an existing wizard). Describe the requirement to `odoo-ai native-check "<requirement>"` — it matches curated capability cards and existence-gates them against the live instance (returning candidates with cited evidence) — or enumerate the full native surface with `odoo-ai capabilities <model>` / `--module <addon>` (wizards, actions, crons, automations, sequences, mixins, feature groups, fields). So the agent reuses native Odoo instead of building custom. Pairs with `odoo-introspect` (which answers "where d