What is edikt?

The governance layer for agentic engineering.

AI coding agents have memory. They don't have governance. That memory is local — never shared, never reviewed, never consistent across a team. Architectural decisions made last month live in Slack threads or nowhere. Standards exist in a memory file (CLAUDE.md, on Claude Code — edikt's current harness, with others planned) that drifts the moment someone forgets to update it.

The result: every engineer's agent works differently. Same team, same codebase, different output. Decisions contradicted. Patterns ignored. Technical debt generated at machine speed.

edikt governs your architecture and compiles your engineering decisions into automatic enforcement. It governs the Agentic SDLC from requirements to verification. It doesn't tell you what to build. It ensures that what you decided to build is what actually gets built.

The problem

You've told your agent your patterns. You've explained your architecture. You've corrected the same mistakes ten times. And then a new session starts, and you do it all over again.

This isn't a model problem. It's a governance problem. Models are stateless by default. Without enforcement, every session starts from zero.

Claude Code — without edikt

❯build the payment handler

func HandlePayment(w http.ResponseWriter, r *http.Request) {

db.Query("INSERT INTO payments...") // business logic in handler

panic("stripe not configured") // told you a hundred times

}

❯I said — no DB calls in handlers, return errors don't panic, use the service layer. We have an ADR for this.

"You're right, let me fix that..."

// Tomorrow. New session. Same mistakes.

Not because the model is incapable. Because there's no governance — no enforcement, no persistent decisions, no feedback loop.

And on a team, the problem multiplies. Five engineers, five different agent sessions, five different interpretations of "follow the coding standards." The output looks like it came from five different organizations. Code review becomes standards enforcement — catching what the model should have known, every PR, every day.

The fix is structural, not conversational

You can't fix a stateless tool by talking to it more. You fix it by installing governance.

/edikt:init

Describe your project once, in plain language. edikt infers the architecture from that description, reads what's already in the repo, picks the rules that match, and generates everything — you confirm and adjust. It doesn't interrogate you. The alternative is twenty yes/no questions in a configuration wizard, and a wizard produces a worse result for a structural reason: it can only ask what its authors anticipated, and you answer from memory, out of context, about a codebase the wizard never looked at. One good description beats a questionnaire.

edikt installs your standards where the model reads them automatically — before writing a single line of code.

Claude Code — with edikt

❯build the payment handler

// Thin handler — delegates to PaymentService

// Returns error — no panics

// No DB calls — service layer handles persistence

// Named constants — no magic strings

// Because it read .claude/rules/go.md, architecture.md,

// error-handling.md before touching your code

The reminders disappear. The standards stick.

A CLAUDE.md is a suggestion the model reads once. .claude/rules/ is enforcement it follows on every file, every session — without being reminded.

Ready to try it? Get Started — 5 minutes

Two systems, one goal

edikt delivers governance through two systems that reinforce each other.

Architecture governance & compliance captures your architecture decisions, detects new ones mid-session, and compiles everything into enforcement the model reads automatically — architecture choices, constraints, conventions, and correctness standards.

Agentic SDLC governance governs the full lifecycle from requirements to verification — PRD, spec, artifacts, plan, execute, drift detection — with specialist review at every critical step.

The two systems connect: the lifecycle surfaces new engineering decisions. Compiled decisions constrain the lifecycle. Decisions compound rather than decay.

The Agentic SDLC

Without edikt, the engineering cycle is scattered — requirements in Notion, decisions in Slack, specs in someone's head, and no way to verify the implementation matches any of them.

edikt governs the full Agentic SDLC. You drive it through natural language, and each step references the one before it:

PRD → spec → artifacts → plan → execute → drift detection

Each step feeds the next. Each must be accepted before the next begins. What changes day-to-day walks the sequence with the prompts and the output.

Command references: /edikt:sdlc:prd, /edikt:sdlc:spec, /edikt:sdlc:artifacts, /edikt:sdlc:plan, /edikt:sdlc:drift

The governance loop

While the two systems handle what gets decided and what gets built, the governance loop handles enforcement throughout each session. While the model works, edikt governs — automatically, every session:

• The model writes a file → auto-formatted via PostToolUse hook
• The model makes a decision → signal detected, ADR capture suggested → compile updates directives
• Context compaction hits → plan phase and invariants re-injected automatically
• Plan phase starts → specialist agents review before the first line is written
• Security gate fires → critical finding blocks progression until resolved
• Feature shipped → drift detection verifies it matches the spec and ADRs
• New engineer joins → same standards, same agents, same decisions, day one

These aren't prompts. They're platform primitives — lifecycle hooks that fire automatically, path-conditional rules that gate on file type, and quality gates that block progression. edikt uses the harness's enforcement surface, not its conversation surface. Today that harness is Claude Code.

What edikt installs

Compiled governance directives

Tell it to compile your governance directives after capturing decisions:

"Compile governance"

edikt reads your accepted ADRs, active invariants, and team guidelines and produces four things under .claude/rules/: an always-on ambient core loaded every session, per-topic files that load when you touch matching code, a machine-readable directive-index.yaml the write-time hooks read, and a manifest that proves nothing drifted. The ADRs are the source of truth. The compiled output is the enforcement format — see Compile for the full render model.

ADRs (accepted) + Invariants (active) + Guidelines
        ↓ /edikt:gov:compile
.claude/rules/ — ambient core, topic files, directive-index.yaml, manifest.yaml

Update an ADR, recompile. One source of truth, one compile pass.

Command reference: /edikt:gov:compile

Governance benchmark — /edikt:gov:benchmark

Compiled directives tell the model what to do. The benchmark tests whether they hold under adversarial prompts.

"Run the governance benchmark"

edikt runs attack prompts against every directive with a behavioral_signal block — the machine-testable predicate that defines what a violation looks like. Each directive gets PASS, FAIL, or SKIP (no behavioral_signal populated).

Currently inert under the v0.6.0+ sidecar architecture: behavioral_signal was a pre-v0.6.0 in-body-sentinel field and isn't part of the current sidecar schema, so every directive reports SKIP until a schema extension restores it. See /edikt:gov:benchmark for the current status.

The benchmark is an opt-in tool — install separately:

./bin/edikt install benchmark

Command reference: /edikt:gov:benchmark

Correctness guardrails — .claude/rules/

One .md file per standard. Path-conditional — each rule only fires on the files it's relevant to.

.claude/rules/code-quality.md       ← every file
.claude/rules/testing.md            ← every file
.claude/rules/security.md           ← every file
.claude/rules/error-handling.md     ← every file
.claude/rules/go.md                 ← **/*.go only
.claude/rules/chi.md                ← **/*.go only

What gets enforced without being told:

• No panic — return errors with context
• No business logic in HTTP handlers
• No raw SQL string concatenation — parameterized queries only
• No any in TypeScript — typed all the way down
• Test behavior, not implementation

Base rules (code-quality, testing, security, error-handling) apply to every language. Language and framework rules layer on top — Go, TypeScript, Python, React, Next.js, Chi, and more. edikt detects your stack and picks the right combination.

Compiled governance and rule packs share the same enforcement surface — .claude/rules/. Together they define everything the model must follow.

They also sit upstream of your linter. The best engineering teams don't fix linting violations — they never write them in the first place. Not because they suppress warnings, but because the standard is understood before the code exists. That distinction is the whole argument: a linter is a detector. It runs after the fact, reports what is already wrong, and charges a correction round every time it fires — the model writes, the linter complains, the model rewrites. Rules move the standard to the other side of the keystroke. The model reads them before it writes, so the code arrives already conforming. The linter stays as a safety net and rarely fires. The goal isn't fewer lint errors. The goal is not writing lint errors.

Lifecycle hooks

15 lifecycle hooks govern the session — ensuring governance stays present throughout, not just at session start. The ones most relevant day to day:

Hook	What it does
SessionStart	Surfaces what changed since last session, relevant agents
PreToolUse	Validates governance setup before the model writes code
PostToolUse	Auto-formats code after every edit
Stop	Detects uncaptured decisions, suggests ADR capture
PostCompact	Recovers context after compaction
UserPromptSubmit	Injects active plan phase on every prompt
SubagentStop	Logs agent activity and enforces quality gates
InstructionsLoaded	Logs which rule packs are active this session

Specialist agents — .claude/agents/

18 domain agents matched to your stack. Each applies a specific domain lens.

architect  ← system design, ADRs, bounded contexts
security   ← OWASP, threat modeling, auth patterns
dba        ← schema design, migration safety, N+1 queries
api        ← API contracts, versioning, breaking changes
qa         ← testing strategy, coverage, flaky tests

Used in plan pre-flight review, review, and audit — or called directly.

Project memory — docs/

The model knows your project identity, not just your file structure.

docs/project-context.md        ← what the project is, stack, non-negotiables
docs/architecture/decisions/   ← why you chose your database, why you went with this architecture style
docs/architecture/invariants/  ← constraints that must NEVER be violated

Loaded automatically at session start via git-aware hooks.

What changes day-to-day

Defining requirements:

"Write a PRD for Stripe webhook delivery with retry logic and idempotency"

Structured requirements with acceptance criteria, generated from your description and project context. Lives in docs/product/prds/ — referenced by everything that follows.

Writing the spec:

"Write a spec for PRD-005"

edikt routes to architect, scans your codebase, and reads your existing ADRs before generating a technical specification from the accepted PRD — architecture decisions, trade-offs, alternatives considered.

Planning execution:

"Create a plan for SPEC-005"

Phased execution with specialist pre-flight review:

Pre-flight review

PRE-FLIGHT REVIEW

DBA

CRITICAL Migration has no rollback — add DOWN migration before executing

WARNING No index on webhooks.status — queried in retry loop

API

PASS Endpoint contract looks stable

Fix the migration gap now. Takes 5 minutes. Would have taken an hour after.

Quality gates:

These fire automatically — you don't trigger them. When a specialist agent detects a critical finding during execution, the model presents the gate:

Quality gate

GATE: security — critical finding

Hardcoded JWT secret in auth/handler.go:47

This gate must be resolved before proceeding.

Override this gate? (y/n)

Note: override will be logged with your git identity.

After implementation:

"Does the implementation match the spec?"

It compares what got built against the PRD acceptance criteria, spec requirements, artifact contracts, and ADR compliance.

Drift report — SPEC-005

SUMMARY

14 compliant (high confidence)

2 likely compliant (medium)

1 diverged

SPEC REQUIREMENTS

Retry backoff — spec requires exponential with jitter

expected: exponential backoff with jitter (ref: spec section 3.2)

found: fixed 5-second retry interval

action: Update RetryJob to use exponential backoff

Governance dashboard:

"What's our status?"

edikt status — my-project

GOVERNANCE HEALTH

Rules: 4 active (code-quality, testing, security, go)

Agents: 7 installed

Decisions: 12 ADRs, 1 invariant

Plan: PLAN-007 Phase 2/4 — in progress

CHAIN STATUS

PRD-005 accepted → SPEC-005 accepted → artifacts accepted → PLAN-007 in progress

GATE ACTIVITY

security: 1 critical finding (resolved)

dba: no findings

For teams

Commit .claude/ and docs/ to your repo. Every engineer gets identical governance from the first session — no setup, no per-developer configuration.

What this means for code review: the standards violations stop arriving. When every engineer's agent follows the same rules, the same architecture decisions, and the same quality gates, code review shifts from catching formatting and pattern violations to evaluating design decisions. The baseline is handled.

What this means for onboarding: a new engineer opens the project, runs Claude Code (edikt's current harness), and gets the same governance as the engineer who set it up six months ago. The standards, the decisions, the agents — all there. No tribal knowledge. No "ask Marcus how we do error handling here."

No drift between teammates. The junior engineer follows the architecture from day one.

On a team, a shared CLAUDE.md requires every engineer to read it, remember it, and follow it. edikt's rules fire automatically — no per-engineer discipline required.

Set up edikt for your team — Getting Started

Across projects

If you run multiple projects — client work, internal products, microservices — edikt's governance installs per-project. Each project gets its own rules, its own decisions, its own agents matched to its stack.

The methodology stays constant: governance chain, quality gates, specialist review. The specifics vary: this project uses Go and PostgreSQL, that one uses TypeScript and MongoDB. Run /edikt:init on each.

When engineers rotate between projects, they don't start from scratch. The governance is already there. Same discipline, different codebase.

Maintenance is low by design. Rules update when you run the install script again. Decisions update when you compile. The overhead per project is a config file and the decisions you'd be making anyway — edikt just makes sure they persist.

See how it works on your first project — Getting Started

Why Claude Code today

Claude Code today — Codex and other harnesses next. edikt's governance loop depends on platform primitives: path-conditional rules, lifecycle hooks that can actually block a write (not just observe it), slash commands, and sub-agent orchestration. "Quality gates" isn't a separate platform primitive any of these harnesses expose — it's what edikt builds on top of blocking hooks plus specialist agents, on any harness that has both.

Researched from public documentation, August 2026 — this space moves fast, treat this as a snapshot, not a permanent scorecard:

Feature	Claude Code	Codex	Cursor	Copilot	Windsurf
Path-conditional rules	Yes	Partial — directory-scoped AGENTS.md, not glob patterns	Yes — .mdc glob frontmatter	Yes — applyTo glob instructions	Yes — glob trigger mode
Lifecycle hooks that can block	Yes	Yes — 11 event types, blocking confirmed on 5 of them	Yes — 18 event types, hooks can return continue: false	Partial — hooks found, only confirmed for logging/audit	Not found
Compaction-aware recovery	Partial — PostCompact only, no PreCompact	Yes — both PreCompact and PostCompact, can even prevent compaction	Has preCompact; recovery behavior unconfirmed	Not found	Not found
Slash commands	Yes	Yes — 40+ built-in	Yes — custom commands since v1.6	Yes — built-in + custom agent commands	Yes — workflows as /name
Sub-agent orchestration	Yes — 18-agent roster, plan-integrated	Yes — 136+ agent definitions across 10 categories	Yes — Subagents (v2.4, Jan 2026), parallel dispatch	Yes — custom agents + Fleet mode	Not found

Sources: Codex hooks · Codex AGENTS.md · Codex slash commands · Cursor Rules · Cursor Hooks · Cursor Subagents · GitHub Copilot custom instructions · GitHub Copilot custom agents · Windsurf Workflows · Windsurf Rules

The honest read: rules and slash commands are table stakes across the field now — that's not a moat. Blocking hooks and multi-agent orchestration are where it gets uneven, and Codex looks the most complete of the four on exactly those two — which is the concrete reason it's the named "next," not just the next-best-known name. The knowledge base (project-context.md, ADRs, specs, docs) is plain markdown that already works on any of them. What edikt hasn't built yet is the governance loop running natively on anything but Claude Code — that's an integration project, not a research problem, and this table is the argument for why Codex is where that project starts.

---

Get Started — 5 minutes · View on GitHub