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>
62 lines
4.6 KiB
Markdown
62 lines
4.6 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
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_data`** is 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.md` drifts 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 (missing `custom_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.
|