title: Get Started
shell: standard
components:
- type: header
title: Get Started
eyebrow: 5 minutes
subtitle: Install, init a site, add pages, add freshness, set up agent workflows. Adopt each layer when you need it.
- type: section
eyebrow: Install
heading: Get the binary
components:
- type: markdown
body: |
kazam is a single self-contained Rust binary. No runtime, no Node,
no Python. Pick whichever install method is convenient - all three
land the same binary on your `PATH`.
- type: tabs
tabs:
- label: Homebrew
components:
- type: markdown
body: |
Easiest on macOS / Linux. Pulls from the `tdiderich/tap` tap.
- type: code
language: bash
code: |
brew install tdiderich/tap/kazam
kazam --version
- label: cargo install
components:
- type: markdown
body: |
Works on any system with a Rust toolchain. Installed to
`~/.cargo/bin/kazam`.
- type: code
language: bash
code: |
cargo install kazam
kazam --version
- type: markdown
body: |
**Bleeding edge:** install straight from `main` to pick up
unreleased fixes.
- type: code
language: bash
code: |
cargo install --git https://github.com/tdiderich/kazam
- label: From source
components:
- type: markdown
body: |
For development or if you want to pin to a specific branch
or commit.
- type: code
language: bash
code: |
git clone https://github.com/tdiderich/kazam
cd kazam
cargo build --release
cp target/release/kazam /usr/local/bin/kazam
- type: section
eyebrow: Step 1
heading: Init a site
components:
- type: code
language: bash
code: |
kazam init my-site
cd my-site
kazam dev .
- type: markdown
body: |
`kazam init` writes a `kazam.yaml`, an `index.yaml`, and a minimal nav.
`kazam dev` starts a local server with live reload - edit a YAML file,
the browser updates. That's the authoring loop.
- type: callout
variant: info
title: Site shape
body: "Every `.yaml` file becomes a page. Subdirectories become URL paths. One `kazam.yaml` at the root holds site-wide config: name, theme, nav."
- type: section
eyebrow: Step 2
heading: Add pages
components:
- type: markdown
body: |
A page is three keys: `title`, `shell`, and `components`. Drop a new
`.yaml` in the folder and it builds automatically.
- type: code
language: yaml
code: |
title: Onboarding Guide
shell: standard
components:
- type: header
title: Onboarding Guide
subtitle: Everything a new hire needs in week one.
- type: markdown
body: |
## Day 1
- Tool access: request in #it-help
- Slack channels to join: #team, #eng, #incidents
- type: callout
variant: info
title: Questions?
body: Ping your manager or post in #onboarding.
- type: markdown
body: |
Build when you're ready to ship:
- type: code
language: bash
code: |
kazam build . --out _site
- type: callout
variant: info
title: More authoring detail
body: The authoring guide covers shells, components, and kazam.yaml config in full.
links:
- label: Authoring guide →
href: about.html
variant: secondary
- type: section
eyebrow: Step 2b
heading: Shape rules, guidance that warns
components:
- type: markdown
body: |
Layout components (graph, pipeline, grid, box, chart and friends) carry shape rules:
small checks like "past 6 graph nodes, pin a row on every node" or "five capabilities per
pipeline stage is the ceiling". `kazam validate` and `kazam build` run them on every
page and report **warnings**. Warnings never fail a build; they tell the author, or the
agent, what to fix. Errors are reserved for pages that cannot render.
The rules, a curated example, and use-when notes for each component live in
`schema/components.json` and come out of `kazam sdk emit-agents` (the component
reference agents read) and `kazam sdk emit-mcp` (tool descriptions and per-component
slices for an MCP host). Add a component with guidance and every agent surface updates
on the next regenerate.
Sites can add their own rules in `kazam.yaml`:
- type: code
language: yaml
code: |
# kazam.yaml
shape_rules:
- component: markdown
warn: words(body) > 300
say: Split long prose into a section with a heading, or pull structure into a table.
- component: graph
warn: nodes > 10
say: Our decks cap graphs at 10 nodes. Split it.
- type: markdown
body: |
Expressions: `nodes > 6`, `!all(nodes, row)`, `any(nodes, width > 160)`,
`words(body) > 120`, `stages[*].capabilities > 5`, `has(context)`, joined with
`&&`, `||`, `!`. Array names compare by length. Add `severity: error` to a rule to make
it fail the build.
- type: section
eyebrow: Step 3
heading: Add freshness metadata
components:
- type: markdown
body: |
Any page with a real owner and a review cadence should declare it.
kazam turns this into a build-time banner (yellow if due soon, red if
overdue) and includes it in the build report.
- type: code
language: yaml
code: |
title: Onboarding Guide
shell: standard
freshness:
updated: 2026-05-01
review_every: 90d
owner: hr@example.com
sources_of_truth:
- label: Notion - HR onboarding doc
href: https://notion.so/your-page
- label: "Linear: Onboarding project"
href: https://linear.app/your-co/project/onboarding
components:
...
- type: markdown
body: |
Every build reports stale pages and writes `_site/stale.md`. Hand that
file to your agent to refresh them.
- type: code
language: bash
code: |
kazam build .
# _site/stale.md lists every page past or approaching its review deadline
- type: callout
variant: info
title: Full freshness reference
body: Banner variants, build report format, status computation, and the agent workflow pattern.
links:
- label: Freshness guide →
href: freshness.html
variant: secondary
- type: section
eyebrow: Step 4
heading: Use prompt templates
components:
- type: markdown
body: |
kazam ships standardized prompts for the content lifecycle. Print one
to give your agent a consistent starting point.
- type: code
language: bash
code: |
kazam prompt show migrate # move existing content into YAML pages
kazam prompt show add-page # scaffold a new page from source material
kazam prompt show refresh # update a stale page from its sources of truth
kazam prompt show audit # review a page for accuracy and gaps
kazam prompt show review # editorial review - tone, structure, completeness
- type: markdown
body: |
Each prompt is designed to be copied into your agent session or piped
directly. They reference the kazam schema and freshness conventions so
the output is valid YAML.
- type: section
eyebrow: Step 5
heading: Set up the agent workspace
components:
- type: markdown
body: |
If you're using an AI coding agent on the same repo that holds your
kazam site, the workspace layer gives it a persistent codebase index,
task tracking, and a visual board. It's the engine that makes
agent-driven content management efficient.
- type: code
language: bash
code: |
kazam workspace init --agent claude
- type: markdown
body: |
That indexes the codebase, installs git hooks, and writes the agent
rules file. Open the board in a separate terminal while the agent works:
- type: code
language: bash
code: |
kazam board
- type: callout
variant: info
title: Workspace guide
body: Anatomy index, task tracking commands, benchmarks, corrections, and the visual board - all covered in the workspace reference.
links:
- label: Agent Workspace →
href: workspace.html
variant: secondary
- type: section
eyebrow: MCP server
heading: Let agents read, write, and annotate directly
components:
- type: markdown
body: |
`kazam mcp` starts an MCP server that exposes your site to AI agents.
Eight tools: `read_page`, `list_pages`, `search`, `get_config`, `write_page`,
`annotate_page`, `list_annotations`, `update_annotation`.
**Local (stdio)** - for Claude Code, Cursor, or any agent on the same machine:
- type: code
language: bash
code: |
kazam mcp --allow-writes
- type: markdown
body: |
**Remote (HTTP)** - serve over a network so your whole team's agents can connect:
- type: code
language: bash
code: |
kazam mcp --transport http --remote --token $KAZAM_MCP_TOKEN --port 8080 --allow-writes
- type: markdown
body: |
The `--local` flag (default) binds to 127.0.0.1. The `--remote` flag binds to
0.0.0.0 and requires a bearer token via `--token` or `KAZAM_MCP_TOKEN` env var.
The HTTP transport speaks the same JSON-RPC protocol over POST requests with CORS
support. Put it behind a reverse proxy (Caddy, nginx) for HTTPS.
See the [MCP reference](/mcp.html) for Claude Code config, Claude Desktop
setup, team deployment, and the proxy script for non-technical users.
- type: section
eyebrow: Step 6
heading: Annotate from calls and meetings
components:
- type: markdown
body: |
Annotations capture human context that data sources miss - competitive intel,
timeline changes, corrections from customer calls. They live as sidecar YAML
files, not embedded in the page.
- type: code
language: bash
code: |
kazam annotate customers/acme.yaml "evaluating Wiz alongside us" \
--section competitive --author tyler
- type: markdown
body: |
Annotations render inline at build time with age indicators and status badges.
When an agent refreshes a page, it reads pending annotations as the
highest-priority source and marks them `incorporated` after use. The 14-day decay
window ensures nothing sits unreviewed.
The same annotation tools are available via MCP - `annotate_page`,
`list_annotations`, `update_annotation` - so agents can write annotations
programmatically during their workflows.
- type: callout
variant: info
title: You're set
body: "From here: the authoring guide for page structure, the freshness reference for staleness tracking, the workspace guide for agent setup, and the components catalog for every primitive."
links:
- label: Authoring guide →
href: about.html
variant: primary
- label: Freshness →
href: freshness.html
variant: secondary
- label: Components →
href: components/index.html
variant: secondary