End-to-end OCA module migration workflow for porting addons between Odoo major versions and preparing [MIG] pull requests. Use when migrating OCA modules, porting addons between Odoo versions, applying OCA migration checklists, resolving migration patch conflicts, or preparing versioned OCA migration PRs.
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
Use this skill for OCA module migration between Odoo major versions. Compose
with odoo-report-migration when the module contains QWeb/PDF reports whose
visual output must be preserved.
This is not an OpenUpgrade skill. Do not adopt the OpenUpgrade operating model, its commands, or its workflow for a normal OCA [MIG] port. Consulting OpenUpgrade's upgrade_analysis.txt for core-module data-model changes IS part of the OCA protocol, because the version guides deliberately cover framework changes only and point there for data-model deltas. If a migration requires project-specific data handling, inspect the addon and repo conventions directly.
Identify:
If the Odoo framework source or local development setup is needed and not inside the workspace, ask the user to set ODOO_SOURCE=/path/to/odoo, ODOO_BASE_COMMAND="...", and ODOO_TOOL_README=/path/to/README.md as needed.
Use OCA-MODULE-MIGRATION.md as the end-to-end guide.
Always apply every intermediate version checklist for jumps across more than one major version. Examples: migrating 15.0 to 18.0 requires the 16.0, 17.0, and 18.0 sections; migrating 18.0 to 20.0 requires the 19.0 and 20.0 sections.
Before creating a migration branch, verify that the OCA repository exposes the target branch and that the related migration issue or PR context is known. Odoo 20 support in this skill remains the normal OCA migration workflow, not OpenUpgrade.
The OCA protocol opens with a preamble: refresh the OCA conventions, subscribe to the project's mailing list, announce the module(s) on the Migration to version <target> issue, and install pre-commit. The issue announcement is the documented OCA step.
The migration is not done at the final commit. It reaches OCA when the branch is pushed to the contributor's fork and the pull request is opened with the [<target>][MIG] <module>: Migration to <target> title. See OCA-MODULE-MIGRATION.md for the fork, push, and pull request mechanics.
$ODOO_TOOL_README, or $ODOO_BASE_COMMAND, and confirmed by the user.git filter-branch or git filter-repo without explicit user approval, even when the module rename makes them the correct move.--no-verify except for the OCA-documented first mechanical-formatting commit, and only after confirming that exception with the user.[<target>][MIG] <module>: Migration to <target>.No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when the user wants to stress-test a plan, get grilled on their design, or mentions "grill me" outside an Odoo-specific context.
The English summary is being prepared. Showing the original description.
Grilling session that challenges your plan against the existing domain model, sharpens terminology, and updates documentation (CONTEXT.md, ADRs) inline as decisions crystallise. Use when the user wants to stress-test a plan against their project's language and documented decisions.
The English summary is being prepared. Showing the original description.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
The English summary is being prepared. Showing the original description.
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.
The English summary is being prepared. Showing the original description.
Odoo 17 development reference for Python models and ORM (search, domain, read_group, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups), cron and server actions, migrations and module upgrades, tests, i18n, and performance. Use this skill whenever work involves Odoo 17 or custom addons, including traceback diagnosis, addons, manifests, XML errors, HTTP controllers, business rules, feature work, refactoring, or reviews.
The English summary is being prepared. Showing the original description.
Odoo 18 development reference for Python models and ORM (search, domain, read_group, compute fields), XML/CSV data and views, OWL/JS client code, QWeb reports, security (ACL, record rules, groups), cron and server actions, migrations and module upgrades, tests, i18n, and performance. Use this skill whenever work involves Odoo 18 or custom addons, including traceback diagnosis, addons, manifests, XML errors, HTTP controllers, business rules, feature work, refactoring, or reviews.
The English summary is being prepared. Showing the original description.