benchbook
↑↓ navigate↵ openDocs · Wiki · Contract
GitHub
A markdown wiki, in git, kept by an agent

Your AI keeps the wiki.
You keep the rules.

You work with an AI agent on projects, and instead of losing the reasoning behind your decisions, the agent files it into a structured markdown wiki — under a written contract that governs what it may write, what it must ask you about, and what it can never touch.

No app. No database. No embeddings. Just files an agent is disciplined about.

See it work

Three ordinary tasks, walked step by step in A Day in the Life.

IngestYou saw a funky ESP32 project and want to build itThe video becomes a source page with the transcript embedded. The build becomes a separate project page — and nothing gets written until you've approved a plan./wiki-ingestDecideYou want a self-hosted bot, but don't know which repoResearch four candidates, record why the most popular one lost, then deploy with seven boring integration steps pre-filled and unticked./wiki-project-startLearnYou want to learn to fly FPV dronesA learning path with gates between phases, a price baseline before you shop, and every gear option you rejected, with your reasoning, dated./wiki-project-start

The three problems it solves

Two of them only show up after the wiki exists.

01

Reasoning decay

Code survives, but why you made a decision doesn't. benchbook captures the rejected alternatives, the reasoning, and the context alongside the artifact.

The concept →
02

Wiki abandonment

Humans stop maintaining wikis because it's tedious. An AI doesn't get bored, so the maintenance cost drops to near zero.

Why the obvious fixes don't hold →
03

Wiki bloat

The counterintuitive failure mode: when maintenance is free, you get too much content. A significant chunk of the contract exists to make the agent write less.

Keeping it honest →

What's actually in the repo

Six moving parts. Mostly plain markdown, plus 870 lines of dependency-free Python and shell.

01

The contract

One file the agent reads at session start: hard rules, page conventions, what needs your approval. It is co-owned — the agent proposes changes to it and never edits it silently.

Read agents-core.md →
02

Page types and domains

source, entity, reference, project — each with a template, required frontmatter, and a placement rule that decides where a thing goes before you have to think about it.

Page types →
03

Indexes

Per-domain catalogues the agent reads before answering. This is the retrieval layer. No vector store, no embeddings, nothing to re-index after an edit.

How retrieval works →
04

Relations

A typed graph across the pages, drawn from a 36-term controlled vocabulary. Each fact is stored exactly once, so a script reads it back from both directions — what runs on this, what backs it up, what a decision touched.

The second axis →
05

Skills

Packaged procedures for the recurring jobs: ingest a source, start or open a project, stress-test a plan, lint, close a session. They carry a maturity field, because a skill with no uses might be new or might be dead.

The core six →
06

Checks

Every mechanical rule as a script you can run in a fresh clone. Errors block a commit through a git hook; warnings never do; anything needing an opinion stays advisory and goes in a report.

Keeping it honest →
Problem 01, in practice

“Why did I pick that library three months ago?”

How was it built?Which stack, which wiring, which of the four config files is the live one.
When, and what since?Dated, in git, with a change history on anything whose state actually moves.
Why that way?Including the options you considered and dropped, and what ruled each one out.

A README captures the first. Git captures the second. Almost nothing captures the third — and the third is the one you actually miss.