Claude-buildease-demo/SKILL.md

name, description

name

description

buildease-demo

Wraps odoo-demo-architect for BuildEase (callista-tools/mev) construction demos. Builds the discovery brief from any source — transcript file, notes, email thread, or a live interview — instead of requiring Knowcap, routes client pains onto BuildEase modules before considering custom work, and after the demo generates the follow-through set (objection sheet, scoped quote, implementation timeline, SOW). Use for "BuildEase demo", "QTO demo", "construction Odoo demo", "prep a demo from these notes", or "write the follow-up after the demo".

BuildEase Demo

Three phases. odoo-demo-architect does the middle one; this skill owns the ends.

Requires odoo-demo-architect installed (~/.claude/skills/odoo-demo-architect/, from github.com/Smetools/odoo-demo-architect). If it is missing, say so and stop — do not reimplement its XML-RPC connector or data builder.

---

Phase A — Discovery brief (no Knowcap)

Goal: produce discovery_brief.md in exactly the shape odoo-demo-architect's step 1 would have emitted, from whatever the user actually has.

Source, in order of preference:

1. A transcript, meeting notes, or email thread — read it.
2. Knowcap MCP, if it happens to be available and the user wants it.
3. Nothing written down → interview the user (see intake below).

Intake — infer first, ask only the gaps

Before asking anything, look: glob the working directory for a transcript, notes, brief, or .md/.txt/.docx that plausibly is the source, and read it. Then answer each item below from what you read. Only the items you genuinely cannot answer go to the user, in one AskUserQuestion batch — never a serial interrogation, never a question whose answer is sitting in the file you just read.

Item	Infer from	Ask only if
Source brief location	A single obvious candidate file in the working directory	Zero or several candidates — ask which, or paste
Odoo UI language	Language the brief is written in; client country; l10n_* in scope	Brief is English but the client clearly isn't anglophone — ask (nl_BE / fr_BE / en_US / other)
Client website / company info	URL or company name in the brief — fetch the site, mine it for what they build, size, regions, branding	No name or URL anywhere in the source
Odoo instance	demo_config.json, prior session, the brief	Not found — always ask, never guess a URL or API key
Demo audience	Attendee list in a transcript header or email thread	Source is notes with no names
Rate card	A rates file in the project	Only needed at Phase C — don't ask now

Anything still missing after that batch: write it into the brief as (unknown) and carry on. One unknown does not block building the demo.

If nothing written down exists at all, the interview replaces the table — still one batch: who the client is, what they build, how they quote today, how they invoice, the top 3 complaints they voiced, who is in the room.

Write discovery_brief.md with these six sections and no others:

## Business shape
Entities, product/customer types, volumes, shared financials.
Company name, website, country, what they actually build — from the site if you fetched it.

## Top pains
3–5 items. Direct client quotes where you have them. Mark anything you inferred as (inferred).

## Hero features
1–2. Each names the pain it kills and the decision-maker it lands on.

## Phase 1 scope
Odoo apps + BuildEase modules, from reference/buildease.md.

## Odoo instance
URL, database, login, API key. Ask if absent — do not guess.
UI language + `l10n_*` localisation to install.

## Demo audience
Who is in the room and what each one needs to hear.

Never invent a pain quote. An inferred pain marked (inferred) is fine; a fabricated quote read back to the client in the demo is not.

Show the brief to the user and get a yes before Phase B.

---

Phase B — Build, via odoo-demo-architect

Hand discovery_brief.md to odoo-demo-architect and let it run its pipeline (research → connect → install → data → heroes → test → sales docs).

Fork the slow half

Module installation and client research are independent — the install list comes from the brief plus the routing table, the research feeds hero building which happens after both. Installing over XML-RPC is minutes of waiting and produces log spew nobody needs in context. So run them as two parallel subagents, launched in one message:

Agent 1 — instance prep. Give it the Odoo credentials, the routed module list, and odoo-demo-architect's scripts/odoo_connect.py. It sets the company, currency, UoM and UI language, installs the localisation, installs buildease + the routed modules, then walks Settings for the BuildEase toggles that default off. It loads no data — that is the join step's job. Returns: what installed, what failed, the settings it changed.

Agent 2 — client research. Give it the brief. It fetches the client's website, and researches each hero feature BuildEase → native Odoo 19 → custom, in that order. Returns: per hero, which of the three it lands in, and the click-path if it already exists.

Join. Both done → install any module Agent 2's research turned up that Agent 1 didn't know about (incremental, cheap), then generate and load the client-specific dataset into the empty database, then build and test heroes.

Two agents, not five. Do not fan out further — hero building is sequential against one database and parallel writes will fight.

Two things to inject before it starts:

1. Read reference/buildease.md and pass the routed module list. The research step's native-vs-custom question becomes BuildEase → native Odoo → custom, in that order. Most construction pains are already solved in mev; custom work is the last resort.
2. This skill is the demo data loader. Do not install buildease_demo_data — that is the old, one-size-fits-all Belgian dataset it replaces. The database starts empty and gets a dataset generated from the brief: the client's own partners, articles, projects and orders, staged so each hero feature has a record to fire on. Install it only if the user explicitly asks for the generic sandbox.

Its step 7 (test every hero on throwaway records) is not optional here either. A QTO → sale order → project → progress statement → invoice chain that breaks mid-demo is the one failure mode that loses the deal.

Verify on throwaway records, then delete them

Test against a partner named ZZ Test…, never against the client's own records — a hero you tested is a hero you consumed, and the demo needs its first click to be the first click.

Then purge. A demo environment ships with zero test residue. Debugging the chain takes several runs, each leaving a full take-off → order → project → statement → invoice trail; "it's cancelled and the partner is archived" is not clean, those records still list on screen. Write the purge as a function in the test script and run it until the counts are zero — not as a one-off you improvise at the end.

Odoo blocks most of this unless you go in order:

transient wizard rows → statements (cancelled only, newest first) → invoices
→ timesheet lines → tasks → projects → sale orders → take-offs → the partner

The traps, all of which cost a debugging round:

• A take-off with no sale order cannot be deleted at all. Its state is derived from the order, so there is nothing to cancel. Convert it to a quotation, cancel that, then delete.
• search will not find the partner once archived — pass context={"active_test": False} or the purge silently no-ops and reports success.
• Statements cancel newest-first only; invoices must go to draft before cancel; leftover add.dynamic.article.template.line rows pin take-offs.
• Delete the partner last, and only once nothing references it. Deleting it first nulls partner_id on whatever survived, so a partner_id-based purge can no longer see those records and a partner_id-based assertion reports clean over an environment that isn't. Sweep by name as well, and assert on both.
• Anything the tests copy inherits the source record's customer, not the throwaway one. Repoint copies at the throwaway partner or they escape the purge.
• Make every step best-effort with its own try, and print what it kept — a silent purge that skipped nine records reads exactly like one that worked.

Finish by reading back the counts of every model you touched and putting them in the verification log. "No test residue" is a claim; the counts are the evidence.

Sanity-check the staged numbers before calling it done

A chain that passes every assertion can still look broken on screen. Check the staged data reads plausibly: booked hours well under ordered hours (over 100% makes the progress statement look wrong), costs under selling prices, dates in the past. Derive staged quantities from the ordered quantity rather than hard-coding them, so they cannot drift when a formula changes.

---

Phase C — Follow-through

Runs after the demo happened. Needs: the built demo, the verification log, and what actually came up in the room. Ask the user for the room notes — objections raised, who pushed back, what they asked for that wasn't there.

Generate four documents. Reuse odoo-demo-architect's templates/ branding and its self-contained-HTML rule (no external assets, single file, prints to A4).

Document	Contents
Objection sheet	Every objection raised → the honest answer. Where BuildEase already covers it, name the module and the screen. Where it doesn't, say so and give the workaround or the build estimate.
Scoped quote	Line items from the Phase 1 scope: modules, configuration, data migration, custom work, training. Days and rate per line. Flag assumptions separately from committed lines.
Implementation timeline	Phased, with the client's own dependencies on it (data extraction, sign-offs, who from their side). Weeks, not dates, unless a start date is agreed.
Statement of work	Deliverables, acceptance criteria, out-of-scope list, change-request process. The out-of-scope list is the point — write it properly.

Rules:

• Every number traces to something. No invented day-rates, no invented licence costs — ask the user for the rate card.
• Anything the demo didn't prove goes in the quote as build work, not as "included". Cross-check against the verification log from step 7.
• The out-of-scope list is where the follow-through earns its keep. Anything discussed and not quoted goes in it explicitly.

Show all four to the user before anything leaves the machine.

---

Guardrails

• Never claim a BuildEase feature works without having seen it work in the demo DB.
• Never hand over an environment holding test records. Purge them and read back the counts; do not settle for "cancelled and archived" and do not write the leftovers off as a note in the verification log.
• Never send anything client-facing without the user reading it first.
• discovery_brief.md, demo_config.json and the follow-through docs hold client data and API keys — keep them in the project directory, never in a scratchpad you'd forget.