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>
4.6 KiB
CLAUDE.md
This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
What this repository is
This repo is a Claude Code skill, not an application. It contains no source code, tests, or build tooling — only prompt content:
SKILL.md— the skill body (name: buildease-demo), loaded by Claude Code when the skill is invoked.reference/buildease.md— the BuildEase module map and pain→module routing table, read at Phase A.
Editing this repo means editing instructions that another Claude instance will follow. There is nothing to compile or lint; the only meaningful verification is running the skill end to end against a real Odoo instance.
Installing / testing a change
ln -s "$PWD" ~/.claude/skills/buildease-demo
Claude Code discovers skills from the name:/description: frontmatter in SKILL.md. Changing name: changes how the skill is invoked; changing description: changes when it triggers — both are the routing surface, so treat them as API.
Architecture
buildease-demo is a thin vertical overlay on callista-odoo-demo. It does not own a pipeline. It supplies exactly five overlays, each applied at a named step of the substrate skill:
| Overlay | Applied at |
|---|---|
Module routing (reference/buildease.md) |
Install modules, Phase A ## Phase 1 scope |
| Solution precedence — BuildEase → native Odoo 19 → custom | Research native-vs-custom |
Demo data policy — never buildease_demo_data |
Load demo data |
| Purge chain — take-off / progress-statement teardown order | Purge test residue |
| Follow-through framing | Phase C |
The boundary is the point of this repo. Anything needed that isn't one of those five is a gap in callista-odoo-demo — fix it there, so the next vertical inherits it. Do not work around it here, and never reimplement the substrate's scripts/, templates/, or demo_config.json handling.
This repo was previously a full three-phase skill. The generic two-thirds (discovery brief from any source, the two-agent parallel build, the follow-through doc set) moved into the substrate on 2026-07-31 because Callista runs it for plain Odoo implementations too, and that content was stranded behind a construction trigger.
Substrate and upstream
| Repo | Role |
|---|---|
admin/callista-odoo-demo (Gitea) |
The pipeline this skill overlays. Hard dependency, installed as ~/.claude/skills/callista-odoo-demo/ |
github.com/Smetools/odoo-demo-architect |
What the substrate was forked from at ada2751. Callista has no commit rights; changes land in the fork. See its UPSTREAM.md |
git@github.com:callista-tools/mev.git |
BuildEase — 34 Odoo 19 modules, umbrella module buildease. Not vendored; reference/buildease.md is a distilled map |
Never install the substrate under the name odoo-demo-architect. Skills resolve by directory name, so a same-named fork silently shadows upstream depending on install order, and two people build different demos from the same brief.
Editing rules that carry weight
- Reference substrate steps by name (Test heroes, Purge test residue), never by number. Numbered references are how an upstream renumbering silently misroutes this skill with nothing to detect it.
- The purge ordering (transient wizard rows → statements → invoices → timesheets → tasks → projects → sale orders → take-offs → partner last) is ordered because Odoo blocks deletion otherwise. Do not reorder or summarise. The take-off-without-a-sale-order trap in particular is non-obvious and cost a debugging round.
- Not installing
buildease_demo_datais the reason this overlay exists at all; the app-level dependencies that bundle used to drag in must still be routed from the pain table. reference/buildease.mddrifts when mev changes. When updating it, keep the two things that make it useful: the pain→module table keyed on the client's own words, and the gotchas (missingcustom_product_*deps, Odoo 19 only, settings that default off).
Writing style for this repo
Match the existing prose: imperative, second person, no hedging, tables for anything enumerable. Rules state what to do and the failure that motivates them ("a fabricated quote read back to the client in the demo is not"). Avoid generic agent boilerplate — everything here should be specific to BuildEase or it belongs in the substrate.
Related
The parent workspace ../CLAUDE.md (Callista BV multi-customer workspace) covers Odoo module conventions — naming, manifests, version numbering — and applies when editing the mev modules themselves, not this repo.