wren-project
MDL Project
Version check
Silently fetch https://raw.githubusercontent.com/Canner/wren-engine/main/skills/versions.json.
Compare the wren-project key with this skill's version (from the frontmatter above).
If the remote version is newer, notify the user before proceeding:
A newer version of the wren-project skill is available. Update with:
npx skills add Canner/wren-engine --skill wren-project --agent claude-code
Then continue with the workflow below regardless of update status.
A Wren MDL project is a directory of YAML files — one file per model — that makes MDL manifests human-readable and version-control friendly (similar to dbt projects).
YAML files use snake_case field names for readability. The compiled target/mdl.json uses camelCase (the wire format expected by ibis-server). The conversion is documented in Field mapping.
Project structure
my_project/
├── wren_project.yml # Project metadata (catalog, schema, data_source)
├── models/
│ ├── orders.yml # One file per model
│ ├── customers.yml
│ └── ...
├── relationships.yml # All relationships
└── views.yml # All views
After building, the compiled file is written to:
my_project/
└── target/
└── mdl.json # Deployable MDL JSON (camelCase)
Note: Connection info is managed separately via the MCP server Web UI, not stored in the project directory.
Save MDL JSON → YAML project
Given an MDL JSON dict (camelCase), write it as a YAML project directory (snake_case):
wren_project.yml
name: my_project
version: "1.0"
catalog: wren
schema: public
data_source: POSTGRES
models/<model_name>.yml
One file per model. Example for orders:
name: orders
table_reference:
catalog: ""
schema: public
table: orders
columns:
- name: order_id
type: INTEGER
is_calculated: false
not_null: true
is_primary_key: true
properties: {}
- name: customer_id
type: INTEGER
is_calculated: false
not_null: false
properties: {}
- name: total
type: DECIMAL
is_calculated: false
not_null: false
properties: {}
primary_key: order_id
cached: false
properties: {}
relationships.yml
relationships:
- name: orders_customer
models:
- orders
- customers
join_type: MANY_TO_ONE
condition: orders.customer_id = customers.customer_id
views.yml
views: []
Load YAML project → MDL JSON
To assemble a YAML project back into an MDL JSON dict:
- Read
wren_project.yml→ extractcatalog,schema,data_source - Read every file in
models/*.yml→ collect intomodelslist - Read
relationships.yml→ extractrelationshipslist - Read
views.yml→ extractviewslist - Rename snake_case keys to camelCase (see Field mapping section below)
- Assemble:
{
"catalog": "<from wren_project.yml>",
"schema": "<from wren_project.yml>",
"dataSource": "<from wren_project.yml data_source>",
"models": [...],
"relationships": [...],
"views": []
}
Build YAML project → target/
Same as Load above, but write the compiled file:
<project_dir>/target/mdl.json— assembled MDL JSON (camelCase)
After building:
- Pass
mdl_file_path="<project_dir>/target/mdl.json"todeploy()to activate the MDL - Connection info is managed via the MCP server Web UI — no file needed
Field mapping
When converting between YAML (snake_case) and JSON (camelCase):
MDL fields:
| YAML field (snake_case) | JSON field (camelCase) |
|---|---|
data_source |
dataSource |
table_reference |
tableReference |
is_calculated |
isCalculated |
not_null |
notNull |
is_primary_key |
isPrimaryKey |
primary_key |
primaryKey |
join_type |
joinType |
All other MDL fields (name, type, catalog, schema, table, condition, models, columns, cached, properties) are the same in both formats.
Typical workflow
1. Generate MDL
Follow the wren-generate-mdl skill to introspect the database and build the MDL JSON dict.
2. Save project
Write wren_project.yml + models/*.yml + relationships.yml + views.yml
(convert camelCase → snake_case from the MDL JSON).
3. Add target/ to .gitignore
4. Commit project directory to version control
5. Later — Build: read wren_project.yml, then models/*.yml, relationships.yml, views.yml.
Rename snake_case → camelCase, write target/mdl.json.
6. Connection info: configure via the MCP server Web UI
(typically http://localhost:9001; use the Docker host hint when running in a container)
7. Deploy: deploy(mdl_file_path="./target/mdl.json")
More from canner/wren-engine
wren-usage
Wren Engine CLI workflow guide for AI agents. Answer data questions end-to-end using the wren CLI: gather schema context, recall past queries, write SQL through the MDL semantic layer, execute, and learn from confirmed results. Use when: user asks a data question, requests a report or analysis, asks about metrics, revenue, customers, orders, trends, or any business data; user says 'how many', 'show me', 'what is the', 'top N', 'compare', 'trend', 'growth', 'breakdown'; user wants to explore, analyze, filter, aggregate, or summarize data from a database; agent needs to query data, connect a data source, handle errors, or manage MDL changes via the wren CLI.
21wren-generate-mdl
Generate a Wren MDL project by exploring a database with available tools (SQLAlchemy, database drivers, MCP connectors, or raw SQL). Guides agents through schema discovery, type normalization, and MDL YAML generation using the wren CLI. Use when: user wants to create or set up a new MDL, onboard a new data source, or scaffold a project from an existing database.
21wren-dlt-connector
Connect SaaS data (HubSpot, Stripe, Salesforce, GitHub, Slack, etc.) to Wren Engine for SQL analysis. Guides the user through the full flow: install dlt, pick a SaaS source, set up credentials, run the data pipeline into DuckDB, then auto-generate a Wren semantic project from the loaded data. Use this skill whenever the user mentions: connecting SaaS data, importing data from an API, dlt pipelines, loading HubSpot/Stripe/Salesforce/GitHub/Slack data, querying SaaS data with SQL, or setting up a new data source from a REST API. Also trigger when the user already has a dlt-produced DuckDB file and wants to create a Wren project from it.
17wren-onboarding
Onboard a user to Wren Engine end-to-end. Walks through environment checks, project scaffolding, connection configuration via .env, and first query. Use when: user wants to install Wren Engine, set up a new data source connection, or bootstrap a new project from scratch. Triggers: '/wren-onboarding', 'install wren', 'set up wren engine', 'wren onboarding', 'connect new database to wren'.
7wren-sql
Write and correct SQL queries targeting Wren Engine — covers MDL query rules, filter strategies, data types (ARRAY, STRUCT, JSON/VARIANT), date/time functions, Calculated Fields, BigQuery dialect quirks, and error diagnosis. Use when generating or debugging SQL for any Wren Engine data source.
3wren-quickstart
End-to-end quickstart for Wren Engine — create a workspace, generate an MDL from a live database, save it as a versioned project, start the Wren MCP Docker container, and verify the setup with a health check. Trigger when a user wants to set up Wren Engine from scratch, onboard a new data source, or get started with Wren MCP. Requires dependent skills already installed (use /wren-usage to install them first).
3