A shape names what kind of thing the agent is building. It’s the interpretive dimension of a playbook: a shape hands the agent a contract — required sections, a content schema, structural invariants — not a layout. The agent infers the actual layout from the topic, the active style, and the active voice, so a contact page for a roofer isn’t the same as a contact page for a SaaS, by design. 
sitekit shape list

​
Atomic vs compound

  • Atomic shapes produce one page (or one element). Each ships a content schema and a shape-specific verify check.
  • Compound shapes are page-list recipes — one sitekit run emits a whole set of pages that share a voice, style, and palette.

​
Page shapes

page (the ephemeral one-off primitive), landing, pricing, faq, contact, legal, about, generic-page — plus the app-shell shapes auth-signin, auth-verify, account, and app-home.

​
Element shapes

For a single section rather than a whole page: hero, features, cta, proof, faq-block, form, site-header, site-footer.

​
Compound shapes

  • marketing-site — seven pages: home, solutions, pricing, FAQ, contact, and two legal pages.
  • platform — eight pages: the marketing surface plus the signed-in app shell (signin, verify, account, app home). Covered below.

​
The platform shape

platform is the SaaS-app starting point. One command scaffolds a public marketing surface, a logged-in app shell, and the account/auth/billing backend in a single move: 
sitekit run --shape=platform
It emits the eight pages and activates the auth + checkout backend (Tiers B and C) together. The handlers ship as SITEKIT:TODO stubs that you author — sitekit scaffolds the standard (pages, schema, migration, contract); the agent writes the handler logic and the in-app product. The opinionated default is magic-link auth, a single user, and Stripe subscriptions; the agent extends it toward teams or passwords as needed.
Because platform declares requiresTiers: ["B","C"], running it arms a guard that keeps verify honest about whether those tiers are actually active. Read the platform-shape reference in the bundled skill before driving this shape.

​
The tier ladder

Every site sits on one of three additive tiers. Each tier implies the ones below it.
1

Tier A — marketing only

The default after sitekit init: a workspace plus a Cloudflare Worker with a health endpoint. Pages are emitted on demand with sitekit run.
2

Tier B — add checkout

sitekit add checkout scaffolds Stripe Checkout, a webhook handler, Resend email, and a pricing catalog.
3

Tier C — add auth

sitekit add auth scaffolds magic-link auth (JWT + Cloudflare D1), signin / verify / account pages, and middleware. Activating C also activates B.
Secrets are set over stdin, never hardcoded: 
echo "$STRIPE_SECRET_KEY" | sitekit secrets set STRIPE_SECRET_KEY

​
Addons

AddonRequiresCommand
customer-portalTier Bsitekit add customer-portal
promo-codesTier Csitekit add promo-codes
After each add, run sitekit verify to see what’s left to implement, and read the operational prose sitekit scaffolds into the site’s playbook/ notes.

​
Valences

A valence is the optional fifth slot — a soft overlay that makes a shape more appropriate to a vertical without touching voice or style. Bundled: local-service, saas, personal-brand. It’s pure guidance; nothing fails verify if the agent ignores it. See Playbooks.

​
Add a page later

Sites aren’t frozen to their starting page set. To add real estate after the fact: 
sitekit site add-page <slug> --shape=<name>
This records the new page in the site’s compound contract and emits its scaffold. The agent authors the body and wires the nav link; sitekit verify flags the page as unreachable until it’s linked. See Workflows → Add a page.