Launched this week
Greplica
Self updating wiki for coding agents
345 followers
Self updating wiki for coding agents
345 followers
Greplica gives your engineering team and every coding agent a shared memory of the codebase. It continuously extracts decisions, constraints, gotchas, failed approaches, and file-level context from coding sessions, then retrieves only what matters for the task at hand. Unlike static docs or siloed agent memory, Greplica stays grounded in the repo, keeps knowledge fresh, and works across developers, agents, clones, and forks. It is open source, runs locally, and offers a managed shared mode.
Greplica
Can I see exactly what it has learned and remembers, and edit or expand it if necessary? For example, in the form of concise documentation or something similar.
Greplica
@natalia_iankovych yes you can. Graph view will expose it in readable format you can view.
And you can ask claude to change any facts as well
Congratulations on the launch 🎉🔥
Does this work only with Claude Code, or can a team share the same memory across Claude Code, Cursor, Codex, and Copilot?
Greplica
@yashkhem Its built exactly for this use case. Completely agent agnostic
Anchoring facts to committed code is the part that convinced me — it gives stale knowledge a natural expiry date, which hand-written docs never have. I maintain around ten repos on my own and my claude.md files rot faster than the code does. What I couldn't tell from the page: how does Greplica sit next to an existing claude.md or agents.md — does it replace them, feed them, or end up competing for the same context window?
Greplica
@soysebalopez we ingest Claude.md in our system itself. So that you can remove it completely.
At least the docs reading part
Anchoring facts to committed code handles the "what does this do" half. The half I'd worry about is "we tried X and it didn't work", because that isn't anchored in anything and it's the note that costs the most when it's wrong. One bad conclusion from one bad session becomes ground truth for every agent run afterwards, and it reads exactly as confident as a true one. What retires a fact, other than the code it points at moving?
The "what does this do" vs "we tried X and it didn't work" distinction is the sharper problem here, agreed. I hit a smaller version of this manually, a running status doc plus session handoff notes so context survives between sessions, but that only catches drift I remember to write down myself. Your harder case is the one with no code artifact to signal staleness at all. Does anything actually retire one of those "we tried X" facts, or does it just sit there until a human notices it's wrong?
@madareyou Nothing retires it today as far as I can tell, and that's the gap. The closest thing to a trigger is making the negative fact carry what it was true against, a commit and the actual error, so a later run can check whether it still reproduces instead of trusting the note. Without that, a wrong 'we tried X' is permanent, and it's the expensive kind of wrong because it stops the thing being attempted at all.
@asadmalik901 You and Juraj are circling the thing that actually breaks these systems, and I don't think "anchored in committed code" quite reaches it.
I've been running a docs/ memory folder for my own agent setup for a while now. "What this module does" self-heals — the code moves, the fact looks wrong, someone fixes it. A "we tried this approach and it fell over" note has no such trigger. Nothing in the repo changes when it stops being true. It just sits there getting more confident with age, and every agent run downstream inherits it as fact.
What worked for me wasn't better extraction, it was making the negative facts carry their evidence — which session, which error, which commit it was true as of. Staleness becomes checkable instead of a vibe: if what it points at is two refactors old, it gets surfaced for review instead of silently retrieved.
So — does Greplica keep provenance on a "we tried X" fact, or is it stored flat alongside the code-anchored ones? That feels like the difference between a wiki that compounds and one that slowly poisons every agent reading it.
@rabnoor_s Provenance is the right shape, and the bit I'd add is that the fact should be re-testable, not just dated. 'This failed at commit abc with this error' is something an agent can cheaply re-run, whereas 'we tried X' is only ever a vote. Dated evidence tells you to doubt a fact, a reproducible check tells you whether to delete it.
@asadmalik901 That is a better version than mine and I am going to steal it.
Dated evidence tells you to doubt. A reproducible check tells you to delete. That distinction does real work.
Where I get stuck is the class of facts that cannot be made re-testable. "This vendor takes three weeks to come back." "That framing lost us the deal." No commit, no error, nothing to re-run. Most of the expensive knowledge in a company looks like that, not like a failing test.
Best I have is forcing an expiry at write time so a human has to actively renew it. Feels crude and I do not love it.
You have chewed on this longer than I have. Is there a version that works for facts with no artifact underneath, or is that the part you just accept will rot?
@kushal_patil Congrats on the launch! with multiple clones and forks feeding the same wiki, how do you handle two forks that genuinely diverge in approach?
Can this also be used by product managers for data analytics? Will it be more efficient?
By giving them documentation of existing tables?
Greplica
@kritin_garg Yes, that will work well too
@kritin_garg Your question deserves a longer answer than it got, because the two cases are genuinely different.
Table documentation is the easy half. Column names, types, which table joins to which. That lives in the schema, and a tool anchored to committed code can keep it honest because when the schema changes the fact visibly stops matching.
The half that actually hurts a PM is the part with no artifact behind it. Which of the three revenue columns is the one finance actually uses. Why that table has a duplicate row for every order placed before a certain migration. Which dashboard everyone quietly stopped trusting. None of that is in the schema and none of it can be re-derived from code, so nothing tells you when it goes stale.
So it would work, but it would be strongest exactly where you need it least. If you try it, the thing worth testing is whether it captures the second kind at all, because that is the knowledge that actually walks out of the door when someone leaves.