# AI-native development
Cratis is built to be driven by an AI assistant — not as an afterthought, but as part of the stack. There are two halves to it: tooling that teaches your agent to **build** applications the Cratis way, and tooling that lets it **operate** a running store. Here's how to turn both on.
## Why "AI-native"
An AI assistant is only as good as what it knows about your framework and your system. Drop a general-purpose agent into a Cratis codebase and it will *guess* — inventing handler classes, missing the vertical-slice conventions, hand-writing the API client you don't need. Point it at a running event store and it has no idea how to read the log or recover a stuck observer.
Cratis closes both gaps with tooling you install, so your assistant works *with* the grain of the framework instead of against it.
## Build with AI: agents and skills that know the Cratis way
The **Cratis AI configuration** is a set of agents, skills, and coding rules that teach an assistant the conventions — vertical slices, `[Command]` with `Handle()` on the record, model-bound projections, `ConceptAs` instead of raw primitives. It works with **Claude Code** and **GitHub Copilot**, surfaced through the standard `.claude/` and `.github/` folders.
Among the skills it hands your assistant:
- **`new-vertical-slice`** — scaffold a whole feature end to end: command, events, projection, query, React, and specs.
- **`cratis-command`**, **`cratis-readmodel`**, **`add-projection`**, **`add-reactor`**, **`add-concept`** — build one artifact correctly, by convention.
- **`scaffold-feature`**, **`write-specs`**, **`review-code`** — set up a feature folder, cover it with BDD specs, and review the result against the project's standards.
Because the skills encode the conventions, an agent that uses them produces slices that look like the rest of your codebase — not a layered approximation of it. (The configuration is the canonical `.ai/` source in the Cratis AI repository, dropped into a project as its `.claude/` and `.github/` folders.)
→ See [Plugins](/plugins/) for the full catalog of agents, skills, and coding rules — and how Claude Code and GitHub Copilot load them. The same conventions are enforced during the build by the [code-analysis gates](/code-analysis/).
**Model first, then generate:** Pair this with [Studio](/studio/): model the feature on the canvas, generate the C# shapes, then let an agent flesh out the slices around them. Design → generate → build, with AI at each step.
## Operate with AI: teach your assistant your store
Building is only half the loop. The other half is *operating* what you built — and Cratis makes the running store legible to an assistant two ways.
### `cratis init` — the CLI, made AI-aware
Run it once inside your project:
```bash
cratis init
```
It writes a **`CHRONICLE.md`** describing every command the CLI can run, installs instruction files for **Claude Code, GitHub Copilot, Cursor, and Windsurf**, and adds a **`chronicle-diagnose`** slash command. From then on your assistant knows how to browse events, watch observers, and diagnose a stuck partition through the [CLI](/cli/) — because the whole command catalog is in its context. Refresh it after a CLI upgrade with `cratis init --refresh`. The [CLI getting started](/cli/getting-started/) guide walks through it in full.
### The Chronicle MCP server — an agent, connected to the store
For tools that speak the **Model Context Protocol**, Cratis publishes a containerized MCP server that connects straight to a running Chronicle store. Point your tool at it with an `mcp.json`:
```json
{
"servers": {
"Chronicle": {
"type": "stdio",
"command": "docker",
"args": ["run", "-i", "--rm",
"-eCratis__Chronicle__Mcp__ConnectionString=chronicle://host.docker.internal:35000",
"cratis/chronicle-mcp"]
}
}
}
```
With it connected, your assistant can — in plain language — do things like:
- **Explore** — list event stores and sequences, show event types and their schemas, and read the event log or the events for a single event source.
- **Run observers** — list observers, replay an observer or one partition, and recover a failed partition.
- **Act on recommendations** — list, perform, or ignore the store's recommendations.
- **Manage jobs** — resume, stop, or delete a running job.
It needs a Chronicle server running; everything it does, it does against the live store.
**Operate, not mutate:** The MCP server and the CLI are *operate-and-inspect* tools — the agent reads the log and manages observers and jobs. To change application state you still go through commands and events. History stays honest.
## The whole loop, AI-accelerated
```mermaid
flowchart LR
subgraph Build["Build with AI"]
SK[".ai skills + agents
new-vertical-slice, …"]
end
subgraph Operate["Operate with AI"]
IN["cratis init
CLI command catalog"]
MCP["Chronicle MCP server
connected to the store"]
end
SK -->|scaffold slices| APP["Your Cratis app"]
APP -->|run it| OP["Running Chronicle store"]
IN -.->|inspect & diagnose| OP
MCP -.->|browse · replay · recover| OP
```
## Where to go next
How design, build, and operate fit together end to end — AI accelerates every step.
Install the CLI, connect to your store, and run `cratis init` to set up AI tooling.
The agents, skills, and coding rules in detail — and how each AI assistant loads them.
The Roslyn analyzers and ESLint rules that enforce the same conventions during the build.
The convention the build-side skills follow — everything for a feature in one folder.