Build on OpenClaw

Skill API Quick Reference

Every skill follows the same two-file pattern: a SKILL.md manifest and a db_query.py script.

name: erpclaw-selling
version: "1.0.0"
description: Sales orders, invoices, delivery notes
author: AvanSaber Inc.
scripts:
  - name: db_query.py
    description: Sales management
    arguments:
      - name: action
        description: Action to execute
        required: true
actions:
  - name: add-customer
    description: Create a new customer
    tier: 1
  - name: list-customers
    description: List all customers
    tier: 1

# Every action follows the same pattern:
python3 db_query.py --action add-customer \
  --company-id "$COMPANY_ID" \
  --name "Acme Corp" \
  --customer-type company \
  --credit-limit 50000

# Output is always JSON:
{
  "customer_id": "abc-123-def",
  "name": "Acme Corp",
  "customer_type": "company",
  "status": "ok"
}

Database Schema

One schema in a single database. Every module has its own table namespace. SQLite (default) or PostgreSQL (enterprise).

One module holds the pen for each table

Any ERPClaw module can read any table in the shared database, but each table has exactly one module allowed to write to it. The rule is called read-many, write-one, and it decides how quickly a bug gets found and how far a bad one can travel.

Picture a document that eleven people can edit. When something in it is wrong, you open the version history and start guessing who changed what. Many business systems end up working like that document without anyone choosing it.

In ERPClaw, when a sales invoice is wrong, there is one owner to look at, not every module that might have touched it. A module that needs something changed elsewhere asks the owning module through its published actions instead of writing the rows itself, and ledger entries have a single writer: the shared posting engine, which checks every entry before it lands. Industry and add-on modules are held to this in code, not by convention: a validator reads each module's database statements and fails any module that writes directly to a table it does not own. That also contains the damage. A defect in an industry module cannot quietly rewrite the sales ledger, because it never had write access there.

The longer version: one writer per table. The rule is enforced alongside the other ERPClaw OS constitutional articles, and it drew more interest than we expected when we presented the architecture at IEEE IRI 2026 (the four questions from that talk).

Quick Start

From zero to a working skill in three steps.

git clone https://github.com/avansaber/erpclaw
cd erpclaw
python3 scripts/db_query.py --action initialize-database
python3 scripts/db_query.py --action seed-demo-data

cd scripts/erpclaw-selling && python3 -m pytest tests -v

# Create a new skill
mkdir my-skill && cd my-skill
# Add SKILL.md + scripts/db_query.py
# Follow the action pattern: --action my-action --param value