sitekit has one core idea: you trust the agent with the writing, but you want the result to look like it was designed deliberately for you — and to stay that way. Everything in the tool serves that split.

​
Three roles

The agent authors

Reads the guidance, writes the HTML, CSS, and TypeScript, and calls sitekit. All judgment and creativity live here.

The CLI aligns

Tells the agent what to build (the playbook), what counts as correct (verify), and how to ship (deploy). It never writes content.

Providers act

Cloudflare hosts, Stripe charges, Resend mails. sitekit shells out to them through a small provider interface.
A load-bearing consequence: sitekit never calls an LLM as its own judgment. It records, scaffolds, verifies, and reports. The agent is the only thing that authors or decides. That boundary holds across every loop.

​
The enforcement contract

This is the heart of the promise: sitekit is rigid on a fixed set of constraints; the agent is free on everything else. The verify loop encodes the rigid column. Everything else is the agent’s discretion.
Rigid — sitekit enforcesFree — the agent decides
The voice’s banned phrasesSection order within a page
The style pack’s tokens (:root block)Component patterns and libraries
The style pack’s fonts and motion guardLayout choices within a shape
The shape’s required sectionsCopy and content (under the voice)
The shape’s content schemaImagery selection (within the shape)
The playbook marker’s presence and integrityAnything the marker doesn’t bind
The mobile-first floor (viewport, tap targets)
The rigid column is what sitekit verify checks. The free column is where the agent does the actual design work — it just can’t approximate the rigid column from memory, because every emitted page carries the real guidance inline.

​
The verify loop

sitekit verify is the central primitive — not a final gate you run once, but the loop you run after every meaningful change. It runs a multi-layer pipeline: pre-flight, schema, structural and coherence checks, and a shape-specific check auto-discovered from each page’s bound shape — around fifty checks in all. 
sitekit verify            # full pipeline at the workspace
sitekit verify <file>.html # just one page (file mode)
sitekit verify --strict   # warnings block too (the deploy gate)
Every check returns a structured fix_hint the agent can act on directly. The workflow is: run, read the hint, fix, repeat — until it’s clean.

The visual pass

sitekit verify --visual renders each page at phone, tablet, and desktop (light and dark) and hands the agent the screenshots to judge against the style’s design intent. It’s the default closing step on a fresh build when Playwright is installed.

​
The playbook marker

Every page sitekit emits carries an inline HTML comment — the marker — recording the exact composition it was built against: 
<!-- sitekit-playbook: { "voice": "editorial", "style": "editorial", "shape": "landing" } -->
The marker is load-bearing. sitekit verify reads it to know which packs to check against. A future agent session reads it to recover the composition from the file alone — no central registry, no lost context. Never strip it.

​
Hard-bake

Content binds into HTML at author time. There is no runtime template engine on the deployed site — a placeholder like {{messaging.tagline}} resolves to a literal string in the shipped artifact. The deployed result is plain static files (HTML, CSS, a small Worker) you fully own. That’s why a sitekit site keeps serving even if you stop using sitekit.

​
Where this leads

Playbooks

The composition the rigid column is built from.

The four workflows

Build, maintain, experiment, evolve — the same three roles each time.