Leed Partial Index

You saw a {{> leed/something }} in a template and you want to know three things: what it is, whether you are allowed to call it, and where it is explained. This page answers all three, for all 54 partials Leed injects into src/_includes/leed/ on every build.

Every one of them follows the ordinary naming rule — the partial’s name is its path under src/_includes/ with .hbs stripped — so leed/docs/header/brand is the file src/_includes/leed/docs/header/brand.hbs during the build, and nothing else. There is no registry and no special casing of the leed/ prefix; the namespace exists only because that is the directory Leed’s files land in. Writing Your Own Partials covers the same rule for your own files.

The three statuses

Every row below carries one of three statuses, and they mean precisely this:

The nine you can use

The complete index

Fifty-four files, in path order, grouped by directory. The counts add up: 5 + 3 + 3 + 2 + 29 + 12 = 54. Re-run the enumeration against src/_includes/leed/ after a build if you need to be certain for a given release — the set moves with the site builder, not with your repository.

leed/ root — 5

leed/menu/ — 3

leed/metadata/ — 3

They are internal because leed/head already calls all three in order. Call one yourself and you emit a second copy of the same <meta> tags.

leed/components/ — 2

leed/docs/ — 29

Twenty-nine files render every documentation page. Four of them are yours to touch: social-icons and document-search are callable, and docs-header / docs-footer are the two eject sources. The other twenty-five are the shell’s own machinery.

Two rows invite a misreading. leed/docs/docs-header is not what renders on your documentation pages — it is a complete, working example header that exists so leed site eject docs-header has something real to copy. What actually renders is leed/docs/header/chrome wrapping one of the two header variants. And leed/docs/footer is the slot, while leed/docs/docs-footer is the default that fills it; the override replaces the second, never the first.

leed/api/ — 12

All twelve render the OpenAPI reference body inside leed/docs/api-article, and all twelve are internal. You will meet them only when you are reading generated API markup or tracing a class name in it.

How these files get there

None of these files is in your repository. They are copied out of the site-builder package into src/_includes/leed/ at the start of every build and serve, and deleted again when the run ends. They are gitignored, so git status never shows them.

Two consequences. An edit under _includes/leed/ never survives — the next build overwrites it and the cleanup deletes it, which is why a “my change did nothing” report almost always turns out to be an edit in that directory. And the supported way to change one of Leed’s own templates is an override, not an edit: three of the fifty-four are starting points that leed site eject copies into your repository for you, described at Leed Site Eject, with the render-time contract at Overriding Leed Templates. Which directories in your clone are yours and which Leed rewrites is mapped at Editable and Read-Only Files.

Helpers have their own parallel index — everything you can call between the braces rather than after {{> is at the Helper Index.