Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/codeforusers/odoo-dev-superskill/migration-behaviorgit clone --depth 1 https://github.com/CodeForUsers/odoo-dev-superskillWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00000 | $0.00476 |
| Opus 5 | $0.00000 | $0.00238 |
| Sonnet 5 | $0.00000 | $0.00095 |
| Haiku 4.5 | $0.00000 | $0.00048 |
Grade A, and why
migration-behavior scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 51 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Migration Behavior
Purpose
Define how the agent should behave when migrating an Odoo module between versions, especially across 16.0, 17.0, 18.0 and 19.0.
When to activate
- The user mentions migration.
- The task involves deprecated syntax.
- The task includes adapting legacy views, ORM APIs, assets, or manifest behavior.
- A module created for an older version must run on a newer Odoo release.
Pre-checks
- Identify source version and target version.
- Inspect manifest version.
- Locate deprecated XML syntax (
attrs,states,<tree>where relevant, old assets patterns, etc.). - Check whether OWL, web assets, JS patches, or controllers are involved.
- Determine whether tests exist and whether they need version-specific adaptation.
Workflow
- Detect current version and target version.
- Build a migration checklist specific to that jump.
- Inspect XML views first, then Python ORM/API changes, then assets/frontend code.
- Replace deprecated patterns using the version matrix.
- Keep changes minimal and traceable.
- Re-run consistency checks after each migration block.
- Update tests and manifests to reflect the new version.
- Flag unclear cases instead of hallucinating a migration rule.
Rules
- Never assume migration rules without version evidence.
- Prefer explicit before/after transformations.
- Keep backward compatibility only if explicitly requested.
- Treat view migrations and ORM migrations as separate passes.
- Preserve business logic unless migration requires changes.
Avoid
- Mixing source and target syntax.
- Rewriting working logic unnecessarily.
- Applying mass changes without checking side effects.
- Ignoring XML inheritance breakage after syntax migration.
- Updating version numbers without adapting code.
Tooling integration (Optional)
- Codegraph: Use
codegraph_exploreto find Odoo core methods (or custom overrides) that have changed signature between versions. Inspect inheritance overrides to ensure compatibility after migration. - Engram: Retrieve previous version migration decisions, framework bugfixes, or manual resolution recipes using
mem_search. Save newly discovered migration guidelines or custom porting patterns usingmem_save.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 51 lines · 0 tokens per session scan A ce4a863310d4
migration-behavior is an agent published in the GitHub repository CodeForUsers/odoo-dev-superskill (11 stars, last pushed 1mo ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 476 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
debugger
Debugging specialist for errors and test failures. Use when encountering build errors, runtime exceptions, test failures, or unexpected behavior. Invoke with /debugger to investigate issues.
verifier
Validates completed work. Use after tasks are marked done to confirm implementations are functional. Invoke with /verifier when you need to verify code actually works.
ijfw-assumptions-analyzer
Use when surfacing hidden assumptions in a brief or plan before execution begins -- what does the plan assume that the spec doesn't guarantee?
ijfw-accessibility-reviewer
Design-phase WCAG 2.1 AA review of UI artefacts: contrast, semantics, focus, ARIA. Trigger per design review pass.
refactor
Use when code has grown complex, has duplication, violates patterns, or needs restructuring - from code smells to architecture-level refactoring.
marketing
Use when creating marketing copy, landing pages, email campaigns, social media strategy, SEO content, or growth experiments.