Odoo
Agent skills for Odoo addon development and OCA module migration
npx -y skills add mart337i/odoo-skills --skill odooAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
- 16 stars16 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Odoo engineering workflows for addon development, codebase exploration, debugging, architecture/refactor review, manifest/docs sync, and routing to migration work. Use when the user mentions Odoo, addons, modules, manifests, models, XML views, security CSVs, record rules, Odoo shell, OWL/QWeb/assets, or when an Odoo codebase is detected.
SKILL.md
2.8 KB, as published. Nobody here has run it
Odoo
Use this skill only for Odoo work. For OCA module migration or major-version addon ports, route to odoo-migration.
First Move
Explore before asking. Inspect the repo for Odoo signals: __manifest__.py, odoo-bin, addons/, models/, views/, security/ir.model.access.csv, controllers/, static/src/, and project docs.
Before version-sensitive changes, detect the target Odoo version from branch names, manifests, docs, dependencies, or config. If the version is not discoverable, ask. If $ODOO_SOURCE is set, inspect it for framework behavior instead of guessing.
Before running Odoo update/test commands, inspect likely commands from repo docs/config. If $ODOO_TOOL_README is set, read it for local tooling. If $ODOO_BASE_COMMAND is set, use it as the starting point for proposed Odoo commands. Then ask the user to confirm before running commands that touch a database or local service.
Route The Task
- Stress-test an Odoo plan/design before implementation: use
odoo-grill-me. - Build or change addon behavior: use DEVELOPMENT.md.
- Understand an unfamiliar Odoo codebase: use EXPLORATION.md.
- Debug broken Odoo behavior: use DEBUGGING.md.
- Trace a concrete execution path through controllers, buttons, cron jobs, model methods, overrides, computes, onchanges, constraints, or side effects: use
odoo-code-tracer. - Hunt for Odoo architecture/refactor opportunities: use ARCHITECTURE.md.
- Sync manifest/docs with implemented behavior: use MANIFEST-DOCS.md.
- Build, review, debug, or migrate Odoo OWL frontend components: use
odoo-owl. - Review Odoo code for correctness, security, performance, tests, migrations, manifests, and official coding guidelines: use
odoo-code-review. - Create or improve Odoo tests using TransactionCase, HttpCase, Form helper, tags, mocks, access tests, workflow tests, or test coverage patterns: use
odoo-test-writer. - Migrate an OCA addon between Odoo major versions: use
odoo-migration. - Need detailed known-version guidance: use
odoo-17.0,odoo-18.0, orodoo-19.0.
Always Apply
Use the compact conventions in CONVENTIONS.md. Keep changes small and idiomatic. Include a security pass when models, views, controllers, workflows, or access behavior change. For business data modules, lightly check multi-company behavior: company_id, defaults, domains, record rules, and cross-company reads/writes.