Quick Start for Developers

In about thirty minutes you will have the leed CLI installed, your site’s repository cloned and rebuilding on http://localhost:8080 as you type, and one template change live on your preview site. This is the condensed happy path; each step links to the page that covers it exhaustively. One thing is worth checking before you start, because it is the only part you cannot fix yourself: your account needs developer access, and an administrator grants it.

If you want the architecture before the commands — what the repository is, and how it relates to the CMS — read How Leed Fits Together first. Otherwise, start here.

Before you start

Three things:

• Git 2.31 or later. The installer checks for it and stops, saying how to install or upgrade it, if it is missing or older.
• Bun 1.1.0 or later. The CLI runs on Bun. If it is absent or out of date the installer offers to install or update it for you; declining ends the install.
• Developer access. This is an override an Administrator grants by ticking the Developer checkbox next to your name on Settings → Team Members. Without it, setup signs you in and then stops with an HTTP 403 when it fetches your site repository’s credentials to clone it — an authorization failure, not a bug in your setup.

The installer supports macOS, Linux and WSL. Sign-in always prints the approval URL and opens your browser where it can — always on macOS, and on Linux and WSL only where a display is available — so on a headless machine you paste the URL into a browser elsewhere.

An Administrator grants developer access with the Developer checkbox described in Billing and Developer Access — the same page covers what that override does and does not unlock.

1. Get your install command

In the CMS, open the profile menu — your avatar at the bottom of the left rail — and choose Developer Setup. The dialog shows your prerequisites and your install command:

curl -fsSL https://app.leed.ai/install | bash

2. Run the installer

Paste the command into a terminal. It runs unattended apart from a few prompts, and here is what it does with your answers:

1. Checks Git and Bun, offering to install or update Bun if needed.
2. Installs the CLI globally with Bun, as @leed-ai/cli from the public npm registry, and makes sure a new terminal finds leed on your PATH.
3. Hands over to leed setup, which signs you in. If this machine already holds a saved login, it asks which one this site is for, or whether to sign in again; there is no default. A new sign-in uses a device-authorization flow. It prints a code formatted like ABCD-1234 and the app.leed.ai/auth/device approval URL, and opens your browser where it can. Check that the code on screen matches the one in your terminal, approve it, and the terminal continues. If you belong to several companies, the approval page asks which company to authorize. You have five minutes before the code expires.
4. Asks where to put your sites, defaulting to ~/leed. A site already set up on this machine is found and kept, so running the installer again asks nothing it already knows.
5. Runs leed site init, which clones your site repository into ~/leed/<your-domain>/raw-content, checks out the staging branch, records the site in ~/.config/leed/sites.json and installs Font Awesome Free — this is the step that needs developer access.
6. Offers, once each, a VS Code workspace for the site, when VS Code is installed, and the Leed plugin for Claude Code, when the claude command is installed without it. If you use Claude Code only in an IDE or in the Code tab of the Claude desktop app, there is no claude command to install it with, so setup prints the two /plugin commands to run there instead.

When it finishes, confirm the install:

leed --version

Every installer step in detail, the credentials file it writes, self-update and shell completion are in Installing the Leed CLI; how the device login works, where the token lives and how it refreshes is CLI Authentication.

3. Build and serve

cd ~/leed/<your-domain>
leed site build --serve

The first build renders your whole site — templates, your published CMS content, Tailwind CSS and the search index — and then starts a local server at http://localhost:8080. Leave it running. Edits to templates, partials and Tailwind files rebuild the affected pages automatically; refresh the browser to see them. Ctrl+C stops the server and cleans up.

Templates are Handlebars, so this is the moment How Templates Work starts paying for itself, with every helper you can call from one listed in the Helper Index (A–Z). Styling is Tailwind driven from site.config.css — see How Styling Works.

These are the flags worth knowing on day one:

That last column is not trivia. Read the --debug trap below before you settle into a habit.

The full watch loop, the remaining flags and a worked session are in Local Development; every flag has a row in leed site build.

4. Make a change you can see

With the server running, open your site folder and change something obvious. A layout under src/_layouts/ or a partial under src/_includes/ is a good first target: change a heading, add a class, save the file, and watch the terminal rebuild and the browser show it.

You are looking at a normal Eleventy project with Leed’s conventions on top. Layouts and partials are .hbs, styling is Tailwind under tailwind/, static files sit in src/static/, and your CMS content is injected at build time rather than living in the repo as source you edit. What is actually in the folder you just cloned is described in Your Site Repository — and some of it you may not edit at all, which Editable and Read-Only Files enumerates before validation does it for you.

5. Validate, commit and push

Shipping is four commands, always in this order, because each one gates the next:

leed site validate            # every changed file is allowed
leed site build               # a plain build — no --serve, no --debug
leed site commit -m "Refreshed the footer layout"
leed site push

There is no git add: the CLI stages your changes itself. Commits are only accepted on the staging branch, which is where leed site init left you, and the repository’s git hooks reject a bare git commit or git push so the checks cannot be skipped by accident.

Your push is traced end to end in What Happens After You Push, and the promotion step is Promoting Preview to Live. The four-step contract itself, the staging-only rule and the automatic rebase are in Validate, Commit and Push; if a command exits non-zero, CLI Troubleshooting and Exit Codes has every code and message.

Here is the whole loop, including the two edges that catch people out — the plain build being a gate rather than a step, and the push exiting to preview rather than live:

flowchart LR
  Edit["Edit files under src/"] --> Serve["leed site build --serve"]
  Serve --> Review["Review at localhost:8080"]
  Review -->|Not there yet| Edit
  Review -->|Happy with it| Validate["leed site validate"]
  Validate --> Build["leed site build<br/>plain, no flags"]
  Build -->|Gate — commit refuses without a recorded build| Commit["leed site commit -m ..."]
  Commit --> Push["leed site push"]
  Push --> PreviewSite["Preview site"]
  PreviewSite -.->|Promote on the Deploy screen| LiveSite["Live site"]

The --debug trap

This one deserves its own heading because it costs people an afternoon.

leed site commit refuses to run unless there has been a successful build since your last edit. It checks a recorded build timestamp — and --debug builds are not recorded, because their output is unminified and therefore not what would ship. So a developer who has settled into leed site build -d will be told, forever, to run a build they have just run:

You must run the following command before changes can committed: leed site build

Let Claude Code drive it

leed site init installs more than the repository: it also writes the git hooks that stop the checks on this page being skipped. It does not write a VS Code workspace or any Claude Code skills into the project. leed site vscode writes the VS Code workspace, with tasks for every command on this page, and leed setup offers it once. The skills come from the Leed plugin for Claude: in Claude Code — in the terminal, in your IDE, or in the Code tab of the Claude desktop app — run /plugin marketplace add leed-ai/ai-plugins and /plugin install leed@leed, then /leed:setup, which checks the CLI, your sign-in and your site and connects Claude to your CMS. Chat in the Claude desktop app is not enough here: it has no terminal, so it cannot run the commands on this page. Among the plugin’s skills are site-builder, which knows Leed’s helpers, partials and conventions for building layouts and styles; site-preview, which handles builds and the dev server; and site-publish, which runs the validate → build → commit → push sequence including its failure and rebase paths, then checks the result on your preview site. /leed:create blog and /leed:create documentation add a whole blog or documentation set in one step.