verikt Your architecture, in every agent session.

What happens without architectural context

Every session starts cold. The agent doesn’t know your layers, your conventions, or which capabilities you’ve wired. It puts domain logic in the adapter layer. It reinvents patterns your team already standardised. It writes code that compiles, passes tests, and violates your architecture.

You correct it. Next session, same thing.

The standard fix — a hand-written CLAUDE.md or .cursorrules file — works until it doesn’t. You write it once, the architecture evolves, the file doesn’t. Three months later your agent is following rules that no longer match your codebase.

At team scale, it compounds. Three engineers, three agents, three different interpretations of the same architecture. You discover the inconsistency in code review — the wrong person catching the wrong problem at the wrong time.

Every agent session starts with your architecture already loaded

verikt guide

Generates context files for Claude Code, Cursor, Copilot, and Windsurf from your verikt.yaml. Always current. One command to update.

verikt.yaml

One source of truth. Every engineer, every agent, every session. Your architecture as a versioned, commitable artifact — not a document that drifts.

verikt check

Catches violations before they ship. 11 architecture detectors in CI — wrong-layer dependencies, anti-patterns, drift. Not in code review. Not in production.

verikt new

Correct structure from day one. Scaffolds from architecture + capabilities, and runs verikt guide automatically — so your agent has context from the first prompt.

The prompts that just work

The CLI is the plumbing. The prompt is the interface.

You prompt	The agent already knows
"Add a GET /orders endpoint filtered by customer ID, paginated, with RFC 7807 errors."	Where the handler goes, which error format to use, how to wire the router — without being told.
"What capabilities am I missing before going to production?"	Your installed capabilities, the smart suggestion rules, what's missing and why.
"Does this PR violate our architecture?"	Your layer boundaries, dependency rules, and which files changed — runs verikt check --diff main.
"I need to handle payments. What do I need?"	That idempotency and audit-log are required, why, and how to add them.

Evidence, not claims

Teams with high AI adoption merge 98% more PRs — but review times balloon by 91%. Only 48% of developers consistently check AI-assisted code before committing. (Osmani, The 80% Problem in Agentic Coding.) The productivity gain lands in generation. The cost lands in review. Architecture violations are that review cost.

Guide vs no guide — EXP-03

Greenfield notification service. Same prompt, same model. Only the guide presence varies.

7 → 1 violations

22.2× variance reduction (EXP-02)

-23% output tokens

Without guide: flat structure (cmd/internal/), 7 violations, 3,522 output tokens. With guide: hexagonal (domain/port/service/adapter/), 1 violation, 2,703 tokens. Variance measured across 3 runs in EXP-02: [2,1,1] → [0,0,0].

See full experiment results →

Practitioner validation

“AI-generated code that works but misses circuit breakers or retry logic is a real risk. Architecture awareness is the missing layer.”

— Senior engineer, payment systems (2M daily transactions)

Try it now →Two commands. Your next session starts differently.

Start right. Stay right.

Every scaffolded service comes with a verikt.yaml — the source of truth verikt guide reads. Your agent has a complete architecture picture from the first prompt.

Architecture (hexagonal) + Capabilities (http-api, postgres, docker) = Your Service

Pick an architecture. Pick your capabilities. Get a production-ready service with the structure already correct — and a verikt.yaml that becomes the source of truth for every agent session.

Go: 63 capabilities across 10 categories. TypeScript: 39 capabilities with Express, Fastify, or Hono. The wizard suggests what’s missing.

Category	Capabilities
Transport	HTTP API, gRPC, GraphQL, Kafka, NATS, WebSocket, SSE
Data	PostgreSQL, MySQL, MongoDB, Redis, S3, migrations
Security	JWT auth, OAuth2, encryption, multi-tenancy
Resilience	Circuit breaker, retry, bulkhead, idempotency
Patterns	CQRS, DDD, event bus, outbox, saga, worker
Observability	Health checks, OpenTelemetry, request ID, audit log
Infrastructure	Docker, CI/GitHub, Makefile, pre-commit
Platform	Config, lifecycle, bootstrap, validation, UUID
Quality	Linting, testing
Frontend	templ, HTMX, static assets, i18n

Three commands. Every agent knows your architecture.

# Homebrew (runs setup automatically)
brew install diktahq/tap/verikt

# Or install script (also runs setup automatically)
curl -sSL https://verikt.dev/install.sh | bash

# Generate architecture context for all AI agents
verikt guide

# Enforce in CI
verikt check

Both install paths run verikt setup automatically — detecting your AI agents and registering verikt globally.

Then open your AI agent in the project directory. The context is already there — the agent loads it silently. Write prompts naturally:

Add a GET /orders endpoint filtered by customer ID, paginated, with RFC 7807 errors.

The agent already knows your architecture, your layers, and your capabilities.

Prompt engineering guide →How to prompt when the architecture is already loaded.

One engineer to start. Consistent across the team.

For Engineers →

Your agent sessions become reliable. Every session starts with your architecture. Stop correcting, start shipping.

For Engineering Leaders →

One verikt.yaml. Every engineer. Every agent. Every session. Architecture governance without being the enforcer.

Your architecture, in every agent session.

brew install diktahq/tap/verikt

Quick Start with AI AgentsGitHub