glennandClaude Opus 5
8ea297e8bf
Callista consumes this pipeline for both plain Odoo implementations and vertical demos, and is not a maintainer upstream — so the generic demo craft that had accumulated in the buildease-demo vertical skill lands here instead, where every engagement can reach it. Moved in from buildease-demo (they were never construction-specific): - Phase A: discovery brief from a transcript, notes, email, Knowcap, or a batched interview. Replaces the Knowcap-bound step 1. Infers before it asks. - Fork the slow half: instance prep and client research as two parallel subagents, then join. - Purge test residue: ordering, traps, read-back-the-counts evidence. - Phase C: objection sheet, scoped quote, implementation timeline, SOW. New here: - Extension points — a vertical supplies module routing, solution precedence, purge chain, demo-data policy and follow-through framing, and nothing else. Anything it needs beyond those is a gap to fix here, not to work around. - Named steps instead of numbered ones. Numbering meant an upstream renumber silently misrouted an extending skill with nothing to detect it. Renamed the skill to callista-odoo-demo: skills resolve by directory name, so a same-named fork shadows upstream depending on install order, and two people would build different demos from the same brief. MIT retained; SMEtools copyright kept, Callista added for modifications. Fork point and divergence recorded in UPSTREAM.md. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Callista Odoo Demo
Turn a discovery call into a complete, working Odoo demo — and the documents to sell it, before and after the meeting — with an AI agent doing the build.
Fork of Smetools/odoo-demo-architect (MIT). See
UPSTREAM.mdfor the fork point and what diverges.
A Claude Code skill. Point it at whatever discovery material exists — a transcript, meeting notes, an email thread, Knowcap, or nothing at all — and a reachable Odoo instance. It writes the discovery brief, researches what Odoo does natively vs. what needs building, stands up a live database (modules + realistic data + the 1–2 "hero" features that win the deal), tests that those features actually fire, and generates the sales documents. After the demo it writes the follow-through set.
Three phases
| Phase | Produces |
|---|---|
| A — Discovery brief | discovery_brief.md in a fixed six-section shape, from any source. Infers first, asks the gaps in one batch |
| B — Build | A live Odoo DB with working heroes, a verification log with real numbers, and three sales docs: run-of-show, decision-maker one-pager, 1-page demo script |
| C — Follow-through | Objection sheet, scoped quote, implementation timeline, statement of work |
Each phase is usable alone. Phase C runs days after the demo.
Verticals extend this
Vertical skills (e.g. buildease-demo for construction) wrap this one and supply only
their own module routing, solution precedence, purge chain, demo-data policy, and
follow-through framing. They do not restate the pipeline. See
Extension points.
Install
git clone <this repo> ~/.claude/skills/callista-odoo-demo
Then ask Claude: "build an Odoo demo for <client> from these notes."
Do not install this as odoo-demo-architect — skills resolve by directory name, and a
same-named fork silently shadows upstream depending on install order.
Prerequisites
- Claude Code.
- A reachable Odoo instance + API key (Settings → My Profile → Account Security → New API Key).
- On Odoo.sh: create the project + enter any partner trial code first (web-only), then come back with the DB URL + API key.
- Optional: Knowcap with its MCP connected, as one possible discovery source → knowcap.ai.
- Optional: the Perplexity MCP for the native-vs-custom research step (web search works too).
Quickstart
- Put your Odoo creds in env vars (or
scripts/creds.json):ODOO_URL,ODOO_DB,ODOO_LOGIN,ODOO_KEY. - Verify the connection:
python scripts/odoo_connect.py→ printsserver_version. - Copy
demo_config.example.json→scripts/demo_config.json, fill it from the brief. - Ask Claude to run the pipeline (see
SKILL.md).
scripts/creds.json and scripts/demo_config.json are gitignored — they hold client API keys. Keep it that way.
Read this before touching Odoo 19
Several core fields were renamed in v19 (res.users.group_ids, res.groups lost category_id, etc.), credit limit is warning-only natively, and fleet load-by-weight needs stock_fleet. All the footguns are in reference/odoo19-field-gotchas.md so you don't relearn them the hard way.
Files
SKILL.md the procedure (what the agent follows)
UPSTREAM.md fork point + divergence from upstream
scripts/odoo_connect.py XML-RPC connector + helpers
scripts/build_demo.py config-driven data + hero builder (template)
demo_config.example.json per-client config shape
reference/odoo19-field-gotchas.md version-specific fields + footguns
templates/ brand.css + the doc templates
License
MIT — see LICENSE. Original copyright SMEtools; modifications Callista BV.
Credit
Original by SMEtools — Odoo implementation + AI automation. Fork maintained by Callista BV. Runs on Claude Code.