callista-odoo-demo/SKILL.md

---

name: odoo-demo-architect description: Build a complete, client-tailored Odoo demo from a discovery call. Mines the client's pains, researches native-vs-custom for each hero feature, stands up a LIVE Odoo database (modules + realistic data + working hero features) over XML-RPC, tests it, and generates the sales docs (run-of-show, one-pager, step-by-step script). Use when prepping an Odoo sales demo, POC, or proof-of-value before a client meeting. Triggers: "build an Odoo demo", "demo DB for ", "Odoo proof of concept", "stand up a demo before the meeting".

Odoo Demo Architect

Turn a discovery call into a polished, working Odoo demo + the documents to sell it — end to end, with minimal human steering. Built from a real engagement that won on first showing.

What it produces

1. A live Odoo database with the client's modules installed, realistic industry data, and the 1–2 "hero" features that map to their pain — actually working, not slideware.
2. Three sales documents (brand-themed, self-contained HTML): a run-of-show, a one-pager for the decision-maker, and a 1-page step-by-step demo script.
3. A verification log proving each hero feature fired (e.g. "credit block raised at 56,379 > 50,000; override confirmed").

Inputs you need before starting

• Discovery material — a call transcript, recording, or notes describing the client's business + pains. (If using Knowcap, pull the transcript first.)
• Agreed scope — which Odoo areas are in Phase 1 (Sales, Inventory, Accounting, Fleet, etc.).
• A reachable Odoo instance + credentials — URL, DB, login, and an API key (Settings → My Profile → Account Security → New API Key). Works on Odoo Online, self-hosted, or Odoo.sh.
  • Odoo.sh note: create the project + enter any partner trial code FIRST (web UI only — no API for project creation). Then proceed here once the DB is up and you have an API key.

The pipeline (run in order)

1. Mine the discovery

From the transcript/notes, extract and write down:

• The business shape (entities, what they sell, who they sell to). Watch for "it's a group" that is really ONE company in Odoo — confirm chart-of-accounts/P&L/warehouse are shared.
• The top 3–5 pains in the client's own words (quote them). These become the demo beats.
• The 1–2 hero features — the differentiators that justify the spend. Everything else is supporting flow.

2. Research native-vs-custom (don't assume)

For EACH hero feature, verify whether Odoo does it natively, no-code, or needs custom code — for the client's exact Odoo version. Use the Perplexity MCP (perplexity_ask) or web search. Ask precisely, e.g. "In Odoo , is there a native hard-block (not warning) on SO confirmation over credit limit?" Capture the verdict + citations. This step repeatedly overturns assumptions (e.g. credit limit is warning-only natively; v19 fleet dispatch IS native but only via stock_fleet).

3. Connect (XML-RPC)

Use scripts/odoo_connect.py. Authenticate, print server_version to confirm the major version (field names differ across versions — see reference/odoo19-field-gotchas.md). All build steps go through the x(model, method, *args, **kwargs) helper.

4. Install modules for the scope

button_immediate_install on the ir.module.module ids. Common set: sale_management, stock, account_accountant, stock_delivery, stock_picking_batch, fleet, web_studio, base_automation, contacts. For fleet load-by-weight on v19 also install stock_fleet (Stock Transport — adds vehicle capacity + batch dispatch). Module installs are heavy; allow several minutes.

5. Generate + load realistic demo data

Industry-appropriate, minimal but believable. Drive it from a demo_config.json (see demo_config.example.json) and scripts/build_demo.py. Rules:

• Get-or-create by name so re-runs are idempotent.
• Set the right currency first (activate it with context={'active_test': False}, set on res.company) — BEFORE posting any invoices (currency can't change once journal entries exist).
• Give products a weight if fleet is in scope. Give customers credit limits (use_partner_credit_limit=True, credit_limit=...) if credit is in scope.
• Pre-stage state to make heroes fire live: e.g. post an unpaid invoice to put a customer's receivable JUST under their limit, so a live order tips them over. Keep one demo quotation in draft for the live click.
• Seed stock with inventory_mode context so deliveries can reserve (go Ready).

6. Build the hero features — no-code first, module as fallback

• Prefer no-code: server actions / automated rules (base.automation) / Studio. Portable to any Odoo, no deploy.
• Custom module only if needed: generate a minimal module, push to the instance's git (Odoo.sh) or hand it to the user to deploy, then install + test. Keep modules tiny and version-correct.
• Example hero (credit hard-block + manager override): override sale.order.action_confirm to raise UserError when partner.credit + amount_total > credit_limit unless the user is in an approver group; add an "Override" button gated to that group. (No-code equivalent: a Studio approval rule on the Confirm button + a stored "over limit" flag.)

7. Test every hero over XML-RPC

On a THROWAWAY record: trigger the action, assert the block fires, assert the override path works, then delete the throwaway. Leave the real demo objects pristine. Print a verification log with the actual numbers.

8. Generate the sales docs

From templates/ (genericized, brand-themed), produce three self-contained HTML files, filling in the client's data:

• run-of-show — beats with exact click-paths + what to say.
• one-pager — before/after, what's automated, investment, the path to go-live; branded for the selling company; decision-maker audience.
• demo-script-1pager — 7-ish numbered steps (Do + Say), prints on one A4.

9. Hand off

Output: the login, the pre-loaded data cheat-sheet, the verification log, and links to the three docs. Remind the user to rehearse once and keep the demo quotation in draft.

Guardrails

• Never invent that a feature works — test it. Step 7 is mandatory; a demo hero that fails live loses the deal.
• Research before building (step 2). Version assumptions are the #1 source of wasted effort.
• Don't hard-code the client. Everything client-specific lives in demo_config.json.
• Currency before invoices. Weight before fleet. Pre-stage before the live click. Order matters.
• Read reference/odoo19-field-gotchas.md before touching Odoo 19 — several core fields were renamed.

Files

• scripts/odoo_connect.py — XML-RPC connector + x() helper (correct context-kwarg passing).
• scripts/build_demo.py — config-driven data + hero builder (template to adapt per engagement).
• demo_config.example.json — the shape of a per-client config.
• reference/odoo19-field-gotchas.md — version-specific field names + footguns learned the hard way.
• templates/ — the three doc templates (brand-themed, {{placeholder}} driven).