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>
80 lines
4.1 KiB
Markdown
80 lines
4.1 KiB
Markdown
# 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](https://github.com/Smetools/odoo-demo-architect)** (MIT). See [`UPSTREAM.md`](UPSTREAM.md) for 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](SKILL.md#extension-points).
|
||
|
||
## Install
|
||
|
||
```bash
|
||
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](https://knowcap.ai).
|
||
- Optional: the **Perplexity MCP** for the native-vs-custom research step (web search works too).
|
||
|
||
## Quickstart
|
||
|
||
1. Put your Odoo creds in env vars (or `scripts/creds.json`):
|
||
`ODOO_URL`, `ODOO_DB`, `ODOO_LOGIN`, `ODOO_KEY`.
|
||
2. Verify the connection: `python scripts/odoo_connect.py` → prints `server_version`.
|
||
3. Copy `demo_config.example.json` → `scripts/demo_config.json`, fill it from the brief.
|
||
4. Ask Claude to run the pipeline (see [`SKILL.md`](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`](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`](LICENSE). Original copyright SMEtools; modifications Callista BV.
|
||
|
||
## Credit
|
||
|
||
Original by **[SMEtools](https://www.smetools.io)** — Odoo implementation + AI automation.
|
||
Fork maintained by **[Callista BV](https://www.callista.be)**.
|
||
Runs on **[Claude Code](https://claude.com/claude-code)**.
|