The commands

Everything a SQL Yodeler project needs is a yodel command, and the starter templates add just targets that wrap them. This page says which one does what, then lists yodel’s commands, its exit codes and the JSON Schemas of its --json output.

Which command runs what

Command	What it is for
npx @intentius/sql-yodeler create <dir> --clickhouse (or --postgres)	once, to make the project from SQL Yodeler’s template, the one released with that yodel (Your first migration).
yodel emulator up	a local ClickHouse and Postgres in Docker, for development; yodel emulator status and yodel emulator down check and stop them.
yodel	everything about the schema and the migrations: plan, new, lint, apply, status, drift, report, ci and the rest of the commands yodel --help lists below. Inside a project, run it as npx yodel.
yodel approve <env>	a person’s approval of the plan yodel apply would run, at a terminal: it shows the plan and asks you to type the environment’s name. Every message that asks for an approval prints it with the digest, yodel approve <env> --plan <digest> (Approval).
the template’s just targets	optional shortcuts that print the command they run; the table in Your first migration lists them.
yodel mcp	read-only tools for a coding agent, over MCP (Set up with a coding agent).
the JSON Schemas	for anything that parses yodel’s output: JSON output.

yodel runs chant’s CLI underneath (chant init, chant emulator, chant run, chant approve), so you never need to; chant’s CLI reference is there for the curious.

yodel –help

$ yodel --help
Usage: yodel <command> [options]

Schema management and migrations for ClickHouse and Postgres.

Commands:
  create      make a new project from SQL Yodeler's template
  init        adopt a live database, or record its baseline in another env
  emulator    start, stop or check the local ClickHouse and Postgres (Docker)
  plan        show what apply would change in an environment
  apply       bring an environment to its declared schema or pending migrations
  approve     approve the plan yodel apply would run (a person at a terminal)
  override    override a policy rule for the current plan, with a reason
  new         write the next migration from the declared schema
  checkpoint  write a checkpoint: the newest recorded schema from nothing
  lint        check the migrations against the lint rules
  test        run tests/*.test.ts on databases built from the migrations
  status      list applied, pending and out-of-order migrations
  report      each environment's migrations side by side, and the audit log
  drift       report declared objects changed out of band or gone
  docs        write an HTML reference and a Mermaid ERD of the schema
  ci          render the project's CI pipelines (GitHub, GitLab, Forgejo)
  config      print each environment's settings, and prove a job cannot write
  rebase      move a migration onto a new parent and recompute its schema
  repair      record a new checksum for an applied migration, with a reason
  revert      undo the newest applied migration from its recorded schemas
  cleanup     drop the old tables and columns steps kept, once past their date
  mcp         serve read-only tools to a coding agent (MCP, stdio)

Options:
  -h, --help     show this help
  -v, --version  print the version

yodel <command> --help (or yodel help <command>) shows a command's options.
Docs: https://intentius.io/sql-yodeler/

Exit codes (yodel <command> --help lists a command's own):
  0  done, or nothing to do
  1  an error
  2  something yodel will not do itself (a change that needs an Op it does not
     run, a manual step); for yodel drift, drift found
  3  something outstanding: apply stopped at its approval gate, status found
     pending migrations, lint found errors
  4  refused, nothing done: a checksum mismatch, an applied migration gone from
     the directory, an out-of-order migration, a fork or another problem in the
     migrations directory, a migration the environment it must run on first has
     not applied, an environment whose reader and writer are one identity, a
     command that writes run with an environment's reader
  5  another apply holds the lock
  yodel plan exits 0 when migrations are pending: it reports, and a CI job that
  posts the plan on a pull request should not fail because the pull request adds
  a migration. To gate on pending migrations, use yodel status.

Exit codes

yodel <command> --help lists each command’s options and exit codes. The exit codes mean the same across commands where they can:

Code	Meaning
0	done, or nothing to do
1	an error
2	something yodel will not do itself (a change that needs an Op it does not run, a manual step); for yodel drift, drift found
3	something outstanding: apply stopped at its approval gate, status found pending migrations, lint found errors
4	refused, nothing done: a checksum mismatch, an applied migration gone from the directory, an out-of-order migration, a fork or another problem in the migrations directory, a migration the environment it must run on first has not applied, an environment whose reader and writer are one identity, a command that writes run with an environment’s reader
5	another apply holds the lock

yodel apply exits with the code of its Op’s Apply step, so a lock held by another apply is 5 there too. yodel plan exits 0 when migrations are pending: it reports, and a CI job that posts the plan on a pull request should not fail because the pull request adds a migration. To gate on pending migrations, use yodel status.

JSON output

With --json, a command prints one JSON document on stdout. Each document has a JSON Schema, shipped in the package’s schemas/ directory and published at https://intentius.io/sql-yodeler/schemas/v1/<name>.schema.json:

Command	Schema
yodel init --from <env> --json, yodel init --baseline <env> --json	init
yodel plan <env> --json	plan: the versioned plan ("mode": "versioned") or the declarative one
yodel apply <env> --json	apply
yodel new <name> --json	new
yodel lint --json	lint; yodel lint --rules --json prints lint-rules
yodel status <env> --json	status
yodel drift <env> --json	drift
yodel rebase --json	rebase
yodel repair <env> <id> --reason <text> --json	repair
yodel cleanup <env> --json	cleanup

Where a document asks for an approval, approve is the command a person runs, yodel approve <env> --plan <digest>, and chantApprove is chant’s own command for the same approval, for a script that records approvals itself. The version is in each schema’s $id (v1). Within a version, fields are only added, so a reader ignores fields it does not know; removing a field or changing what one means is a new version. The exit code is the same with or without --json. yodel mcp serves the read-only commands to a coding agent, with these schemas: Set up with a coding agent.