RepoLens Version Two helps engineering teams understand what changed and what matters across repositories, branches, and pull requests. It analyzes PRs, detects affected modules and changed endpoints, highlights review hotspots, powers branch-aware chat with grounded code references, compares branches structurally, and sends alerts for important changes so teams can understand evolving codebases faster with more trust.
I built RepoLens Version Two to solve the next problem after repository understanding: understanding change.
Version One helped developers understand unfamiliar repositories faster through module maps, dependency graphs, API discovery, generated docs, grounded repo chat, and branch comparison.
But understanding a repository once is not enough. Repositories keep changing. Pull requests introduce risk. APIs evolve. Architecture drifts. Teams need to know what changed, what was affected, and what actually matters.
RepoLens Version Two is built for that workflow.
It can now analyze pull requests, generate engineering summaries, detect affected modules and changed endpoints, highlight likely review hotspots, support branch-aware and PR-aware repo chat with exact code references, compare branches structurally, detect architecture drift, and send alerts for meaningful changes.
What makes RepoLens different is that it does not rely on generic AI output alone. It first builds a structured understanding of the repository and its changes, then uses that foundation to provide more grounded, navigable, and verifiable insights.
I would love feedback on the PR intelligence workflow, branch-aware chat experience, change detection quality, and which signals would be most useful for real engineering teams.
Really powerful idea: understanding what actually changed across PRs, branches, and the codebase instead of just scanning diffs could save devs a ton of mental overhead. Congrats on the launch! What has been the hardest part about accurately identifying “what actually matters” versus just listing changes? 🚀
One thing I’d really love feedback on:
If you work in fast-moving repositories, which signal would be most useful to you first?
PR summaries
affected modules
changed endpoints
review hotspots
branch-aware chat
architecture drift alerts
Curious which one feels most valuable in real engineering workflows.
How is this different from just using ChatGPT on a repository or asking GitHub Copilot questions?
Love the focus on structured understanding, but how do you plan to handle situations where multiple PRs touch overlapping modules? That could muddy the waters for teams relying on clear insights.
