Team memory and learnings
Teach the bot your conventions by replying to comments — and review what it has learned.
Generic reviewers do not know your codebase's intentional patterns. They do not know that your unused constructor argument is wired by a DI container, or that your ORM enforces null checks at the query layer, or that your team has standardized on a custom error type. Without a way to teach them, they keep flagging the same things on every PR — forever.
Revvu fixes this with team memory. You teach the bot in plain English by replying to its comments on GitHub. The next review picks up what you taught and uses it as context.
How teaching works
Reply to any bot comment in the PR thread the way you would explain the convention to a new teammate. No special syntax, no slash commands, no labels. Examples:
- Dependency injection — We use dependency injection here on purpose, that's why the constructor param looks unused.
- ORM null safety — Our ORM does null checks at the query layer — flagging null on the result is a false positive.
- Custom error type — We always throw AppError, never raw Error, in this codebase.
Volunteering rules via @mention
You can also teach the bot proactively without waiting for a review comment. Mention it on any PR and describe the rule you want remembered: "@revvu-ai remember we never use useEffect for data fetching in this codebase". The bot stores the rule and confirms it in the thread. This path is useful for encoding conventions before the bot even has a chance to flag them.
What gets stored
Every reply is classified into one of five intents: learning, correction, disagreement, question, or acknowledgement. By default, only learning and correction are stored as permanent rules. Questions and acknowledgements get a conversational reply but do not adjust future reviews. You can change which classes get stored via the storedFeedbackClasses setting in the Tier 3 (Learning) section of repo settings.
Where learnings live
Learnings are stored in Revvu's own database, scoped to your repository. No third-party memory service is involved. Your data stays within the Revvu platform under the same privacy and retention policy as your review records. You own the data and can delete it at any time.
How duplicates are handled
Before a new learning is written, the bot checks it against your existing rules. If it is semantically equivalent to something already stored — same intent, different phrasing — the new version replaces the old one rather than creating a duplicate. The dedup decision is made by the bot itself; when uncertain, it keeps both rules and lets you clean up from the dashboard.
Per-repo scope
Learnings never leak between repos. Your payment service learns about payments. Your frontend learns about UI conventions. Your data pipeline learns about ETL idioms. Each repo builds its own memory, and the bot only consults the memory for the repo it is currently reviewing.
How learnings shape future reviews
Before each review the bot loads all stored learnings for the repo and injects them into the reviewer's context. When a comment is influenced by a stored rule, the bot adds a footer attribution like "Based on team memory: <rule>" so you can see which learning produced it. The attribution is controlled by the includeLearningsAttribution setting and can be turned off if your team prefers cleaner comment bodies.
Managing learnings
Each repo's dashboard page at /dashboard/repos/[id] has a Learnings tab listing every captured rule alongside the conversation that produced it. You can delete individual rules when a convention changes, or use "Clear all" to reset the repo's memory entirely. Cleared learnings are gone — there is no soft-delete.
Configuration knobs
| Setting | Default | Effect |
|---|---|---|
| learningsEnabled | true | Master switch. When off, no learnings are fetched or injected during reviews. |
| maxLearningsInjected | 50 | Cap on how many learnings can be injected into a single review. Prevents prompt bloat on repos with hundreds of stored rules. |
| feedbackCaptureEnabled | true | Whether replies to bot comments are processed at all. Off means the bot will not respond to or learn from feedback. |
| storedFeedbackClasses | ["learning", "correction"] | Which feedback intents become permanent rules. Add "disagreement" if you want disputed findings to also adjust future reviews. |