edikt Across Projects
Every new client project starts from zero. No governance, no methodology in place, no way to ensure your engineers follow the same standards they used on the last engagement. The senior engineer who built the patterns on project A rotates off, and the engineer who replaces them starts from scratch.
You have a methodology. Your consultancy knows how to build software. But Claude doesn't know any of it — and there's no mechanism for that knowledge to persist from one engagement to the next.
This guide shows the full workflow. Same methodology across every client project. Different stacks, different decisions, same governed output.
1. Setting up client project A — Go backend for a logistics platform
Ravi is the technical director. His consultancy just signed a new client — a logistics company that needs a shipment tracking API. Go, Chi, PostgreSQL. Ravi opens the project.
Ravi captures the client-specific constraints immediately:
Ravi commits and pushes. Every engineer assigned to this project gets the full governance from their first session.
Command references: /edikt:init, /edikt:adr, /edikt:invariant, /edikt:compile
2. Setting up client project B — TypeScript frontend for a fintech dashboard
Same week. A different client — a fintech company building a real-time trading dashboard. TypeScript, Next.js, React. Ravi opens the project.
Different stack, different rules. Same methodology. The governance chain (PRD, spec, artifacts, plan, execute, drift) is identical. The quality gates work the same way. The decision capture process is the same. What changed is the stack-specific rules: typescript.md, frontend.md, and nextjs.md instead of go.md and chi.md.
Ravi captures the client-specific decisions:
Commit, push. Project B is governed. The methodology is Ravi's consultancy's methodology. The rules are fintech-specific. The invariants are this client's compliance requirements. Each project has its own governance — nothing leaks between them.
3. Engineer rotating from project A to project B
Anya has been working on the logistics API (project A) for three weeks. She's built the tracking context, captured two more ADRs, and is comfortable with the Go codebase. Today she rotates to the trading dashboard (project B) because the frontend needs an engineer who understands real-time data.
Anya opens project B in Claude Code. She's never seen this codebase.
Anya went from Go with DDD and event sourcing to TypeScript with Next.js and Zustand. Different language. Different framework. Different architecture. But the governance loaded instantly — she knows the decisions, the constraints, the invariants. She didn't ask Kai how the project works. She didn't read a wiki. Claude told her.
Every decision Anya's predecessors made on this project is reflected in Claude's approach. The server-first component strategy. The scoped Zustand store. The existing WebSocket manager. The financial data invariant. Claude referenced three ADRs and one invariant — without Anya asking about any of them.
This is the moment for consultancies. An engineer rotates onto a project they've never touched, and their first session produces code that follows every decision the team made before they arrived. No ramp-up week. No "ask Kai how this works." The governance is in the repo.
4. Capturing a client-specific decision — the governance grows
Anya is mid-implementation. She needs to decide how to handle WebSocket disconnections in the trade history view.
Anya commits. Tomorrow, when Kai opens the project, his Claude session knows about the stale data pattern. When the next engineer builds the portfolio positions widget, Claude will implement the same disconnection handling without being told. The decision Anya made today is enforcement for every engineer from this point forward.
Command references: /edikt:adr, /edikt:compile
5. Status across projects — governance health per engagement
End of the week. Ravi checks the health of both client projects.
He opens the logistics project:
He opens the trading dashboard project:
Two different projects. Different stacks. Different clients. Different decisions. Same methodology. Same governance chain. Same quality gate structure. Same status format.
Ravi can see at a glance: the logistics API has zero security findings and one DBA warning that was resolved. The trading dashboard had a security gate fire and was resolved. Both projects have their client-specific invariants active with no violations.
He pulls this up in the client review meeting. Not a report he spent an hour writing — a command he ran in 2 seconds per project.
Command reference: /edikt:status
What stays the same, what varies
The methodology is the constant:
- The governance chain: PRD, spec, artifacts, plan, execute, drift detection
- The quality gates: blocking and advisory, with override logging
- The specialist agents: architect, security, DBA, API, QA, SRE
- The decision capture: ADRs compiled into enforcement directives
- The lifecycle hooks: session start, plan injection, compaction recovery, signal detection
What varies is what should vary:
- The stack rules: Go rules on the logistics project, TypeScript rules on the dashboard
- The ADRs: event sourcing for logistics tracking, Zustand for dashboard state
- The invariants: EU data residency for one client, no client-side storage for the other
- The compiled governance: each project's directives reflect that project's decisions only
Nothing leaks between clients. The logistics client's data residency invariant doesn't appear in the trading dashboard project. The dashboard's Zustand decision doesn't show up in the Go codebase. Per-project governance, shared methodology.
When an engineer rotates, they carry the methodology — not the client-specific knowledge. The knowledge is in the repo, loaded automatically. The methodology is in the muscle memory of running /edikt:init, capturing decisions, compiling governance.
One command per project. The framework is immediate. The specifics accumulate as the engagement progresses. The next engineer who joins gets everything the last one built.
Command reference: /edikt:init, /edikt:status, /edikt:adr, /edikt:invariant, /edikt:compile