The Leed plugin for Claude teaches Claude Code how Leed works: how to build, preview and publish a Leed website with the leed CLI, change CMS settings, manage assets, add whole sections such as a blog or a documentation set, and keep your docs publishing with your releases. This page lists what the plugin installs and what each part is for. To install it, see Get Started with the Leed Plugin for Claude.
What the plugin installs
The plugin is one package, leed, from the leed marketplace (/plugin install leed@leed). It holds:
| Part | What it is |
|---|---|
| Skills | Fifteen skills: instructions, references and small scripts that tell Claude how to do one kind of Leed work. They are listed below. |
| A startup hook | A version check that runs when a Claude Code session starts. See The startup version check. |
| Recipes | The data /leed:create runs: each recipe’s page type, its steps in order, and the starter layouts and stylesheet it copies into your site. |
| Starter templates | The site-wide set site-onboarding uses: a site template, a header and footer on Leed’s menu builder, the brand theme and buttons, and the settings it applies. |
The skills drive the leed CLI, which /leed:setup installs. The plugin declares no MCP server of its own, so nothing connects when a session starts. Your company’s CMS server is added by leed mcp add --cms during setup, bound to your company (see Connecting to the Operator MCP), and the Leed documentation server is added only if you say yes when setup offers it.
Every Leed release publishes the plugin and the CLI with the same version number.
Skills you run by name
Four skills are commands you type. Each is safe to run again.
/leed:setup
Checks and installs everything Leed needs on this machine: Node 22 or later, git 2.31 or later and Bun; the leed CLI at the plugin’s version; a signed-in company and its site checkout; the CMS MCP server. It offers the Leed documentation MCP server once and remembers your answer, and asks before turning on plugin auto-update. It ends with a status table, one row per check. On a machine that is already set up it changes nothing. Run it first, and again whenever the startup check tells you to.
/leed:create
Adds a whole section to your site in one step from a recipe, creating the page type, its menus, search index and starter templates without duplicating anything that already exists. /leed:create on its own lists the recipes.
| Recipe | What it adds | Plan |
|---|---|---|
/leed:create blog | A posts page type at /blog/, with an article layout, a paged list of cards, and optional author and topic pages, styled from your brand tokens | Any |
/leed:create documentation | A documentation set at /docs/, with its left navigation menu, its search index and a welcome page as the starting page, and an optional one-line call to action above each page’s Previous/Next links | Any |
/leed:create recommendations | Leed’s recommendation cards under each post on the page types you choose (the blog by default), styled in your brand, with an offline preview for leed site build --serve | Growth and above |
/leed:create cta | Leed’s CMS-managed call to action: a cta.hbs partial and its slot in the layouts you choose and on the home page, so a call to action made in the CMS appears without a republish | Growth and above |
Below a recipe’s plan, /leed:create explains what the recipe adds and stops without writing a file or changing a setting. If a step fails, it reports exactly what it created, and running the same recipe again picks up from there.
/leed:review
Answers the comments people leave on a page in the Leed editor. After Claude has written a page, you read, edit and comment on it in the editor, then say “review the comments on <page>” or run /leed:review <page>. Claude reads every open comment thread in full and answers each with a tracked suggestion you accept or reject in the editor, then reports what it did for each comment, or why it changed nothing. It never edits a commented page directly and never resolves a comment. Every plugin skill that writes page content ends by handing the pages over this way.
/leed:docs-ci
Connects your product’s GitHub or GitLab repository to Leed so your docs publish with the release that ships the code they describe. It creates the Leed OIDC trust for your release pipeline, adds the release job to your own CI as a dry run first, and tells your agent which commit to stamp a docs edit with. It needs the Growth plan, the Content Publisher role and the CLI, and never commits or pushes. See Continuous Documentation.
Skills Claude uses on its own
The other eleven skills load when your request calls for them; you rarely need their names. Any of them can also be run by name as /leed:<skill>.
| Skill | Claude uses it when you |
|---|---|
site-onboarding | Ask Claude to build your new site. It interviews you about your business, proposes your pages, labels, menus and search, and once you confirm, sets up the menus, theme and fonts in the CMS and writes starter templates for your site template, header, footer and buttons. It hands blogs and docs to /leed:create and finishes by checking staging. Also /leed:site-onboarding. |
site-patterns | Build or review any template, layout, partial or stylesheet. Leed’s always/never rules for menus, forms, recommendations and calls to action, pagination, links, images, page lists, layouts, theming and dark mode, CSS layers and header height, so a site uses Leed’s built-in systems instead of hand-built copies. |
site-audit | Ask for an audit or review, or publish changed templates. It checks the site against the site-patterns rules and proposes a fix for each finding, naming the rule and the file and line. It only reads, and changes nothing until you say yes. |
site-builder | Change templates, layouts, partials, CSS or JavaScript, or write Leed Markdown content. It knows every Handlebars helper, Tailwind v4, Alpine.js, Font Awesome and the CLI’s conventions. |
site-preview | Want to see the site. It builds and runs the local preview server, and starts, restarts and stops it. |
site-publish | Publish site changes. It runs leed site validate, commit and push, then checks the result on your staging site against the live one (screenshots at desktop and mobile widths, console errors, broken links), and asks before promoting to production. |
site-settings | Need a CMS setting changed: page types, labels, autolinks, search indexes, forms, shortcodes, users, URL aliases, OIDC trusts, broken-link reports or your company’s general settings, with leed settings. It also creates internal page types (--type internal) for content such as a handbook or runbooks that must never reach the site, and knows that their pages are locked rather than published. |
site-assets | Need a file in the asset manager. It uploads local images, documents, audio and video with leed asset upload, which returns ready-to-paste Leed Markdown, and finds, edits and exports existing assets. |
site-design-import | Have designed your site in Claude Design. It turns the “Handoff to Claude Code” into your theme’s brand tokens, one layout per page type, CMS menus and assets, lists anything it could not map, and finishes with an audit and a staging check. It shows you the plan before changing anything. |
site-migrate | Want to bring existing docs to Leed from Docusaurus, MkDocs (Material), GitBook, Mintlify, ReadMe, VitePress or Nextra. Navigation becomes menus, pages become Leed Markdown, images go to the asset manager and old URLs become redirects, with a report of anything it could not map. |
site-sandbox-move | Have a sandbox site, built before you had an account, and now want it in Leed. It creates the CMS records the sandbox holds in dependency order, swaps every placeholder for the real id, copies your templates into your site and imports the content. Also /leed:site-sandbox-move. |
Skills that need your site’s checkout run their commands from inside it, and outside one they name the site explicitly: the CLI never assumes a site or a company for you.
The startup version check
The plugin and the CLI are released together and should always be the same version. When a Claude Code session starts, a hook compares the plugin’s version with leed --version. It is silent when they match. When they differ, it prints one line:
| The line says | Do this |
|---|---|
| the Leed CLI is older than the plugin | run /leed:setup, which installs the CLI at the plugin’s version |
| the Leed plugin is older than the CLI | run claude plugin update leed@leed (or /plugin marketplace update leed), then restart Claude Code |
| the two are different builds of one release | run /leed:setup, which installs the CLI at the plugin’s exact version |
The check is also silent when the CLI is not installed yet and whenever it cannot tell: no shell, or leed does not answer within a few seconds. It makes no network call and never blocks a session. leed self-update is not the fix for an older CLI, because it goes to the latest release and can overshoot the plugin.
What leaves your machine
The plugin itself sends nothing. Its skills send data off your machine only by running a command, a fetch or an MCP tool call that Claude Code asks you to allow first, unless you have already allowed it in your permission settings.
| Destination | What it receives | When |
|---|---|---|
| Your company’s Leed CMS MCP server | The CMS tool calls Claude makes and their arguments: page content, settings, assets | When Claude calls a CMS tool, after setup connects it |
The Leed documentation MCP server (leed.ai/mcp) | Documentation search queries | When Claude looks something up in the Leed docs, if you added it |
| The Leed CMS API and your site’s repository at Leed | Your sign-in; the settings, pages, assets, contacts, imports and deployments you read or change; your committed site changes; the files you upload | When a skill runs a leed command that talks to the CMS, pushes or uploads |
| Leed feedback on a blocked request | The ray id, method, path, status and time of a request Cloudflare’s firewall blocked, the command or tool name without its values, and at most 2 KB of the blocked body | When Claude reports a blocked request |
| The Leed installer, the npm registry, the Bun installer and Leed static assets | Download requests for the install script, the CLI and your site’s build packages, Bun, and web fonts or Font Awesome Free | When setup installs or updates something, or a build or init needs a font |
| Cloudflare (Wrangler usage metrics) | Wrangler’s anonymous usage metrics, unless you turn them off | When leed site build --wrangler runs a local Wrangler server |
| A Claude Design handoff bundle’s URL | A download request | When site-design-import imports a handoff and you agree to the download |
| Your own staging and live site | Page, stylesheet and script requests | When site-publish checks staging against the live site |
| Your GitHub or GitLab | Requests for the repository’s numeric id, default branch, CI file path and merge settings | When /leed:docs-ci reads your branch model, with your existing gh or glab sign-in |
The release job /leed:docs-ci writes into your CI calls Leed from your pipeline when a release ships, not from your machine.
How long Leed keeps it
What Claude writes to the CMS through these skills (pages, settings, assets, menus, users, authors and contacts) becomes your company’s data in Leed, and is kept until you change or delete it, or until the company is deleted. A blocked-request report is kept as feedback so Leed can find and fix the firewall rule. Leed’s privacy policy covers all of it. On your machine, the CLI keeps your sign-in, including your email, in ~/.config/leed/auth.json, and the sites you set up in ~/.config/leed/sites.json; leed auth logout removes the sign-in.