A pasteable skeleton generated from the repository name. Check the project README for the exact package and arguments.
Star count
7 ★ · Tommkruix/archprint · read from the repository page · (checked 2026-10-16 20:00:20)
Source
collected from the punkpeye/awesome-mcp-servers list · type: MCP server
Harvest history
first seen 2026-10-09 · last seen 2026-10-16 · seen 32× · listed by 7 sources
Score
score 703 · 7 ★ · 7 sources · mcp
FAQ (answers come from our records)
How do I install it?
We did not find an install command for this repository (our install coverage is only about 4%). Check its README or releases page.
Who is it for?
We filed it under these tags: MCP 服务. The tags come from the entry itself, not a taxonomy we imposed.
Who maintains it?
repository Tommkruix/archprint;first catalogued 2026-10-09;last seen 2026-10-16。There is no official certification or quality rating here — we record sources and dates only.
**Mine the architecture rules your repo already enforces, with the evidence attached.** **Try it in your browser**, nothing to install · Quick start · Use in CI · Use with AI agents · Docs What it does, in plain words Every codebase has unwritten rules. "Pages never talk to the database directly." "Shared code never reaches back into the app." Nobody wrote them down, but the code follows them, until one day someone (or an AI assistant) breaks one without noticing. Archprint reads a TypeScript project, finds the rules its code already follows, and shows you the proof for each one: how many files follow it, which files break it, and how sure it is. The rules you trust become automatic checks in the tools your team already runs, so a break is caught the next time lint runs (in your editor, a pre-commit hook or CI), not weeks later in review. Think of it as a building inspector who surveys the house first and writes down how it was actually built, instead of handing you a rulebook from somewhere else. - **For developers and tech leads:** inferred, evidence-backed lint rules for ESLint and dependency-cruiser, generated with init, connected with wire, and removed with eject. - **For reviewers:** archprint check flags only the rule breaks a pull request introduces, inline on GitHub, never the existing backlog. - **For teams using AI coding agents:** Claude Code, Cursor and other agents can ask Archprint for the project's rules, with the evidence, before they write code. - **For anyone evaluating a codebase:** a quick, honest picture of how a project is actually structured. Your CLAUDE.md is guidance. Your lint rules are enforcement. Archprint closes the gap by generating the enforcement from patterns your codebase already demonstrates, so you adopt rules you can trust instead of authoring them by hand. See it in action The recordings below use archprint-demo, a small Next.js API whose routes reach the database only through a service layer. **1. Find the rules your code already follows.** Each rule comes with its evidence. **2. See why one rule is trusted.** The confidence check, step by step. **3. Turn the rules on, watch a break get caught, and remove it all again.** Archprint writes its files, adds one line to your ESLint config, lint flags a route that imports the database directly, and eject restores your project exactly. **Try it yourself, nothing to install:** open the demo in StackBlitz. The scan runs as soon as it opens, and the demo's README walks through enforcing a rule in ESLint, breaking it, and asking for the rules over MCP. Use it with AI coding agents AI coding agents can ask Archprint for a project's rules through MCP, an open standard that lets agents use outside tools. You ask in plain words; the agent calls Archprint on its own and answers with the evidence. Archprint only reports. Enforcement still runs in your linter. **Claude Code** lists the rules with what is enforced and what is held for review, then adds a route and checks its own change with archprint before it reports back: **Cursor works the same way.** In these recordings Cursor was set to Grok 4.7, not Claude. In the desktop app's chat, its agent called Archprint's scan tool on its own; this screenshot shows the tool result and the answer: In the terminal (cursor-agent), it does the same: lists the rules, then adds the route and checks it with archprint_check: Measured: the same question with and without Archprint We asked Claude Code (Opus 5.5) "What architecture rules does this repo already follow?" on the demo app (70 files), five runs each way. Median [range]: | | Without Archprint | With Archprint | | ----------------- | ------------------------- | ------------------------- | | Tokens read | 81k [58k to 96k] | 52k [52k to 52k] | | Tokens written | 1.1k [1.1k to 1.4k] | 0.6k [0.6k to 0.6k] | | Cost per question | $0.083 [$0.078 to $0.153] | $0.037 [$0.032 to $0.076] | | Time | 17 s [15 to 19] | 10 s [9 to 31] | | Tool calls | 5 [4 to 10] | 2 [2 to 2] | What the answers showed: - Both found the main rule: routes reach the database only through lib/services/. - With Archprint, every run gave the evidence for each rule and named the one file that breaks one (lib/db.ts reads process.env outside the config layer). No run without it noticed that. - Without Archprint, Claude also described naming conventions Archprint does not check. Read these numbers with care: about 50k of the tokens read in both columns are Claude Code's own system prompt,