Kazam – my answer to static sites in the age of Claude being my main author

I built kazam after reaching for Next.js one too many times to ship an internal static site that renders a dozen pages once in a while.

Markdown was never pretty enough since I wanted cards, charts, etc. Everything else (Next.js, Docusaurus, Mintlify) felt bloated for a site that updates occasionally and just needs to live in git and render cleanly.

kazam is the middle path: a handful of YAML files, zero npm dependencies, one Rust binary, themed static HTML out. No framework, no webpack, no runtime JS. `kazam dev` reloads on save; `kazam build --release` emits minified HTML you can drop on any static host. Because the source is YAML in a git repo, change history is just `git log`.

I went this path because I wanted something easy for agents to edit since that's how a lot of my workflows are built at this point. YAML is just as simple as markdown, but it allows for you to build a component library to align to the YAML schema.

That's exactly what large language models produce correctly on the first try. Every page of the docs site was written by Claude following the bundled `AGENTS.md` authoring guide. I expect agents to be the primary contributors to sites built with kazam going forward.

There's also `kazam wish deck`: you drop a folder of real context (notes, transcripts, prior decks, PDFs) and your agent — Claude, Gemini, Codex, or OpenCode — reads it and writes a populated deck for you. kazam does no file parsing; the agent does. Or run `--yolo "about me"` to skip the folder entirely and let the agent invent the whole thing from its context about you (see my demo for that output).

Demo (3 min): https://www.loom.com/share/528d98fef421443497753af86cd7d737 Docs + live examples + source: https://tdiderich.github.io/kazam/ Repo: https://github.com/tdiderich/kazam

Feedback on the format, the components, or the ethos very welcome.

Happy to dig into any of the tradeoffs.