odoo-demo-recording

name	odoo-demo-recording
argument-hint	[flow/feature to record]
description	Record a screen-capture video (MP4/GIF) of one Odoo workflow for a demo, sales walkthrough, or marketing clip - driving the live instance through a scripted click path and saving the result. Capture runs via pagecast/Playwright-video MCP (chrome-devtools drives the path; screenshot→GIF fallback when the recorder is unreachable). Use when the deliverable is a video of a live flow, not a static review or bug hunt. Pushy trigger: fire on "record a demo of this Odoo workflow", "capture a GIF of creating an invoice in Odoo", "capture a short MP4 for the website", "quay video demo Odoo", "tạo video hướng dẫn quy trình". Routing: stitch many scenes / multi-scene walkthrough into one video → odoo-produce-video; RATE how a screen looks → odoo-ui-review; broken screen → odoo-debug; compare two builds → odoo-visual-regression; write frontend code → odoo-coding; code audit → odoo-code-review

Role

Demo/marketing recorder for Odoo. Turn a described workflow into a clean, scripted click path through the live instance and produce a polished video or GIF artifact. Plan the path before recording (which menus, which records, what to type) so the take is smooth and re-runnable.

Out of Scope

• Rating how a screen looks (aesthetic/a11y/performance verdict) → odoo-ui-review
• Diagnosing a broken screen → odoo-debug
• Comparing two builds for visual drift → odoo-visual-regression
• Writing Odoo frontend code → odoo-coding
• Static source-level code audit → odoo-code-review

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. 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.
• find_examples - Semantic code search returning real indexed code snippets from the Odoo codebase.
• model_inspect ★ - Superset inspection of an ORM model: enumerate or fully describe fields, methods, views, extenders, or a summary 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.

OSM use is light here - only to plan the click path: module_inspect(name=<module>, method='views', odoo_version='<version>') tells you which views/menus exist; model_inspect(model=<model>, method='summary', odoo_version='<version>') confirms fields/records the demo will touch; check_module_exists confirms the demo module is installed; find_examples surfaces the canonical flow for the feature.

Browser tools

Chrome-devtools MCP tools drive and record the live instance. Each has a headless default (mcp__plugin_odoo-ai-agents_chrome-devtools__*) and a headed (...chrome-devtools-headed__*) variant - default to headless (recording works headless; only safe choice on no-display hosts); use headed only when the human asks to watch. This skill runs INLINE (call tools yourself, no dispatch brief) - call the -headed tool directly when needed:

• navigate_page - open each step's URL.
• click / fill / fill_form / hover - perform the scripted click path on camera.
• take_screenshot - capture key frames (poster image, GIF frames, or fallback when video unavailable).
• evaluate_script - set up deterministic demo state (e.g. scroll position) between steps.

Video capture is performed by the recording-capable browser MCP (pagecast/Playwright video). pagecast and playwright are OPT-IN - only the headless chrome-devtools is eager (bundled .mcp.json); the recorder families ship no longer eager and must be wired first via /odoo-ai-agents:odoo-setup browser (step 12 for Claude, step 10 for Codex/Gemini). If the recorder MCP is not wired (its tools are absent) or only screenshot capture is available, fall back to a chrome-devtools take_screenshot frame sequence assembled into a GIF.

Workflow

Work in rounds; fire independent calls in the same message within a round.

Round 0 - Load context

context.md is Tier-2 SHARE; resolve it via the resolve-capture-substitute protocol in ${CLAUDE_PLUGIN_ROOT}/snippets/state-root-resolution.md (captured path shown as <SHARE_DIR> below), then read <SHARE_DIR>/context.md (Markdown bullets, - **key**: value format). Extract odoo_version, instance_base_url, instance_login, screenshot_baseline_dir (parent = video output dir).

If a key is missing, fall back to the machine-global $ODOO_AI_HOME/instances.toml (see snippets/instance-resolution.md) for the instance URL. Ask the user only for what none of these resolve (plus the workflow to record, format MP4/GIF, and length) in a single message. Do not guess.

Once odoo_version is resolved, pin it with set_active_version(odoo_version=<concrete>) and pass that concrete version on every Round 1 OSM call - the pin is per-API-key and racy under concurrency; without explicit passing the click path may target the wrong version's view names and URL scheme (/odoo vs /web, which differ by version).

Round 1 - Plan the click path (parallel, OSM)

For the feature to demo, fire in parallel:

• check_module_exists(name=<module>, odoo_version='<version>') - confirm demo module is installed.
• module_inspect(name=<module>, method='views', odoo_version='<version>') - enumerate menus/views the path will visit.
• model_inspect(model=<model>, method='summary', odoo_version='<version>') - confirm fields/records the demo touches.
• find_examples(query='<feature> typical flow Odoo', odoo_version='<version>') - sanity-check the canonical happy path.

Produce an ordered step list (menu → record → field input → action) before recording.

Round 2 - Set up deterministic state (browser)

Log in, navigate to the start screen, and use evaluate_script / fill to put the instance into a clean, repeatable demo state (known record, expanded menu, top of page).

Round 3 - Record the take (browser)

Start the recorder, then drive the planned path with click / fill / fill_form / hover, pausing briefly on key screens. Capture take_screenshot key frames for the poster and as GIF fallback. Stop the recorder by name - stop_recording (pagecast) - then CLOSE the page you drove this round (close_page / browser_close) before moving to Round 4. Both steps are mandatory for EVERY recording round, including a retake. Full rule: ${CLAUDE_PLUGIN_ROOT}/snippets/resource-teardown-contract.md T0/T2.

Round 4 - Produce the artifact

visual/videos/ is Tier-2 ISOLATE; resolve it via the same resolve-capture-substitute protocol (captured path shown as <ISOLATE_DIR> below). Save the MP4 (or GIF) to <ISOLATE_DIR>/visual/videos/<feature>-<timestamp>.{mp4,gif} and report the path, duration, and step list so the take is re-runnable.

Standalone-first fallback

• OSM unreachable: skip Round 1 verification; grep the repo for menu/view ids (grep -rn "<menu_id>" --include=*.xml) to reconstruct the click path from source; only ask the caller to confirm the menu path and records if the grep result is insufficient. Prefix with ⚠ OSM unreachable - click path planned from disk grep, verify menus on the live instance.
• Browser MCP / video recorder unreachable: if video capture is unavailable, fall back to a screenshot frame sequence assembled into a GIF. If the instance itself is unreachable, re-check <SHARE_DIR>/context.md for instance_base_url and instance_login; if still unreachable after trying the URL from context, emit status: NEEDS_NEXT with:

  next:
    - skill: odoo-instance
      reason: provision the Odoo instance needed to record the demo
      inputs: {operation: ensure-up, series: "<series from context>", modules: ["<modules required for workflow>"]}
      confidence: 0.9
      risk_level: L2
  

  so the run-harness provisions one; fall back to BLOCKED(instance unreachable - tried <url>) only if provisioning is itself impossible. Do NOT ask the user for a screen-capture of the flow. Prefix with ⚠ Recorder unreachable - produced frame sequence / GIF only.

Output format

## Demo Recording: <feature workflow> (Odoo v<N>)

### Click path (re-runnable)
1. Navigate <url> → 2. Click <menu> → 3. Fill <field>=<value> → 4. Click <action> …

### Artifact
- File: <ISOLATE_DIR>/visual/videos/<feature>-<timestamp>.mp4 (or .gif)
- Duration: <s> · Resolution: <WxH> · Poster: <screenshot path>

### Notes
<any state setup assumptions, e.g. demo data record used>

Examples (sales order MP4 + portal GIF with recorder unavailable): ${CLAUDE_PLUGIN_ROOT}/skills/odoo-demo-recording/references/examples.md

Notes / Integration

• Videos/GIFs are written under <ISOLATE_DIR>/visual/videos/.
• Use a consistent viewport and login for repeatable takes.
• This skill records flows only; it never edits Odoo source. Hand any needed fix to odoo-coding.

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.