Getting Started
What you'll have in 5 minutes
After running /edikt:init, your project gets:
- Rules that the model reads before writing any code — matched to your stack
- Specialist agents (architect, QA, security, DBA) you can invoke by name
- Automatic behaviors — code auto-formatted on edit, context refreshed each session, decisions captured when you make them
- A governance chain — PRD → Spec → Plan → Code, with drift detection
All committed to your repo. Your whole team gets identical governance. New to edikt? Read What is edikt? first.
1. Install
curl -fsSL https://github.com/diktahq/edikt/releases/download/v0.7.1/install.sh | bashInstalls the v0.7.1 Go launcher (bin/edikt) and the versioned payload under ~/.edikt/. Cosign-verified release assets, pinned to a specific release tag.
Switching versions after install:
edikt list # show installed versions
edikt install <version> # add a newer version
edikt use <version> # activate it
edikt rollback # revert to the previous versionFor the full upgrade flow with sidecar migration, status checks, and prompts, run /edikt:upgrade from inside Claude Code instead. The mechanics of each launcher subcommand — install, use, rollback, prune, list, pin management — are documented in Keeping edikt Up to Date.
Staying on the v0.4 line: if your project isn't ready for the sidecar architecture (introduced in v0.6.0, current through v0.7.1), v0.4.x still installs from diktahq/edikt-legacy (archived, read-only):
curl -fsSL https://raw.githubusercontent.com/diktahq/edikt-legacy/v0.4.5/install.sh | bashv0.4.5's installer uses a different fetch model (raw git-tag, not release assets), so its --ref only resolves to other v0.4.x tags, not v0.7.x. v0.5.x is retracted.
2. Run /edikt:init
Open any project in Claude Code — new or existing — and run:
/edikt:initInit runs in three steps. You talk to it naturally throughout — no CLI flags, no config files to edit.
[1/3] Scan
edikt scans your codebase automatically — languages, frameworks, linters, existing docs, commit conventions:
Existing project:
[1/3] Scanning project...
Code: Go project, 142 files
Chi framework, PostgreSQL
Build: make build
Test: make test
Lint: golangci-lint (.golangci-lint.yaml)
AI config: CLAUDE.md (34 lines)
Docs: 3 ADRs in docs/architecture/decisions/
Commits: conventional commits detected
Governance: verikt.yaml detected — architecture pack skippedNew project (no code yet):
edikt shows the same scan format (with "no source files detected"), then asks:
What are you building?
Example: "A multi-tenant SaaS for restaurant inventory. Go + Chi, PostgreSQL, DDD with bounded contexts."
Describe your project in a few sentences. edikt infers the stack and architecture from your description.
[2/3] Configure
edikt shows all available rules and agents in one view. Recommended items are checked based on what was detected or described. Everything else is available to toggle on:
Rules (✓ = recommended for your stack):
Base:
[x] code-quality — naming, structure, size limits
[x] testing — TDD, mock boundaries
[x] security — input validation, no hardcoded secrets
[x] error-handling — typed errors, context wrapping
[ ] api — REST conventions, pagination, versioning
[x] architecture — layer boundaries, DDD, bounded contexts
[ ] database — migrations, indexes, N+1 prevention
...
Language:
[x] go — error handling, interfaces, goroutines
...
Framework:
[x] chi — thin handlers, middleware chains
...
Agents (✓ = matched to your stack):
[x] architect — architecture review
[x] backend — Go patterns
[x] dba — PostgreSQL
[x] qa — test strategy
[x] docs — documentation
[ ] security — OWASP, auth, secrets
...
SDLC:
Commits: conventional commits (detected from git log)
PR template: yes (GitHub repo detected)
Toggle items by name (e.g. "add api", "add security"),
or say "looks good" to proceed.One screen. Say "looks good" when you're happy with the selection.
[3/3] Install
edikt generates everything and shows progress:
[3/3] Installing...
✓ Config .edikt/config.yaml
✓ Project context docs/project-context.md
✓ Rules 6 packs → .claude/rules/
✓ Agents 5 specialists → .claude/agents/
✓ Hooks .claude/settings.json (9 behaviors)
✓ CLAUDE.md updated
✓ Directories docs/architecture/, docs/plans/, docs/product/Summary
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
EDIKT INITIALIZED
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Rules: 6 packs — code-quality, testing, security,
error-handling, go, chi
Agents: 5 specialists — architect, qa, backend, dba, docs
Hooks: auto-format on edit, context on session start,
plan injection on every prompt, compaction recovery,
decision detection on session end
What just changed:
Before edikt, the model writes code with no project standards,
no architecture awareness, and forgets everything between sessions.
Now the model reads your 6 rule packs before writing any code.
Try it — ask it to write a function and watch it follow
your project's error handling and testing patterns.
Commit .edikt/, .claude/, and docs/ to git — your team gets
identical governance automatically.
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━3. Start working
From this point, every session in this project reads your rules before writing code, knows your project identity, and enforces standards automatically.
Start the governance chain:
"Write a PRD for [feature name]"
The model generates structured requirements with acceptance criteria. Accept it, then continue: "Write a spec for PRD-001", "Create a plan for SPEC-001". Each step feeds the next.
Capture decisions as you go:
"Save this decision"
The model persists it as an ADR with enforcement-grade language. Then say "Compile governance" to update the directives it follows automatically.
Check governance health:
"What's our status?"
The model shows the governance dashboard — rules, agents, chain status, gate activity, signals.
For teams
One engineer runs /edikt:init and commits the generated files. Every teammate using Claude Code gets the same governance automatically — no additional setup. The rules, agents, hooks, and decisions are in the repo.
Across projects
Run /edikt:init in each project. Each gets its own rules matched to its stack, its own decisions, its own agents. The methodology is the same everywhere.
What got generated
your-project/
├── docs/
│ ├── project-context.md # project identity
│ ├── architecture/
│ │ ├── decisions/ # ADRs (with README)
│ │ └── invariants/ # hard constraints (with README)
│ ├── plans/ # execution plans (with README)
│ └── product/
│ ├── prds/ # requirements (with README)
│ └── specs/ # specifications (with README)
├── .edikt/
│ └── config.yaml # governance configuration
└── .claude/
├── rules/ # guardrails the model reads automatically
├── agents/ # specialist agents (stack-matched)
├── settings.json # 9 automatic behaviors
└── CLAUDE.md # project block + natural language triggersAutomatic behaviors (15 lifecycle hooks):
| Behavior | What happens |
|---|---|
| Session refresh | Surfaces what changed since last session |
| Governance check | Validates setup before the model writes code |
| Auto-format | Formats code after every edit |
| Decision detection | Suggests ADR capture when decisions are made |
| Plan injection | Injects active plan phase on every prompt |
| Context recovery | Recovers plan + invariants after compaction |
| Agent logging | Logs agent activity, enforces quality gates |
| Rule tracking | Logs which rule packs load each session |
All behaviors are configurable — set any to false in .edikt/config.yaml.
Questions? See the FAQ or open an issue on GitHub.
What's next
- Cheatsheet — every slash command on one page, with the natural-language phrases that route to each one