Your AI agent doesn't need better prompts. It needs a governance layer.
I didn’t set out to build a governance tool. I set out to understand why my AI agent kept ignoring rules I’d already written down.
I had a “no magic numbers” rule in my CLAUDE.md — one rule among twenty-five covering code style, error handling, database conventions, API design. Clear enough. Claude reads it at session start.
Mid-session, after building two other services, I asked Claude to write an HTTP retry client. It produced the function with 429, 1000, and 2 hardcoded inline. Three magic number violations. The rule was right there in context. Claude had read it. Then it wrote code that violated it anyway.
That was the version of the problem I could measure. The version I couldn’t: building a webapp, asking Claude to reuse existing components, watching it acknowledge them, then testing the output and finding it had reimplemented the same behavior from scratch. The components were in the codebase. The instruction was explicit. The acknowledgment was real. The enforcement was absent.
Both times I’d done everything right. Rule written. Context given. Agent acknowledged it. Still drifted.
Context is not enforcement
Here’s what I had wrong. I thought writing the rule was the same as enforcing it.
It isn’t.
CLAUDE.md is context. The model reads it at session start. By the time it’s mid-session — multiple tasks completed, a full codebase loaded, twenty-five guidelines competing for attention — one rule on line 15 doesn’t constrain anything. The model isn’t forgetting. It’s that context and constraint aren’t the same thing.
Moving that rule to .claude/rules/ helps — Claude Code weights that directory differently than CLAUDE.md. But that alone isn’t enforcement. A rule in .claude/rules/ written the same way it was in CLAUDE.md is a slightly better suggestion, not a governed constraint.
Enforcement is what happens when that rule gets compiled into a directive with enforcement-grade language — not “avoid magic numbers” but “Never use numeric literals directly in code. Assign them to a named const. No exceptions.”
The compile step structures directives for attention — invariants listed first and restated last, so the things that must never be violated get the most weight. Thirteen lifecycle hooks keep governance present throughout the session — PostCompact re-injecting directives after context compaction, UserPromptSubmit injecting the active plan phase into every prompt. Quality gates let specialist agents block completion when they find critical violations.
The directory is where the output lands. The governance system is what makes the output effective.
I tested the difference. Three runs with the magic numbers rule only in CLAUDE.md, buried among twenty-five other guidelines: violations every time. Same project, same prompt, governance compiled through edikt into .claude/rules/ with enforcement-grade directives: every constant named, zero violations. The compliance difference wasn’t marginal. It was total.
That’s the gap edikt closes — not by moving files to a different directory, but by compiling your engineering decisions into a governance system that survives the entire session.
Rahul Garg has been writing about the practices underneath this on martinfowler.com — a series on reducing AI friction that names the problem directly. From Encoding Team Standards: “two developers on the same team, using the same tool, same codebase, same project context, producing materially different results.” The series also covers Context Anchoring and The Feedback Flywheel — decisions that persist and learnings that compound.
The series describes the practices. edikt is what happens when those practices get compiled into enforcement.
Architecture governance & compliance
The first system governs your architecture and ensures every line of code Claude writes is compliant with the decisions you’ve made — architecture choices, hard constraints, and team conventions.
The core mechanism is governance compilation. You capture architecture decisions as ADRs with enforcement-grade language. Not “we should prefer PostgreSQL” — MUST use PostgreSQL for all persistent storage. No document databases for transactional data. You capture hard constraints as invariants — things that must never be violated. You capture team conventions as guidelines.
Then you run /edikt:gov:compile. It reads every accepted ADR, every active invariant, every guideline. It checks for contradictions — if ADR-001 says “use PostgreSQL” and ADR-007 says “no relational databases,” compilation fails until the conflict is resolved. It distills each decision into a short, actionable directive with a source reference. And it writes the result to topic-grouped rule files under .claude/rules/.
Claude reads .claude/rules/ automatically, every session, before doing anything. Your architecture decisions aren’t suggestions anymore. They’re directives Claude follows before writing code — during planning, during execution, during review. Decide once. Compile. Every future session is compliant.
On top of compiled governance, edikt installs rule packs — twenty packs across three tiers: base (language-agnostic), language-specific, and framework-specific. Each focused on catching real bugs rather than enforcing taste. Claude invents a method that doesn’t exist in your codebase — the hallucinated API rule catches it. Claude leaves a // TODO: implement placeholder in production code — caught. Claude writes a timing-sensitive comparison without constant-time equality — caught. Rule packs and compiled governance both end up in .claude/rules/ — one enforcement surface, two sources of truth.
The compile step handles attention mechanics. Invariants are listed first and restated last — primacy and recency. The things that must never be violated get the most attention weight.
Compiled directives don’t get lost to context compaction the way CLAUDE.md content does. edikt’s hook system — thirteen hooks total — ensures governance stays present throughout the entire session. UserPromptSubmit injects the active plan phase into every prompt. PostCompact re-injects governance after context compaction. Your decisions aren’t loaded once. They’re enforced at every lifecycle point.
Agentic SDLC governance
The second system governs the full engineering lifecycle. A chain of commands, each producing artifacts the next step builds on, each transition gated:
You tell Claude what you want to build. /edikt:sdlc:prd generates structured requirements — numbered criteria with explicit verification methods. Not a wishlist. Testable acceptance criteria that the rest of the chain can verify against.
That PRD gets accepted, then /edikt:sdlc:spec produces a codebase-aware technical design — routed through the architect agent and relevant domain specialists, referencing existing ADRs, naming specific types and endpoints. A spec can’t be written from an unaccepted PRD. The transition is gated.
/edikt:sdlc:artifacts breaks the spec into implementable blueprints — data models, API contracts, migration plans, test strategies — each reviewed by the relevant specialist. The DBA reviews the data model. The API engineer reviews the contracts. QA reviews the test strategy. These aren’t documents. They’re the engineering blueprints your implementation builds against.
/edikt:sdlc:plan phases the work and runs a multi-agent pre-flight review. Before you write a line of code, the DBA checks your migration for missing indexes, security checks for hardcoded secrets, SRE checks for missing health probes.
v0.4.0 adds iteration tracking — if a phase fails evaluation and gets re-attempted, the plan tracks it and escalates when the approach clearly isn’t working. Acceptance criteria from the spec travel alongside each phase as a structured sidecar, so the evaluator checks against the criteria you defined, not criteria it invents.
Then you execute. Claude writes code within a governed session — compiled directives and rule packs fire automatically, hooks inject context at every lifecycle point. Quality gates mean specialist agents can block completion on critical issues. The DBA finds a missing index on a foreign key. Security finds a hardcoded JWT secret. The gate fires. You see the finding before the phase is marked done.
/edikt:sdlc:drift closes the loop. It compares the actual implementation against the full chain — PRD acceptance criteria, spec requirements, artifact contracts, ADR compliance, invariant compliance. You see exactly where implementation matches intent and where it doesn’t.
Each step is governed by the architecture decisions you’ve already compiled. Each step is reviewed by nineteen specialist agents who bring domain expertise to the points in the lifecycle where it matters most.
Where the two systems meet
The two systems work independently. You can use architecture governance without ever running the lifecycle chain. You can use the chain without compiling a single ADR. But when they work together: the lifecycle produces governance, and governance constrains the lifecycle.
Writing a spec forces you to choose between approaches. That choice is an architecture decision. If the spec contradicts an existing ADR, edikt catches the conflict. If the spec introduces a new architectural pattern, the stop hook detects it and suggests capturing it as an ADR — before the context window forgets it.
A plan pre-flight surfaces constraints that were never formalized. The DBA catches a missing rollback plan. That finding becomes an invariant. You compile. Next session, Claude includes rollback scripts automatically — not because it remembers the review, but because the invariant is now a compiled directive.
Drift detection reveals decisions that were never made explicit. The implementation diverged from the spec — but the divergence is actually better. That’s a decision. Capture it. Compile it. Now it’s part of the architecture Claude follows.
Decisions compound. They don’t just persist — every session is more governed than the last. Not because you maintained a bigger CLAUDE.md file, but because the system captures decisions as they happen and compiles them into enforcement that strengthens over time.
Honest current state
edikt is Claude Code only. Compiled governance, lifecycle hooks, path-conditional rules, and agent spawning are Claude Code primitives that don’t exist in Cursor, Copilot, or other AI coding tools. Platform abstraction is on the roadmap — starting with Codex — but I didn’t want to abstract before the enforcement model was right on one platform.
It’s a v0.4.0. I’ve been dogfooding it since v0.1.0 — edikt governs its own development. Both systems work, the hooks work, the agents work, the quality gates work, drift detection works. Early adopters are using it. Edge cases will surface as usage grows.
Everything is plain markdown. No compiled code, no runtime dependencies, no build step. If edikt disappeared tomorrow, every file it created — every ADR, every invariant, every spec, every compiled directive — would still be there. Readable, useful, yours.
Who it’s for
Engineers who use Claude Code daily and are tired of their agent producing code that doesn’t follow the decisions they made. You’re already doing governance by hand — maintaining CLAUDE.md files, re-prompting standards, catching drift in review — and you know it’s not enough.
Teams get the same governance automatically. Compiled rules live in the repo. Run /edikt:init on a new engineer’s machine and their Claude follows the same architecture decisions, the same invariants, the same coding standards as yours. One command.
The space is Agentic Engineering Governance — the discipline layer between “AI agent that can write code” and “AI agent you can trust to build the right thing the right way.” The category is new. The problems aren’t.
Try it
curl -fsSL https://edikt.dev/install.sh | bashRun /edikt:init in your next Claude Code session. Make a decision. Compile it. Start a new session. Watch Claude follow the decision without being told.
Documentation: edikt.dev
GitHub: github.com/diktahq/edikt
References
Rahul Garg — Patterns for Reducing Friction in AI-Assisted Development, martinfowler.com: