glennandClaude Opus 5
96d02fe0d7
Most of this skill was never construction-specific. Phase A (discovery brief from any source), the two-agent parallel build, the generic purge craft and Phase C (follow-through docs) applied to any Odoo demo — but sat behind a BuildEase trigger, so Callista's plain Odoo implementations could not reach them and still ran upstream's Knowcap-bound step 1 with no follow-through. Those moved to callista-odoo-demo (Callista's fork of Smetools/odoo-demo- architect, which we cannot PR). What is left here is the part that is actually about construction, expressed as five overlays on named substrate steps: module routing, solution precedence, demo-data policy, purge chain, and follow-through framing. SKILL.md goes from 208 lines to 119. Nothing BuildEase-specific was dropped — the take-off-without-a-sale-order trap, the dynamic-article-template-line pin, the settings-default-off walk, the booked-vs-ordered-hours check and the custom_product_* dependency gap all survive. Two rules now carry the boundary: anything needed that is not one of the five overlays is a gap to fix in the substrate rather than work around here, and substrate steps are referenced by name, never by number — numbering was how an upstream renumber could silently misroute this skill. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
120 lines
5.6 KiB
Markdown
120 lines
5.6 KiB
Markdown
---
|
|
name: buildease-demo
|
|
description: BuildEase (callista-tools/mev) construction overlay for the callista-odoo-demo skill. Routes the client's pains onto the 34 BuildEase Odoo 19 modules before any custom work is considered, replaces the generic teardown with the take-off → progress-statement chain, and keeps the per-client dataset instead of the old buildease_demo_data bundle. Use for "BuildEase demo", "QTO demo", "quantity take-off demo", "construction Odoo demo", "vorderingsstaat demo", or a follow-up after one.
|
|
---
|
|
|
|
# BuildEase Demo
|
|
|
|
A **vertical overlay** on `callista-odoo-demo`. That skill owns the pipeline — discovery
|
|
brief, build, test, purge, sales docs, follow-through. This one supplies the five things
|
|
that are specific to construction, and nothing else.
|
|
|
|
**Requires** `callista-odoo-demo` installed at `~/.claude/skills/callista-odoo-demo/`
|
|
(Callista's fork of Smetools/odoo-demo-architect). If it is missing, say so and stop —
|
|
do not reimplement its XML-RPC connector, data builder, or pipeline here.
|
|
|
|
> Do **not** substitute an `odoo-demo-architect` install for it. That is upstream, without
|
|
> Phase A's source-agnostic discovery, without Phase C, and without the extension points
|
|
> this file plugs into.
|
|
|
|
**Run `callista-odoo-demo` and apply the overlays below at the named steps.** Everything
|
|
not listed here is that skill's job — follow it as written.
|
|
|
|
---
|
|
|
|
## Overlay 1 — Module routing
|
|
|
|
*Applies at:* **Install modules**, and Phase A's `## Phase 1 scope`.
|
|
|
|
Read `reference/buildease.md` and route the client's pains onto BuildEase modules using
|
|
its pain → module table. Match on **the client's own words** — the table is keyed on what
|
|
they actually say ("we measure in Excel then re-type it into the quote"), not on module
|
|
names they will never utter.
|
|
|
|
Install the umbrella module `buildease` plus the routed set. `buildease` depends on
|
|
nothing and installs the set.
|
|
|
|
## Overlay 2 — Solution precedence
|
|
|
|
*Applies at:* **Research native-vs-custom**.
|
|
|
|
The precedence becomes **BuildEase → native Odoo 19 → custom**, in that order. Most
|
|
construction pains are already solved in mev; custom work is the last resort, and native
|
|
Odoo is the middle tier, not the first question.
|
|
|
|
Odoo 19 only — every mev manifest is `19.0.x`. Do not attempt this against 17 or 18.
|
|
|
|
## Overlay 3 — Demo data policy
|
|
|
|
*Applies at:* **Load demo data**.
|
|
|
|
**Do not install `buildease_demo_data` or `buildease_demo_data_sale_progress`.** They are
|
|
the previous generation of environment setup: one fixed Belgian construction dataset, the
|
|
same for every prospect, dragging in `l10n_be` and `accountant` whether or not the client
|
|
is Belgian. The per-client dataset generated from the discovery brief replaces them — the
|
|
client's own partners, articles, projects and orders, staged so each hero has a record to
|
|
fire on.
|
|
|
|
Install them only if the user explicitly asks for the generic sandbox. The app-level
|
|
dependencies that bundle used to drag in (`sale_management`, `project`, `purchase_stock`,
|
|
`sale_timesheet`, `industry_fsm`, `accountant`, `uom`) still need installing — route them
|
|
from the pain table, not from the demo bundle.
|
|
|
|
## Overlay 4 — Purge chain
|
|
|
|
*Applies at:* **Purge test residue**, replacing the generic chain.
|
|
|
|
```
|
|
transient wizard rows → statements (cancelled only, newest first) → invoices
|
|
→ timesheet lines → tasks → projects → sale orders → take-offs → the partner
|
|
```
|
|
|
|
The generic traps still apply. These are the BuildEase-specific ones, each 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.
|
|
- Leftover `add.dynamic.article.template.line` rows pin take-offs. Clear them first.
|
|
- Statements cancel newest-first only.
|
|
|
|
## Overlay 5 — Follow-through framing
|
|
|
|
*Applies at:* **Phase C**.
|
|
|
|
Where an objection is already covered by BuildEase, name the **module and the screen** on
|
|
the objection sheet — "that's `sale_progress_revision_formula`, on the statement's Revision
|
|
tab" lands better than "yes, we support that". Where mev does not cover it, say so and give
|
|
the workaround or the build estimate.
|
|
|
|
Check the scoped quote against `reference/buildease.md`'s gotchas before pricing:
|
|
`custom_product_sale`, `custom_product_bom` and `bom_on_sale_order_line` are **not in the
|
|
mev repo**, so anything under `buildease_custom_product*` is not a "just install it" line.
|
|
|
|
---
|
|
|
|
## BuildEase-specific checks
|
|
|
|
- After installing, **walk Settings once**. `res.config.settings` and `res.company` are
|
|
extended by 8 modules each and several BuildEase behaviours default to off.
|
|
- At the staged-numbers sanity check: **booked hours well under ordered hours**. Over 100%
|
|
makes the progress statement look wrong on screen even when every assertion passed.
|
|
- The spine of every BuildEase demo is QTO → sale order → project → progress statement →
|
|
invoice. If that chain breaks mid-demo you lose the deal, so it is the chain **Test
|
|
heroes** must exercise end to end.
|
|
- `quantity.take.off` inherits `mail.thread` + `mail.activity.mixin` — chatter and
|
|
activities work for free. Cheap demo beats.
|
|
|
|
## Guardrails
|
|
|
|
- Never claim a BuildEase feature works without having seen it work in the demo DB.
|
|
- Never invent a pain quote. `(inferred)` is fine; a fabricated quote read back to the
|
|
client in the demo is not.
|
|
- If something you need is not one of the five overlays above, that is a gap in
|
|
`callista-odoo-demo` — fix it there, so the next vertical gets it free. Do not work
|
|
around it here.
|
|
|
|
## Files
|
|
|
|
- `reference/buildease.md` — the module map, the pain → module routing table, and the mev
|
|
gotchas. Read it at Phase A.
|