edikt for Teams
Every engineer on your team uses Claude Code. Every engineer prompts it differently. The output looks like it came from five different organizations. You know this because you're the one reviewing the PRs — catching the naming inconsistencies, the business logic in HTTP handlers, the error handling that doesn't match what the team agreed on last sprint.
Code review has become standards enforcement. That's not your job. That's a governance problem.
This guide shows the full workflow. One engineer sets up edikt, commits it, and every engineer on the team gets a governed session from that point forward.
1. One engineer sets up, commits — the whole team gets governance
Elena is the engineering lead. The team builds a support-ticketing API — Go, Chi, PostgreSQL. She opens the project in Claude Code.
Elena commits:
git add .claude/ .edikt/ docs/
git commit -m "chore: add edikt governance"
git pushThat commit is the only setup step. Every engineer who pulls this branch gets the full governance — rules, agents, hooks, project identity. No Slack message saying "hey, update your CLAUDE.md." No wiki page nobody reads. One commit, done.
2. New engineer opens the project — governance is already there
Next morning. Tomasz pulls the latest changes and opens the project in Claude Code. He's never heard of edikt. He doesn't need to.
Tomasz didn't mention the service layer pattern. He didn't mention typed errors. He didn't mention keeping business logic out of handlers. The model read .claude/rules/architecture.md, .claude/rules/error-handling.md, and .claude/rules/chi.md — automatically, before writing anything.
This is the moment for teams. Every engineer's agent session produces the same architecture, the same patterns, the same error handling. Not because they prompt the same way. Because the governance is in the repo.
3. The code review shift — standards are already followed
Tomasz opens his PR. Elena reviews it.
The handler parses query parameters, validates them, and calls the service. No database queries. No business logic. The service builds filter criteria and calls the repository. The repository runs parameterized SQL — no string interpolation. The errors are typed with context wrapping.
Elena's review comments:
Elena: "Nice cursor-based pagination choice. One thought — should we
add a max page size to prevent someone requesting 10,000 tickets?
Maybe cap at 100 with a default of 20."
Elena: "The TicketSearchCriteria value object is clean. Consider adding
a Validate() method so the service doesn't need to check each
field individually."Two comments. Both about design decisions. Neither about standards violations.
Before edikt, Elena's review of a similar PR would have looked like this:
Elena: "Move the SQL query out of the handler — it should go through
the service layer."
Elena: "Don't use fmt.Errorf here — we use typed errors. See how
the assignment handler does it."
Elena: "This string interpolation in the WHERE clause is a SQL injection
risk. Use parameterized queries."
Elena: "The handler is doing too much — parsing, validation, querying,
formatting. Split it up."
Elena: "We discussed using cursor-based pagination in standup last week.
This is offset-based."Five comments. All standards enforcement. All things the model should have gotten right on its own.
The shift isn't incremental. The category of review comment changes. Elena stops catching basics and starts evaluating design. The team's code review actually improves the codebase instead of policing it.
4. Quality gate fires — the model blocks a security issue
Two weeks in. The team has captured 5 ADRs and compiled them into governance directives. Priya is building the ticket closure endpoint.
The model builds the endpoint. Handler, service, repository — following the pattern. Then:
The security agent caught raw string interpolation in a SQL query. It didn't just warn — it blocked. Priya couldn't proceed until the issue was resolved or she logged an override with her identity.
This is what quality gates do for teams. The security standard isn't a suggestion someone reads in a wiki. It's enforcement that runs on every session, for every engineer.
If Priya had overridden:
The override is recorded. Elena sees it when she checks governance status. It's not surveillance — it's a record that a trade-off was made consciously, not accidentally.
5. Status dashboard — governance health at a glance
End of sprint. Elena checks the state of governance.
Seven rules active. Five ADRs compiled into directives. One security gate fired and was resolved. One plan in progress. Elena can see exactly what's enforced, what decisions the team has made, and whether any gates were overridden.
She reads it out in the sprint review — two seconds, no prep, nothing to have written in advance.
Command reference: /edikt:status
6. New hire onboarding — zero setup, same governance from minute one
Week 6. A new engineer joins — James, straight out of a bootcamp. His first day, he clones the repo, opens it in Claude Code.
The model referenced three ADRs and one invariant. It knew about UTC timestamps, migration rollbacks, and soft deletes — not because James told it, but because the team's governance was committed to the repo six weeks ago.
James's first PR arrives with the right patterns. Elena's review is about the feature, not the formatting. The onboarding checklist just got shorter.
Before edikt, James would have spent his first week learning patterns by getting them wrong in code review. "We don't do it that way — check the wiki." Except the wiki is six pages and half of it is outdated.
With edikt, the governance is the wiki. It's enforced, not referenced. It's current, not aspirational. And it works from minute one.
What changes
The dynamic shifts in three places.
Code review stops being standards enforcement. When every engineer's agent reads the same rules and follows the same ADRs, the baseline is handled before the PR opens. What's left is the work that actually matters: evaluating design decisions, questioning trade-offs, catching logic errors.
Onboarding stops being knowledge transfer. The new engineer's agent session is as governed as the senior engineer's. The patterns are enforced, the decisions are documented, the invariants are active. Tribal knowledge becomes committed governance.
Consistency stops being a function of who's prompting. The engineer who writes great prompts and the engineer who writes "add a search endpoint" both get architecture-compliant output. The rules don't care how you ask. They fire every time.
One commit to set up. Zero per-engineer configuration. The governance accumulates as the team makes decisions and compiles them. Every ADR makes the next session smarter. Every invariant prevents the same mistake from happening twice.
Command reference: /edikt:init, /edikt:status, /edikt:adr, /edikt:gov:compile