Developersdon'thavetostartfromscratch.
Build from your team's existing knowledge, code, and decisions — instead of rebuilding them every time.
vault/piecesauthpaymentsmailerloggerrate-limits3-uploadwebhooksfeature-flagsaudit-logexport classAuthModule {}jwt.strategy.tstokens to answer "do we have JWT auth?"
lines generated when a piece already exists
command to reuse it
Every team rebuilds the same things. Then their AI rebuilds them again.
The auth module your team perfected two projects ago still exists — buried in that repo, tangled with its dependencies, invisible to search. So the next project writes a new one, and an assistant asked the same question writes a third.
Knowledge nobody can find
It is in a repo, in a head, or in a pull request from 2023 — never in one searchable place.
AI that regenerates
An assistant with no memory of what you own writes a fresh version every time it is asked.
Why it matters now
Generation is cheap; review is not. Every regenerated module is another one to maintain.
The knowledge was never lost. It was never findable.
Capture once. Find it anywhere. Add it in one command.
Three verbs, one binary. Everything lives in a git folder on your machine called the Vault — no server, no account.
Capture
Point BWX at a folder that works. It reads the code, writes the summaries, and versions the result into the Vault as a piece.
vault/pieces/auth/0.1.0/
Find
Search by meaning, not by filename. The same index answers a human at the terminal and an assistant over MCP.
Add
One command copies the piece into the project, wires what it can, and prints the steps only you can decide.
No install step. No registry.
Layers
Code, plus everything you'd otherwise have to ask a colleague about.
├── card.md ~50 tokens
├── surface.md ~200–400
├── summary.md ~500
├── piece.toml
└── src/
├── auth.module.ts
├── jwt.strategy.ts
└── …4 more
"Do we have something for X?"
JWT + refresh tokens for NestJS services.
kind: code · nest, jwt, passport
proven in 3 projects
"How do I call it?"
"Why was it built this way?"
Whoever is asking — human or AI — climbs only as high as the task needs.
Your assistant gets a librarian instead of the whole library.
brico mcp exposes the Vault over the Model Context Protocol. Claude, Cursor, IDE agents, internal copilots — any MCP-capable assistant can search your pieces and recommend reuse before writing anything new.
search_pieces(query, kind?)Meaning-based search across the Vault.
get_piece(name, level)Card, surface, summary or source — the caller picks.
plan_reuse(task)What to reuse for a task, and what is genuinely new.
get_relations(name, kind?)What this piece depends on, and what depends on it.
One exchange
~300
tokens · Vault answer
Full repo scan
Repo-indexing assistant
A 10,000-piece Vault carries about 40 MB of vectors — it fits on the laptop that asks the question.
Architecture
Boring on purpose: files in git, one SQLite index, one binary.
The Vault is a git directory
Plain files you can read, diff, review and revert. History is git history.
One index.db
sqlite-vec plus FTS5, zero runtime dependencies. Delete it and it rebuilds.
Embedding generation is the only step that touches a network, and it is always skippable.
Roadmap
Four phases, in this order.
Knowledge layer
Summaries at capture · meaning-based search · the MCP server.
AI piece kinds
Prompts and agent skills captured and versioned like code.
Accounting & graph
What was reused where, and what depends on what.
Team scale
Shared Vaults, review flow, an optional hosted tier.
FAQ
Questions worth asking.
A command-line tool that keeps your team's proven code as versioned, searchable pieces — so engineers and AI assistants reuse them instead of rebuilding them.
No. BricoWerx does not generate code. It indexes, searches, and manages code your team has already written and validated, allowing you to reuse what works instead of generating a new, unproven version.
No. It operates within your own repository (or a shared local Vault) directly on source files. There is no external registry, no publishing step, and no hidden node_modules folder. Pieces are copied directly into your project where you can see and modify them.
None of the above. The Vault is a plain git directory on your local machine. The search index is a local SQLite database that the binary manages for you. It works completely offline.
Because pieces are just files, BricoWerx supports any stack. However, the automated wiring (like updating imports) currently works best for TypeScript/JavaScript ecosystems.
The Vault opens soon. Be in the first cohort.
We're finishing Phase A: summaries at capture, meaning-based search, and the MCP server.