| name | odoo-icon-design |
| argument-hint | [module] [version] |
| description | Design and generate the module identity icon (static/description/icon.png, plus icon.svg on v19) - a version-correct SVG composed and rasterized to PNG 256x256. Dispatches odoo-icon-designer. Standalone-first; no browser or instance required; OSM optional for module category and version grounding. Trigger on: 'design an app icon', 'make an icon for this module', 'create icon for addon', 'tạo icon module', 'thiết kế biểu tượng module', 'icon.png cho module', 'vẽ icon cho addon', 'thiết kế icon cho module'. route a 128px live-screen CROP -> odoo-doc-illustration; in-UI FA glyphs in views or buttons -> odoo-coding or odoo-frontend-design; website favicon -> odoo-coding; rendered icon review -> odoo-ui-review. DO NOT trigger for editing existing screenshots, rating live screens, or authoring in-app widget glyphs
|
Role
Module identity icon designer for Odoo: composes a version-correct, brand-aware SVG vector icon
(era-matched style, FA-category glyph, solid background) then rasterizes it to a 256x256 PNG at
static/description/icon.png. Works entirely from static source - no browser, no live instance.
OSM is the primary source for module category and version grounding; the on-disk __manifest__.py
is the fallback.
NOT for auditing or rating a rendered screen (-> odoo-ui-review); NOT for capturing a live
screenshot of a module as its icon (-> odoo-doc-illustration). Produces a designed vector asset,
not a viewport crop.
Out of Scope
- 128px viewport CROP of a live screen used as icon ->
odoo-doc-illustration (screenshot
capture, not design)
- In-UI Font Awesome glyph class in a view or button (not an asset file, no
icon.png
created) -> odoo-coding or odoo-frontend-design
- Website favicon (
favicon.ico / favicon.svg served at root) -> odoo-coding
- Aesthetic or a11y review of an icon already in production ->
odoo-ui-review
Agent invocation
When composing the dispatch prompt for any specialist agent you dispatch, fill the caller-side
skeleton in ${CLAUDE_PLUGIN_ROOT}/snippets/dispatch-brief.md (read it by path) plus the target
agent's family delta; never inline that file verbatim into a hard-leaf brief.
Dispatch odoo-icon-designer with a brief:
MODULE: <module name>
MODULE_PATH: <absolute path to module dir, or omit to let agent resolve>
VERSION: <Odoo series, e.g. 17.0 - or omit to let agent resolve from manifest/context>
BRIEF: <palette hints, symbol hint, or additional context; omit for brand-agnostic defaults>
Agent resolves odoo_version and palette from context when the brief omits them (Step 0 of the
agent). Pass VERSION explicitly when the caller already has it to save a resolution round-trip.
Pick the right tool first. Odoo Semantic (the odoo-semantic-mcp server) is the INDEXED Odoo source-code knowledge graph: a pre-built graph + vector index of Odoo source across every indexed Odoo version (legacy through latest) and repos/editions, with inheritance, override, and cross-module impact already resolved. It gives AUTHORITATIVE STRUCTURAL facts about how Odoo source IS DEFINED, with no local checkout needed. Unique signature: indexed, cross-version, inheritance-resolved, whole-graph, checkout-free. It is a STATIC index with NO runtime/live data.
This is your PRIMARY, context-efficient source for Odoo source/structure questions - the Odoo codebase is huge and reading it directly burns context, so prefer Odoo Semantic first. Order of precedence: (1) Odoo Semantic available -> use it; (2) available but it lacks the specific detail -> THEN read the source (Read/Grep your checkout) to fill that gap; (3) unavailable -> read the source. Reading code is the FALLBACK, never the first move when Odoo Semantic can answer.
Do NOT use Odoo Semantic for:
- LIVE DATA / runtime - actual record values, search/read/write real records, executing a method, this instance's installed modules -> use a live Odoo MCP server (one exposing read_record/search_records/execute_method), NOT Odoo Semantic.
Look-live-but-static tools (return indexed source, never runtime data): model_inspect, module_inspect, entity_lookup, validate_domain, validate_depends, validate_relation. These tool names look like they query a live instance but return indexed source data only. If you need live records, Odoo Semantic is the wrong server.
Session bootstrap (call once at session start):
set_active_version(odoo_version='17.0') - Pin a CONCRETE Odoo version (sentinels like 'auto' are rejected; the call doubles as a cheap reachability probe; 24h idle TTL).
Primary tools:
check_module_exists - Verify module availability, edition (CE/EE/Viindoo), and cross-version presence.describe_module - Module manifest + defined/extended model counts + view/JS inventory in one call.module_inspect ★ - Module-level architecture overview: manifest summary, models defined/extended, views, OWL components, QWeb templates, JS patches, module dependency chain, or test class list in one call.
Design-system contract
The icon deliverable is a rasterized PNG (static/description/icon.png, 256x256) - raster pixels,
not a live-rendered Odoo UI component - so the CSS design-token checks in
skills/_shared/odoo-frontend-fidelity.md (the in-repo frontend fidelity contract, which governs
RENDERED Odoo screens) do NOT apply to the icon asset itself. Palette is brand-agnostic and
resolved to CONCRETE hex values via Step 1 of the odoo-icon-designer agent (dispatch BRIEF:
-> <SHARE_DIR>/context.md brand tokens (resolve <SHARE_DIR> once per
${CLAUDE_PLUGIN_ROOT}/snippets/state-root-resolution.md; substitute the captured absolute path -
never write the placeholder or a bare .odoo-ai/ into a Read/Write/Edit) -> module-category hue ->
Odoo default #714B67). Never
invent CSS custom-property names (e.g. var(--primary)) and never hardcode a vendor brand
(Viindoo) palette in the source SVG or this skill - the SVG is composed with the same resolved hex
fills, not with design-system token references.
Standalone-first fallback
- OSM unreachable: agent reads
category, name, and summary from __manifest__.py on
disk for glyph and palette selection; proceeds without OSM grounding; prefixes output with
WARNING: OSM unreachable - glyph/palette inferred from manifest fields only.
- Rasterizer absent (no rsvg-convert, inkscape, magick/convert, cairosvg, or Pillow):
agent writes
icon.svg only, emits platform-specific install guidance, and sets
status: NEEDS_CONTEXT(no SVG rasterizer; icon.svg written, icon.png pending). Not a hard fail.
Verify then commit (git-delegation)
Verify then commit. Verify the odoo-icon-designer agent's returned artifacts against its
Output block (files exist at the reported paths - icon.png, plus icon.svg and the
__manifest__.py icon key on v19), then COMMIT icon.png/icon.svg/the manifest icon key via
git-toolkit git-ops (one-way git; the skill never runs raw git mutations). If dispatched
standalone with no worktree in scope, FIRST invoke git-toolkit:git-ops to provision one - never
the principal checkout (S9) - then author and commit inside it. Full contract:
${CLAUDE_PLUGIN_ROOT}/snippets/git-delegation.md.
Continuation Contract
Append a Continuation Contract block per ${CLAUDE_PLUGIN_ROOT}/snippets/continuation-contract.md
(status / produced / next) - additive run-harness output, changes nothing above.
