Install

Goal

One command, one workspace, and a map of everything it contains. A workspace is the folder you work in: it holds one or more templates and declares the toolchain they share.

Node ^22.13.0 || >=24 is required. An unsupported Node fails the install outright rather than warning and carrying on — the workspace ships an .npmrc that sets engine-strict, because npm’s default is a warning, and an install that “succeeds” on the wrong Node surfaces its failure much later, at the lint stage of a check run, far from the cause.

npm create @homepages/workspace@latest my-workspace

It takes half a minute or so — it installs the kit, the CLI, the lint preset and their toolchain into the new folder, and runs git init there. The name is a positional argument, so nothing prompts you. On success it prints:

Created my-workspace/

  cd my-workspace
  npm run dev        # preview templates/starter
  npm run check      # typecheck + lint + validate

templates/starter/sections/main/ is a skeleton to build on — add a template or a
section by copying a folder that already works and renaming its key.
The authoring guide: node_modules/@homepages/template-kit/guide/ (start at llms.txt).

That last line is this corpus, shipped inside the tarball you just installed. The same pages are on the docs site.

What got created

Sixteen files, and nothing else you did not ask for:

./AGENTS.md                                    # workspace instructions for a coding agent
./CLAUDE.md                                    # the same, for Claude Code — a sibling file, not a copy
./eslint.config.mjs                            # re-exports the kit's lint preset; three lines long
./.gitattributes                               # pins the tree to LF, so a template hashes the same everywhere
./.gitignore                                   # node_modules, the dev cache, generated maps, logs
./.npmrc                                       # engine-strict — the Node check described above
./package.json                                 # the Node range, three scripts, and the pinned toolchain
./package-lock.json                            # the exact versions installed; ships in your submission
./README.md                                    # this workspace's own short reference
./templates/starter/sections/main/fixtures.ts  # sample content the section previews against
./templates/starter/sections/main/Renderer.tsx # the markup — a pure server component
./templates/starter/sections/main/section.ts   # what content the section has, and how AI fills it
./templates/starter/template.ts                # composition — which sections, on which pages
./templates/starter/theme.css                  # generated from theme.ts; never hand-edited
./templates/starter/theme.ts                   # the template's design tokens
./tsconfig.json                                # extends the kit's tsconfig; four lines long

Read it as three layers.

The workspace root is toolchain, not content. package.json gives you three scripts — dev, check and pack — and pins every tool the templates below it share, so a second template needs no setup of its own. The dotfiles exist to make failures early and identical on every machine: the wrong Node fails at install, and line endings cannot change a template’s content hash.

templates/starter/ is one template. template.ts is its composition — the sections it is built from, and the pages they are laid out across — and theme.ts its design tokens, from which theme.css is generated.

templates/starter/sections/main/ is one section, and the three files there are the whole authoring contract: section.ts, Renderer.tsx, fixtures.ts. That folder is a skeleton to build on, not a worked example — it has a single text slot, so that every part of the contract is present and none of it is buried. For a real, multi-section template to read alongside it, Read the starter points to a separate scaffold you can pull down whenever you want it.

The two agent files are for the coding agent you may be working with, not for the platform. README.md, CLAUDE.md and AGENTS.md are yours to rewrite; nothing reads them but you.

Verify

The create command exits 0. Then, from inside the new folder:

cd my-workspace
find . \( -path ./node_modules -o -path ./.git \) -prune -o -type f -print | sort

The output is the sixteen paths mapped above, in that order. Both node_modules and .git are pruned — the scaffolder runs git init, so without pruning it the listing also carries every file that command just wrote under .git/.

The three files under templates/starter/sections/main/ are the ones to check by name: Renderer.tsx, section.ts and fixtures.ts. All three, every time.

Next

First render — start the dev server and watch that section render.