AI

Most frameworks give AI tools too much freedom. State can live anywhere, effects can happen anywhere, and there’s no canonical structure to follow. The result is generated code that works but doesn’t hold up.

Foldkit’s architecture changes this. The Elm Architecture enforces a rigid, yet expressive structure (Message → update → Model → view → Command) where every piece has a canonical shape and a canonical place. The same constraints that make your code correct make it machine-legible.

An AI that understands this loop can reason about the entire program as a state machine. It can generate structurally valid code, not just syntactically valid code. It can scaffold Messages and know exactly where they wire through. It can extract Submodels and get the OutMessage pattern right.

This isn’t a bolt-on. It’s a consequence of the architecture.

For the best experience, clone the Foldkit repository as a git submodule in your project:

git submodule add https://github.com/foldkit/foldkit.git repos/foldkit

This gives the AI access to the Foldkit source code, the examples, and this documentation site: real patterns it can learn from and apply to your code. The starter template includes an AGENTS.md with Foldkit conventions and a .ignore file that keeps the submodule out of your editor’s file tree.

To update the submodule and pull the latest source, examples, and docs:

git submodule update --remote repos/foldkit

Foldkit ships a skills plugin for Claude Code that encodes Foldkit’s conventions, patterns, and quality standards into agent workflows. The skills reference the actual example code in the Foldkit repository, so the generated output stays in sync with the framework as it evolves.

Skills generate code. The DevTools MCP server lets agents observe and interact with code that’s already running. Agents can read the current Model, list and inspect Message history, rewind the UI to any past Model, and dispatch Messages into the runtime.