Teach it your repository

An agent that starts every ticket from nothing rediscovers your conventions every time, and guesses at decisions somebody already made. A knowledgebase is where that knowledge lives between tickets.

What a knowledgebase is

A folder of Markdown a project points at: a wiki, an Obsidian vault, the notes a product team keeps. Agents read it before they shape, plan and build, and write back what they learned once the work has landed.

It is a git repository, so several people and several machines can feed the same one. One base can serve several projects, and one project can point at several bases. The Knowledge page in the sidebar lists them.

Each card carries one status and the one button that answers it: Up to date, N new files with Update, Needs update, N issues with Fix issues, Learning stopped with Resume, Updating while a pass runs, or Empty. The sidebar shows an amber count when a base needs a person. Under the name sit the folder, the file count, a link to the history of recent passes, and which projects consult it.

The four ways to start one

Create knowledgebase asks for a name and a source.

From codebase. An agent reads a project and writes the wiki. Pick the agent, model and effort, and the card turns violet with the pass running on it: reading the repository, writing the area pages, then the patterns, concepts and index, with the agent’s current action and the elapsed time underneath. Stop keeps everything written so far and leaves the base as Learning stopped; Resume picks up where it left off rather than starting again.

New wiki. An empty wiki that fills up as tickets land. Nothing is consulted while a base is empty, so it costs nothing until the first ticket lands, and that first ticket is the first entry.

Existing folder. Notes or a wiki you already have. Your files stay exactly where they are and are declared immutable sources: agents read them and never rewrite them. The wiki is seeded beside them. A folder that already is a wiki is left alone.

From GitHub. A wiki someone shares, cloned and kept in sync.

Unless you switch it off, a new base gets a private GitHub repository through the sign-in you already use, and its first commit is pushed.

What a ticket gets

Before the first pass that needs it, a read-only run reads the base against the ticket and writes a short brief: which areas, components and conventions apply, with paths into the wiki; what was decided before and where; and what it could not find, so nothing is invented to fill the gap.

The brief is stored on the ticket, shown in the drawer’s Knowledge section with links to the pages it cites, and reused across shaping, planning and execution. One consult per ticket is the normal cost, not one per phase. When the base moves on, the brief says so and can be run again.

How pages get written back

Every ticket that lands is written into the base as a source and ingested following the base’s own rules: the pages it touches are updated, the index gets its line, the log gets its entry. A file you drop into the folder yourself is ingested a few seconds later without pressing anything, and a push from somebody else is pulled in and ingested the same way.

The project’s Knowledgebase section decides how that lands.

Per base, it sets the agent and model that consult and write, and Updates to the wiki: Apply directly, which commits, or Suggest for review, which opens a branch and a pull request for whoever owns the base. Every landed ticket teaches the wiki; the only choice is how the change arrives.

The health check

A wiki that only ever grows drifts. Health check reads the whole base, then fixes what the sources settle: contradictions, pages nothing links to, claims the code has moved past. It follows the base’s own rules and leaves open only what a person has to decide, such as two sources that disagree with neither newer. It runs on its own after every ingest, and on demand from its button. Its changes land through the same Apply or Suggest setting.

The page graph

The graph button on a card draws the base the way Obsidian draws a vault.

Every page is a node, every link an edge, coloured by top-level folder. Pan and zoom, hover for a title, click a node to read the page and see what links to it and what it links to.

Note

Bases live in their own folders, never inside your repository. No run can write to one except the pass that teaches it, and that pass cannot write outside the wiki.

Next

Write a ticket — a brief only helps a ticket that says what it wants. Projects holds the per-project Knowledgebase section.