This release comes with improvements on the auto update process and better detection of linux tooling so keyboard shortcuts can work better. Also improved the website with more specific instructions for linux so people can troubleshoot better.

Let me know what you think!

Two months ago I posted here about Archgate, a CLI that turns Architecture Decision Records into machine-checkable rules so AI coding agents follow your architecture before writing code. The post got 40+ upvotes and some really sharp feedback. I want to close the loop on what changed.

The feedback that mattered most

The top comments were clear:

u/CasuallyRanked (28 pts): "Can this not just be achieved with a skill that tells Claude to look at some ADRs?"

u/Dnomyar96 (23 pts): "This feels like an overengineered solution. You can just store it as files somewhere and tell Claude to look at those files."

u/Enahpets (13 pts): "Claude.md is a flat file → it's best practice to keep it small, almost like an index, linking to other files. Progressive disclosure. So just like your MCP but no need for the MCP."

u/Agreeable-Weekend-99: "I've often made a bad experience with MCP tools about using a lot of tokens at session start, even when not used."

u/musty_mage: "I see this as useful to enforce cross-repo ADRs... Not sure if ADR is the correct term here though. These are much lower level rules."

All valid. Here's what I did about each one.

1. The MCP server is gone

The most-upvoted critique was about complexity. The MCP server added a running process, a connection to maintain, and token overhead from tool registration. It's been fully removed.

Everything now runs through the CLI. archgate check validates code. archgate review-context returns ADR briefings for changed files. The editor plugins invoke CLI commands directly: no server, no protocol overhead, no extra process.

This also simplified the architecture significantly. The CLI is a standalone binary (compiled Bun, ~55MB, no runtime dependencies). It works the same whether an AI agent calls it, a human runs it, or CI executes it in a pipeline.

2. Five editor integrations, not one

The original post was Claude Code-centric. Now there are plugins for:

Editor	Integration
Claude Code	Full plugin: developer agent + architect, quality-manager, adr-author, onboard skills
Cursor	Developer agent + governance skills
VS Code	Extension that distributes governance skills to GitHub Copilot
GitHub Copilot	ADR context via the VS Code extension
OpenCode	Agent bundle: developer + 4 subagents (architect, quality-manager, adr-author, cli-reference)

Same ADRs, same rules, same archgate check regardless of which tool writes the code. The governance layer is editor-agnostic. This was always the goal, but now it's actually shipped.

3. Token savings are real and quantified

u/Agreeable-Weekend-99's concern about token overhead was spot on. The plugins now use a review-context command that pre-computes a focused briefing. Only the ADRs that apply to the files being changed, condensed to ~20 lines per ADR (Decision + Do's and Don'ts). The AI reads that instead of grepping through your codebase to discover conventions by trial and error.

The result: ~67% fewer tokens per task compared to an unguided agent. Fewer tool calls, fewer context-discovery loops, and the AI gets it right on the first try more often.

4. The "is ADR the right term?" question

u/musty_mage raised a good point: traditional ADRs document big decisions ("we chose PostgreSQL"), while Archgate ADRs can be granular ("API routes go in /api, use this error handling pattern").

I kept the ADR term, but the framing shifted. Archgate ADRs are executable architecture decisions, they document both the what (markdown for humans and AI) and the how (TypeScript rules for automated enforcement). They range from high-level ("we use React for the frontend") to granular ("every CLI command must export a register*Command() function"). The spectrum is a feature, not a problem.

The key differentiator from "just writing files the AI reads" remains enforcement. The ADR is a document. The companion .rules.ts is a check. Together they're a governance unit that works in CI, pre-commit hooks, and during AI-assisted development. The same rules for humans and agents.

5. Progressive disclosure, built in

u/Enahpets's advice about progressive disclosure was already something we were moving toward. The review-context command is exactly that, an index that returns only the relevant ADR briefings for the current change set, not the entire governance corpus. The AI loads the full ADR only when it needs deeper context.

What the numbers look like now

Metric	At original post	Now
Version	v0.26	v0.33.1
Editor plugins	1 (Claude Code)	5
npm downloads/month	~0	~3,700
GitHub stars	~10	32
Platforms	macOS ARM, Linux x64	+ Windows x64
MCP server	Required	Removed
CI integration	Manual setup	GitHub Actions (archgate/check-action@v1)

Getting started

curl -fsSL https://cli.archgate.dev/install-unix | sh
archgate init

Or: npm install -g archgate → archgate init

archgate init scaffolds the .archgate/ directory with a sample ADR and rule. From there:

1. Edit the ADR to match your team's actual decisions
2. Write rules in the companion .rules.ts (plain TypeScript, defineRules() API, no DSL)
3. Run archgate check — violations report file paths, line numbers, and the ADR that was violated
4. Add archgate check to CI to block non-compliant merges

The ADRs are the same ones your AI agents read as context. One source of truth, two enforcement points.

What's next

• Starter ADR sets for common stacks (TypeScript API, React frontend, monorepo) so teams don't start from a blank page
• Community marketplace (archgate/awesome-adrs) for sharing and discovering ADR sets
• Pre-commit hook packaging for husky/lefthook/pre-commit ecosystems

Links

• Website: archgate.dev
• GitHub: github.com/archgate/cli
• Docs: cli.archgate.dev
• Install: curl -fsSL https://cli.archgate.dev/install-unix | sh