Veri Docs GitHub Download

The system of record for product intent

Agents can build anything. Veri helps you decide what should be built — and whether it worked. Evidence, requirements, decisions, and work orders live as plain Markdown in your repo, and each coding task gets the context it needs — without rebuilding the project from chat history every session.

npm install -g @verikb/cli
Download for macOS View on GitHub 10-minute quickstart
macOS 13+ · Apple silicon & Intel · free & open source

Also for Windows 10+ and Linux (AppImage · .deb) — the Windows installer is unsigned for now, so SmartScreen warns on first install; the ~120 MB AppImage auto-updates and bundles its own WebKit; the .deb is smaller but doesn't auto-update. The CLI and MCP server are on npm and run anywhere Node 20+ does — npm install -g @verikb/cli on any platform.

Veri
acme-invoices
2
main · clean
work-ordersWO-002

PDF export pipeline

in-progress
Summary

Render branded invoice PDFs from the invoice data model. Output must be deterministic and print-identical across machines, per [[REQ-001]].

In scope
Template compilation with Typst, per [[DEC-005]]
Invoice numbering follows [[REQ-003]]
Out of scope: email delivery, batch export
Acceptance tests
Sample invoice renders byte-identical on two machines
Custom fonts embed correctly in exported PDF
Rendering fails loudly on missing template variables
CONTEXT PACKAGE9 docs · ~1.8k tokens
WF-001Workflow~210
WO-002PDF export pipeline~340
REQ-001Branded PDF invoices~180
REQ-003Invoice numbering scheme~140
DEC-005Typst for PDF rendering~260
DEC-004Invoice data schema~190
DEC-002Rust core owns rendering~150
DEC-001Local-first data storage~140
SRC-002Invoice requirements interview~160
+ DEC-003 rides along by name only — flagged already rejected
the real interface, miniaturized — switch documents, start the agent session, approve what it files
Local-first

Plain files are the architecture

veri/decisions/DEC-005-typst-for-pdf-rendering.md
decisionsDEC-005

Typst for PDF rendering

active
Choice

Compile invoice templates with Typst, embedded in the Rust core.

Rejected alternatives
Handlebars + headless browser — the [[DEC-003]] approach; slow and nondeterministic print output.
LaTeX — deterministic but a 4 GB toolchain dependency.
flip the toggle — same document, same bytes

A Veri project is a veri/ directory of readable Markdown. The files are the source of truth — the app is a view over them.

Four things operate on the same knowledge, and none of them owns it:

  • The Veri appreads and edits the files
  • Your editoropens them like any Markdown
  • Gitversions, diffs, and syncs them
  • Your agentretrieves them over MCP

Delete Veri and your project knowledge is still a folder of Markdown that renders on GitHub.

Context, not prompt engineering

Why not just CLAUDE.md and an ADR folder?

Every new agent session starts with incomplete institutional memory — the session ends, and everything it learned evaporates.

If you keep an agent-instructions file — CLAUDE.md, AGENTS.md — and architecture decision records, you already believe the idea. What a folder of files can't do is scale with the project: one file carries everything, into every session, and nothing checks that any of it still holds. Veri keeps the plain files and adds the four things the folder can't.

A growing CLAUDE.md

  1. one file carries everything, into every session
  2. every task pays the whole file's token cost
  3. no links between documents — nothing flags drift
  4. an agent edit becomes an instruction, silently
  5. outcomes scatter across chat logs and commit messages
  6. prune it by hand, or watch it rot

With Veri

  1. each task gets a scoped package — only the documents linked to it
  2. typed links between documents, and veri check flags what breaks
  3. agent writings arrive as drafts you promote
  4. finished work files a receipt on the work order
  5. knowledge accumulates; the per-task cost doesn't

Keep your CLAUDE.md — Veri is what it points at. This repository's own is two lines, and the second says to fetch the context package.

Scoped context

The agent gets a package, not a repo dump

The context package for a task is the documents linked to it — the project workflow, its requirements, every active decision within two hops, source excerpts. Typically a few thousand tokens, with a per-document estimate, assembled fresh from current file versions every time. It's the panel on the right in the demo above.

Superseded decisions ride along by name only, flagged as already rejected — so the agent doesn't relitigate them.

You see the exact package before the agent does, and start the session from it with one click.

CONTEXT PACKAGE — WO-002~1.8k tokens
The project's working rules ride in every package: how decisions are filed, what needs approval.
The task itself — deliverable, scope, and acceptance tests.
Linked as "implements" — the requirement this work order exists to satisfy.
Referenced from the work order's in-scope list.
Active decision directly linked — constrains the implementation approach.
Active decision one hop away via REQ-001 — the data the pipeline renders.
Active decision within two hops — where this code must live.
Active decision within two hops — no server round-trips in the export path.
Source excerpt — the customer evidence behind REQ-001.
+ DEC-003 by name only, flagged already rejected · rebuilt from current files on every request
click a document to see why it's in the package
Decisions

Decisions that stay decided

A decision records what was chosen, why, and which alternatives were rejected — like DEC-005 above. Active decisions travel into every future context package they constrain. Agents stop re-opening what you settled in March — and when a decision is superseded, the package says so.

Human approval

Agents propose. You decide what becomes canon.

Agent-written requirements start as drafts, agent-filed decisions as proposals — labeled non-binding until you promote them. Nothing an agent writes silently becomes project truth.

NEEDS REVIEW1 pending
REQ-004 Import time entries from CSV draft
the review queue on the home view — try Promote

And when a session finishes, work comes back as receipts: when, which commit, which files, what was done — appended to the work order itself.

Decisions, approvals, status changes, and receipts are ordinary file changes. The evolution of the project's reasoning is as inspectable as the evolution of its code: git diff shows every word.

Agent-native

Works with your coding agent

Veri exposes the knowledge base over MCP, the open protocol coding agents already speak. One click writes the project's .mcp.json; your agent gets ten tools to read context and file work back. No prompt pasting, no lock-in to one model.

Veri detects the agents on your machine and starts a session from the work order's kickoff prompt — or copy the prompt into any client that speaks MCP.

Something else? Any MCP client works.

.mcp.json — written by Veri at the project root
{
  "mcpServers": {
    "veri": {
      "command": "node",
      "args": [
        "…/@verikb/mcp/dist/server.js",
        "/Users/you/code/your-project"
      ]
    }
  }
}
get_context · search · get_document · get_neighbors · file_decision · file_work_order · file_requirement · file_source · file_receipt · get_import_instructions

Give your agent a memory that outlives the session

Free, open source, local-first. Your knowledge base is yours — Veri just keeps it working. And the repo practices what it preaches: Veri is built by executing Veri work orders.

Download for macOS Star on GitHub or start with the quickstart
Apple silicon & Intel
The app runs on macOS 13+, Windows 10+, and Linux (AppImage or .deb). The CI gate, CLI, and MCP server are plain Node and run anywhere Node 20+ does — the CLI and MCP from npm: npm install -g @verikb/cli.
Apache-2.0 · browse the sample knowledge base on GitHub · changelog