Skip to content
verikt

Introduction

The Problem

Section titled “The Problem”

Starting a new service means making dozens of decisions upfront: project layout, error handling, logging, config, middleware, database setup, graceful shutdown. You either copy-paste from a previous project (carrying its tech debt) or spend hours setting up boilerplate before writing a single line of business logic.

Then, three months later, every team’s service looks different.

AI agents make this worse. They write correct syntax but don’t know your architecture — domain code imports adapter code, config loading ends up in the wrong layer, and the production patterns you’ve standardized get reinvented differently every time.

The Solution

Section titled “The Solution”

verikt guide generates instruction files from your verikt.yaml so AI agents (Claude Code, Cursor, Copilot, Windsurf) start every session with your exact architecture rules, capability set, and dependency constraints. This is prevention, not correction — the agent knows the rules before it writes the first line.

For greenfield services, verikt also composes your project from two building blocks:

  1. Architecture — The structural pattern (hexagonal, layered, clean, flat) that defines your project layout and dependency rules
  2. Capabilities — 63 modular features (HTTP API, MySQL, auth, circuit breaker, i18n, etc.) that plug into your architecture
Architecture (hexagonal) + Capabilities (http-api, mysql, docker) = Your Service

How It Works

Section titled “How It Works”

Capabilities generate only the code, imports, and configuration they need — nothing more. When you add an HTTP API, verikt suggests what else you likely need: health endpoints, request ID propagation, rate limiting, CORS. verikt check validates your dependency rules with 11 AST-based detectors — domain code importing adapter code gets caught at the command line, not in code review.

Next Steps

Section titled “Next Steps”