Buff Development
Knowledge base

Entry

What a piece of knowledge consists of: title, one-line description, type, scope, body and two flags. How to write it so the model uses it.

One entry — one fact. Not “everything about tests” but “tests fail without the environment up”.

The editor: title and address, one-line description, type and scope, markdown body, two flags.

Fields

FieldWhy
TitleWhat the entry is called for a person. The entry’s address in Latin letters is derived from it automatically (sborka-trebuet-tulcheyn) — you can adjust it by hand.
One-line descriptionThe most important field. This is what the model uses to decide whether to open the entry’s body (see how it reaches the model).
TypeRule, fact or pitfall — see types. Chosen by what the entry changes for the reader.
ScopeThe whole organisation, one development project or one task — see scopes. Only the model chooses the “task” scope in the course of work; in the editor a task’s entry can be moved to a project by choosing it here.
BodyMarkdown: what exactly needs to be known. Links to other entries — [[entry-name]]. The “Preview” toggle shows how the text will be read.
Show to the model upfrontThe entry reaches the model in full in every task instead of being opened when needed.
PermanentThe AI cannot change it or archive it. You can.

The one-line description is half the job

The model always sees an index: one line per entry of the form “title — description”. It opens the body only when the description answers its question.

So the description is written not as the title in other words but as an answer to the question “when will this entry come in handy”.

BadGood
“About tests”“Tests fail until the environment is up”
“The YAGNI rule”“We do exactly what the current task needs — no “might come in handy later””
“Payment module”“Payments go through an external gateway; the test setup is started with a separate command”

Body

Short and to the point: what to know, how to check, what to do. The model reads it in full, so extra text means extra tokens every time the entry is accessed.

A good body answers three questions:

  1. What exactly is true. “The tests need running services; they do not start them on their own.”
  2. How it shows. “The tests fail with an unclear connection error.”
  3. What to do. “Bring the environment up, wait until it is ready, then run the tests.”

Write links to other entries as [[entry-name]] — the model follows them to related knowledge.

Secrets

The editor warns you if something in the body looks like a token, a password or a key. It is a warning, not a ban: you decide. But remember that the knowledge base goes into the model’s prompt — secrets do not belong there, and a real secret that has been exposed must be rotated, not hidden.

Entries the AI tries to make are checked more strictly: the server simply will not accept an entry containing a secret.

Changing an entry

An entry is changed as a whole: open it, correct it, save it. If someone else (a person or the model) has changed it in the meantime, saving will not overwrite their edit: the editor shows a conflict warning and the entry’s current text next to yours. Then it is up to you — take the current version as the basis and make your edit again, or, having looked at it, save yours on top.

On this page