CLI Command Reference

This is the index. It shows the whole leed command tree, the options that apply everywhere, and where each command’s own flags are written up. Every command in the tree accepts --help, at any depth — leed site commit --help prints that command’s synopsis and options — so this page exists to answer the other question: which command, and where is it documented.

The command tree

Every group and leaf that ships. * marks the ones hidden from --help. For the live list, with every option, run leed schema --json; to find a command by what you want to do, run leed cli search "what you want to do".

leed
├── auth
│   ├── login
│   ├── logout
│   ├── status
│   ├── default
│   ├── rotate
│   └── reset
├── login                       alias of `leed auth login`
├── site
│   ├── init
│   ├── build
│   ├── validate
│   ├── commit
│   ├── push
│   ├── list
│   ├── eject
│   ├── upload              *
│   └── notify-cms          *
├── import
│   ├── openapi
│   ├── markdown
│   ├── html
│   ├── status
│   ├── apply
│   └── clean
├── page
│   ├── sync-state
│   ├── review
│   ├── get
│   ├── create
│   ├── update
│   ├── publish
│   ├── schedule
│   ├── stamp
│   └── frontmatter get | set
├── asset
│   ├── list | get | set
│   ├── export
│   └── upload
├── settings
│   ├── pagetype      list | get | create | set
│   ├── label         list | get | create | set
│   ├── autolink      list | get | create | set | delete | reorder
│   ├── searchindex   list | get | create | set
│   ├── company       get | set
│   ├── form          list | get | create | set | publish | delete
│   ├── shortcode     list | get | create | set
│   ├── user          list | get | set
│   ├── oidctrust     list | create | delete
│   ├── path          list | resolve | create | delete
│   ├── menu          list | get | set | add | remove | move | reorder | set-menu
│   ├── brokenlinks   list
│   ├── pending
│   └── publish
├── deployments
│   ├── status
│   ├── promote
│   └── retry
├── contacts
│   ├── export
│   └── import
├── mcp
│   └── add
├── schema
├── cli
│   └── search
├── self-update
├── completion              *
│   ├── install             *
│   └── uninstall           *
├── completion-server       *
└── __credential            *   git’s credential helper for the content repository

Global options

These are declared on the root program, so every command accepts them however deeply nested it is.

Every command that changes something also takes --dry-run, which reports what it would do and changes nothing — leed site commit, push and validate --reset, the settings, asset, page, contacts and import verbs, and leed mcp add among them. leed schema --json says, per command, whether it has one.

--json has its own page: the envelope, the fifteen error codes, the exit classes and the rules for consuming them are on machine-readable output.

Reading the logger filter

Channels are named leed:<area>:<level> — leed:app:error, leed:site:build:info, leed:auth:debug — and -n takes the same wildcard patterns the debug package uses. The default, *:error, matches every :error channel from every library that uses debug, which is why a quiet run still tells you when something breaks. --verbose is a shorthand and nothing more: it is precisely -n leed:*, every level of every Leed channel. Pass both and they combine, as leed:*,<your filter>.

Every leed:* channel writes to stderr, in both human and JSON mode. They are diagnostics, not a command’s answer, so leed site list > types.txt captures the table and none of the logging.

Eleventy’s internals are a separate matter, because Eleventy loads its own copy of debug and reads the raw DEBUG variable:

DEBUG=Eleventy* leed site build

An inherited DEBUG is merged into the CLI’s own filter rather than replacing it. And once the namespaces are registered, the CLI deletes DEBUG from the environment whenever no Eleventy channel ended up enabled — a deliberate performance workaround, because Eleventy checks that variable to decide whether to run character-set detection on every template it reads. The practical consequence is that DEBUG=* does not behave the way you would expect from other tools. Use -n for Leed channels and DEBUG=Eleventy* for Eleventy’s.

leed auth

Six subcommands managing the sessions the CLI holds — one per environment and company — plus the two GitLab tokens your site checkout depends on. None of them needs a site directory except rotate and reset, which are scoped to one site.

What the session actually is, where it lives and how it stays alive is the subject of CLI authentication.

leed login

leed login

A top-level alias for leed auth login, with identical flags and identical behavior. It reports its own name — login, not auth.login — in its --json document, so a consumer can match the command line it actually ran.

leed site

Run these from your site folder — the one holding leed.config.json — or from raw-content/. The CLI searches those two levels and no further.

leed site generate, leed site import and leed site create-page-type are gone: importing content is the leed import group below, and a page type is created with leed settings pagetype create.

leed site itself declares three hidden options — -l, --location, -c, --customer and --ci — which exist so a CI build can point the CLI at a checkout without a leed.config.json. They read BUILD_SITE_LOCATION, BUILD_CUSTOMER and CI respectively, and are documented alongside every other variable the CLI reads on leed.config.json, files and environment.

leed schema

leed schema --json
leed schema site.list --json
leed cli search "publish a form"

The CLI describing itself, in stages. leed schema is the index — every command in one line with whether it mutates, is idempotent, reaches the network and has a --dry-run, plus the shared options, envelope, error codes and exit codes described once. leed schema <group> narrows the index to one group, and leed schema <command> returns one command’s document: its arguments, its options, the JSON Schema of its result and the next steps it can name. A name is accepted dotted (site.list) or as an argv path (site list), and --command still works as an alias. It is built from the live command tree of the binary running it, so it cannot describe a version other than the one you have.

leed cli search is the way in when you do not know the name: it matches your own words against every command’s name, description, options and positional arguments, so page id finds the commands that take a page id. Both are documented under discovering the CLI.

leed import

Content into the CMS, from whichever source it is in: stage a set for review, build it, then upload it. Run from your site folder.

Every verb takes --page-type-id. The workflow and its guards are on importing an OpenAPI spec, and the flags on OpenAPI commands.

leed page

Page content from the command line. Every verb takes --env and --company.

create and update take --source-id <sha> to record the commit the content was checked against in the same write. If the CMS takes the body but not the tag, the result is a partial success that names the leed page stamp to run.

leed asset

leed settings

CMS settings, one noun at a time: pagetype, label, autolink, searchindex, company, form, shortcode, user, oidctrust, path, menu and brokenlinks, each with the verbs shown in the tree above. Ids are positional — leed settings searchindex get <searchIndexId> — and field flags are generated from the setting’s own schema. Changes are staged until published: leed settings pending lists what is unpublished and leed settings publish [ids] | --all publishes it, one unit at a time, exiting non-zero if any unit failed. A user’s role can only be changed by an Administrator, with leed settings user set --role, and oidctrust create needs --yes.

leed deployments, leed contacts and leed mcp

Maintenance commands

leed self-update

Checks the registry for a newer release and installs it, bypassing the 24-hour throttle the automatic check obeys. With nothing to do it prints “Already up-to-date, no updates required.”; otherwise it prints “Update complete!” once bun install -g has finished. The automatic update path — which installs rather than merely notifying, and how to suppress it in a script — is described under installing the Leed CLI.

leed completion install
leed completion uninstall

Shell tab completion for bash, zsh and fish, detected from SHELL. The candidate list is generated from the live command tree, so it never goes stale as commands and flags change. Install prints “Shell completion installed. Restart your terminal to activate.” Both commands are hidden from --help and both are fully supported.

Commands you will not run yourself

leed site upload and leed site notify-cms exist for the build pipeline. upload uploads a built worker version and reports the build result back to the CMS; notify-cms posts a committed change set to POST /api/site/pushed, and is what leed site push calls in-process at the end of a successful push. upload also works locally if you have a reason to run it. Both retry the CMS call with exponential backoff on timeouts and transport errors, and both exit with the CLI’s shared exit classes — including upload’s non-zero exit with ok: true when the worker was uploaded but the callback was not delivered. See CLI troubleshooting and exit codes for the full table.

completion-server is invoked by the shell hook that leed completion install writes, on every Tab press. It is outside the --json envelope contract: its stdout is the shell’s candidate list, in a format the shell defines, whatever --json or LEED_JSON say. __credential is the other one — git runs it as the credential helper for your content repository, and it answers git, not a person.

Quick reference

Every command that appears in --help, in one place.

Workflow context for these commands is in local development and validate, commit and push; if a command has failed and you are here looking for the message, start at CLI troubleshooting and exit codes.