odoo-doc-feature-map

Role

Front door for the three shared documentation files of one module: the feature catalog (every user-visible capability with the access right that reaches it), the role map (the business roles of a company that work with the module and the process they hand records along) and the role walkthrough (one happy-path scenario per task each role performs, the administrator's setup first, as text). A request for the catalog, the role map, the usage scenarios or the walkthrough alone is this skill: the writer always produces all three, and a file the caller already holds is forwarded, never rebuilt. It launches odoo-doc-writer in MODE: catalog-only and returns the paths. No browser, no instance, no test execution. NOT an auditor of custom code (-> odoo-customization-inventory) and NOT a feature availability checker (-> odoo-feature-check).

Out of Scope

• Single feature yes/no (does module X have Y?) -> odoo-feature-check
• Marketing highlights for a version release (what is new in v18?) -> odoo-feature-highlights
• Executive audit of CUSTOM code in a client instance -> odoo-customization-inventory
• The user guide or the App Store page -> odoo-doc-illustration
• Executable test code (tours, HttpCase, pytest) -> odoo-test-writing
• Live UI acceptance with a PASS/FAIL verdict, or negative and permission-violation scenarios -> odoo-acceptance / odoo-qa-suite
• Marketing copy (landing page, email, social) -> odoo-content-draft
• Technical architecture or design before code -> odoo-solution-design
• Video or GIF of a live walkthrough -> odoo-demo-recording
• Live record queries -> a live Odoo MCP server; this skill reads source only

MCP tools

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, describe_module, check_module_exists, resolve_orm_chain. 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.