Claude Code skill

Claude Code can write ODXProxy clients without being told the protocol every time. The odxproxy-clients skill teaches it the envelope, the nine allowed actions, the error catalog, and the official SDKs — plus the habit that matters most: inspect the target Odoo's real schema before modelling it.

Source: terrakernel/odxproxy_claude_code_skills · MIT.

Install

git clone https://github.com/terrakernel/odxproxy_claude_code_skills.git
cd odxproxy_claude_code_skills
./install.sh

install.sh symlinks every skill in the repo into ~/.claude/skills/, so a later git pull updates what's installed. Pass --copy to copy instead, or a target directory to scope it to one project:

./install.sh .claude/skills          # project-scoped — check it in with your repo
./install.sh --copy                  # copy instead of symlink

Using it

The skill auto-triggers — there's nothing to invoke. Its description fires whenever a prompt involves ODXProxy or building an Odoo client through it:

• "Build a Python service that reads sales orders from Odoo through ODXProxy."
• "Generate a typed TypeScript model for res.partner on my Odoo instance."
• "Why am I getting error -32002 from odxproxy?"
• "Introspect the product.template fields before we write the DAO."

You can also point at it explicitly — "Use the odxproxy-clients skill to …".

What it teaches

The skill front-loads the two facts that cause most integration bugs: the two distinct secrets (x-api-key for the proxy, odoo_instance.api_key for the Odoo user), and that HTTP 200 can still carry an error. Then it follows a fixed workflow:

1. Introspect first. Call fields_get on the model to get its real field names, types, required flags, relation targets, and selection values — then map that into your language's structs or DTOs. Odoo models are heavily customized per instance, so writing the native data model before introspecting is the most common source of bugs.
2. Pick the client path — an official SDK, or a hand-rolled client against the raw JSON-RPC contract.
3. Map each operation to one allowed action, reaching for call_method + fn_name when an Odoo method falls outside the eight CRUD actions.
4. Handle errors by code, not by HTTP status alone — retry on timeout, surface Odoo validation messages, fail fast on auth.

Its reference material (the full envelope contract, per-action params/keyword shapes, the error catalog, per-SDK APIs, and the introspection recipe) loads only when relevant, so the skill stays cheap in context until it's needed.

The odx.py introspection CLI

The skill ships a zero-dependency CLI over /api/odoo/execute — Python 3 standard library only, no pip install — for introspecting or testing an instance before any SDK is chosen:

cp scripts/.env.example scripts/.env      # then fill in the values
python3 scripts/odx.py --env-file scripts/.env fields_get res.partner
python3 scripts/odx.py --env-file scripts/.env search_read res.partner --fields name,email --limit 5

It covers every action — version, search_count, search, read, fields_get, search_read, create, write, unlink, call_method, and a generic execute. The two keys it reads are different: ODX_PROXY_KEY is the proxy's x-api-key, ODX_ODOO_API_KEY is the Odoo user's key. The script bakes in the 200-with-error check, so a proxy or Odoo failure exits non-zero with the JSON-RPC error on stderr.

Prefer to write the client yourself? The SDK overview and the API reference carry the same protocol the skill is built on.