What inline learns
Repo memory
Repo memory is a short written profile of one repository, which inline keeps and reads before every review of it. It describes the architecture, the conventions and the fragile areas, in the same way a colleague would brief someone joining the team.
Reading and editing the profile is an admin task, on a repository's own settings. Everyone else sees its effect in the reviews.
#What the profile holds
Repo memory
What inline has learned about this codebase from past reviews: architecture, conventions, fragile areas. Injected into every review so findings fit how this repo actually works.
Architecture. Next.js app router. The review worker is in-process, started from instrumentation.
Conventions. Route handlers validate with zod at the boundary and return typed errors.
Fragile areas. Cache invalidation around head SHAs. Webhook signature handling.
The profile is a few hundred words of plain prose about the repository, and you can read all of it on the card. A typical one covers three things:
| What it records | Why the next review wants it |
|---|---|
| The architecture | Which parts of the codebase do what, so inline knows whether a change belongs where it landed. |
| The conventions | How your team writes things, so inline stops suggesting a pattern you deliberately moved away from. |
| The fragile areas | Where changes have caused problems before, so inline reads those more carefully than the rest. |
#Where it comes from
You do not write the profile. inline builds it as it goes: after each review that went as far as reading the code, it takes what it learned and folds that into the profile. Nothing is written from a review that was triaged out.
A repository inline started reviewing last week has a short profile or none. One it has reviewed for months has a detailed one. The card shows how many reviews went into it, so you can tell which you are looking at.
#What it changes about a review
The profile goes into every review of that repository, so findings arrive already knowing where they are. A reviewer who has read your codebase says different things from a reviewer who has only read the diff.
In practice you see fewer suggestions that are wrong for your codebase, and more attention paid to the parts your team already knows are delicate.
#Editing it yourself
Choose Edit and the profile opens as text you can change. Add something inline has yet to work out, correct something it has got wrong, or cut a section that describes code you have since deleted. The counter shows how much room is left.
Save memory keeps your version. Your edits stay in place, and later reviews add to what you wrote rather than overwriting it.
Editing is worth doing after a large refactor, when the profile still describes the shape the codebase used to have.
#Rebuilding it
Regenerate throws away the current profile and writes a fresh one from the reviews inline has stored. Reach for it when the profile has drifted far enough that correcting it by hand would take longer than starting again.
#Switching it off
The switch at the top of the card stops inline reading the profile, and stops it adding to it. Reviews of that repository then work from the diff and the surrounding code alone.
The profile is kept while the switch is off, so turning it back on picks up where it left off.