AI-native development

The Cratis Stack

Build and operate with AI agents

Cratis is designed to give an AI assistant the same domain vocabulary, framework boundaries, and verification gates your team uses. Cratis maintainers use framework-aware workflows in Cratis repositories today; external portable coding skills remain in distribution preview. The CLI and Chronicle MCP provide the documented operating side now.

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 the operating gap with documented CLI and MCP setup today. For coding workflows, it separates the repository-local setup used by Cratis maintainers from a generated portable distribution that remains gated until its first real target and release are approved.

Build with AI: skills that know the Cratis way

The Cratis AI configuration teaches an assistant the conventions—vertical slices, [Command] with Handle() on the record, model-bound projections, and ConceptAs<T> instead of raw primitives.

Cratis-owned repositories currently carry repository-local rules and host adapters, so maintainers can use these workflows today. The public portable skills are being generated for Agent Skills, Claude Code, Codex, GitHub Copilot, Cursor, Kiro, Junie, Gemini CLI, and Pi, but they are not released for external installation yet. The public distribution repository remains fixture-only until source, target, canary, and release gates pass.

Among the workflows available to Cratis maintainers:

• 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.)

Start with AI setup and current availability, then use the ecosystem support matrix to see what is verified and what remains blocked. Plugins explains the shared skill model, while the code-analysis gates enforce framework contracts during the build.

Model first, then generate

Pair this with Studio or Screenplay: model the feature on the canvas or as a declarative .play script, 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:

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 — because the whole command catalog is in its context. Refresh it after a CLI upgrade with cratis init --refresh. The 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:

{
    "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

Where to go next

Get started with AI

Set up the operating tools today and understand the coding-skills release status.

Ecosystem support

See generated formats and verification status across supported AI hosts.

Trust and distribution

Learn how approvals, generated bytes, canaries, rollback, and project context fit together.

The Cratis Stack

How design, build, and operate fit together end to end — AI accelerates every step.

CLI getting started

Install the CLI, connect to your store, and run cratis init to set up AI tooling.

Plugins

The agents, skills, and coding rules in detail — and how each AI assistant loads them.

Code analysis

The Roslyn analyzers and ESLint rules that enforce the same conventions during the build.

Vertical slices

The convention the build-side skills follow — everything for a feature in one folder.