Guide
Keeping what you learn
The costly part of working in a large codebase is rarely writing the code. It is the hours
spent discovering why something is the way it is — and the fact that the discovery evaporates when the
session ends. capture_concept is where it goes instead.
1 · Notice the moment
The signal is a specific feeling: I wish I had known that three hours ago. A platform behaving unlike its documentation, a constraint with no visible cause, a fix that looks arbitrary until you know what it prevents. Capture it before moving on — you will not come back.
2 · Reduce it to one sentence
The invariant is the whole thing. If it needs “and” to be stated, it is two concepts and should be captured as two. Everything else — the mechanism, the stakes, the case that makes it click — goes in the fields underneath, where it does not dilute the claim.
3 · Say where it applies
Relevance is a set of URI globs, and it is what makes a concept useful rather than merely stored: anyone who opens a matching file is handed it, without having to know it exists or go looking.
4 · Give it evidence, if it can have any
A claim about code should point at the code that proves it. Anchor the verification at the symbol rather
than the line — #symbol=Name keeps resolving as the file moves under it — and set a
ttlDays for how long that evidence stays trusted before it is checked again.
5 · Read what is already there
Before solving something that feels hard, ask whether it has been solved. Concepts answer to the same addresses as everything else.
Written this way, the lesson stops being something a person remembers and starts being something the repository knows.
This page names what exists. The depth behind every name — the bounds, the failure modes, how they compose — ships inside the binary at help:///, and answers to explore and read exactly like your code does. Install it, and your agent has the manual.