Odoo native capabilities — discover before you customize

The suite's whole rule is read ground truth from the running instance, don't guess. This skill applies that rule one step earlier than the rest: before asking "where do I extend?", ask "should I extend at all, or does Odoo already do this?"

Odoo is enormous. Huge amounts of business behavior already ship as native primitives — sequences, scheduled actions, automation rules, mail/activity mixins, transient-model wizards, computed fields, feature groups — scattered across installed addons. Left to memory, an AI agent reinvents them: a max(x)+1 numberer instead of ir.sequence, a write() override for a side-effect instead of an automation rule or computed field, a custom audit-log model instead of mail.thread. The result is more code, more bugs, and a fight with the platform on every upgrade.

The move: enumerate the native surface from the live registry, reuse what fits, and only then customize the gap.

Native first → introspect → plan → code

This is Step 0 of the suite's workflow. It does not replace odoo-introspect — it precedes it.

0. native-check   (this skill)  — does Odoo already ship this? what's the native surface here?
1. introspect     (odoo-introspect) — for the gap you DO build: fields, MRO, super(), security, trace
2. plan the smallest extension at the right hook
3. code → 4. test → 5. review