Balaur gets more useful over time by growing its own knowledge — facts it remembers and procedures it learns. Growth is suggest → approve: Balaur proposes a reviewable change; you say yes; it ships. No model retraining, no black box. We deliberately split the two so each rides the simplest mechanism that fits, instead of a custom unified index:
| Memory (facts) | Skill (procedure) | |
|---|---|---|
| Is | a fact (who/what/preference/decision) | a procedure (how to do a recurring thing) |
| Lives | vault/memory/ — private (gitignored) |
pi/skills/<name>.md — tracked (reviewable) |
| Tool | memory_write |
skill_write |
| Engine | Balaur’s own FTS5 index; auto-recalled on local/private terminal turns (recallContext) |
Pi-native skills — Pi discovers, injects & invokes them (/skill:name) |
| Keystone | whenToUse (natural-language “use this when…”) |
description (Pi’s surfacing hint) |
Memory is plain Markdown facts under vault/memory/, indexed by a disposable FTS5
accelerator and recalled by relevance; the body is organic and the frontmatter (whenToUse /
tags / pinned) is an optional retrieval aid. Pinned pages are always in context; the rest
surface when relevant.
Skills are Pi-native. A skill is a Markdown file under pi/skills/ with name /
description frontmatter (the Agent-Skills standard). Pi itself discovers them, injects their
descriptions into the prompt, and lets you invoke one explicitly with /skill:name — so Balaur
keeps no custom skill index. skill_write simply writes the file; pi/ is a Pi package
(its package.json pi manifest), so the new skill is loaded on the next start.
A third, heavier rung exists for when a procedure needs real new code (API calls,
computation): a code skill — a TS Pi extension under ../code-skills/
(distinct from the Markdown procedure skills in pi/skills/), gated by make skill-check. Most
growth never needs it; prefer a procedure skill.
detect → suggest → approve → write → ship → refine / consolidate
skill_write the procedure (with a clear description); set up the memory area.pi/skills/: commit → push → /reload in the balaur
terminal, and Pi loads the new skill. Memory facts are personal and just live in the private
vault (backed up via backup.sh).memory_duplicates to spot near-duplicate facts and propose a merge; and propose
removing a skill that’s gone unused or been superseded. Knowledge organizes itself by
addition and subtraction, not just accretion.pi/skills/) and code skills land as
reviewable git changes; memory is reversible (git revert, or the vault’s own history).scripts/skill-validate.ts (denylist + capability header +
compile) before a human approves. Procedure pages need only your approval (no code = low risk).Each step forward requires the previous one to be boring and trusted first.
Balaur’s design is a deliberate 80/20 of a crowded space. What we borrow, and the heavy machinery we decline (great ideas at disproportionate cost for a single-user box):
whenToUse surfacing hint and a
suggest → draft-card → confirm flow. Take: whenToUse + the suggest-then-confirm gate.
Skip: the card is just a git diff; the store is just files.whenToUse gives ~80% of recall for a fraction of the moving
parts (no embedding model, extraction provider, server, or graph).git revert is our rollback). Skip: the standing job.The throughline: plain files + git + your approval — FTS5 for facts, Pi’s own skill system
for procedures. We add a feature only when ~80% of its value can’t be had for ~20% of the build,
and we remove anything that stops paying for itself: we carried a unified memory+skill index
briefly and cut it once Pi-native skills did the procedure half for free (and dropped an
importance field that wasn’t earning its place in ranking).