Today we're launching LemonBeam, an open-source tool that scans a public GitHub repository and generates an onboarding guide where every claim cites the exact file and lines it came from.
🍋Try it: lemonbeam.app
The problem
Getting started in an unfamiliar codebase means piecing together what it does, how to run it, and how the tests work from READMEs, package scripts, config files, and source code.
The obvious shortcut is asking ChatGPT. The answers are often useful, but when we checked the citations, they were fabricated, pointed hundreds or even thousands of lines away, or were missing entirely. A right answer you can't check is still a guess.
How LemonBeam is different
Rules, not AI, decide which evidence the model sees. LemonBeam downloads the repo at an exact commit, then filters, parses, and chunks the code with Tree-sitter and scores each chunk within a per-section token budget. One AI call writes the guide from that evidence only.
Every citation is checked. A separate validator removes any citation that doesn't match the evidence the model actually received.
Gaps are visible. Anything that couldn't be read or included is listed in an Uncertainties section instead of being hidden.
Every guide has the same six sections: Project Overview, Setup/Installation, Running Locally, Project Structure, Testing, and Uncertainties and Missing Information. Each guide is pinned to the commit it analyzed, so everyone on a team can generate the same guide and check it line by line.
Three ways to use it
- 🌐 Website: Paste a public GitHub URL and your OpenRouter API key at lemonbeam.app.
-
💻 CLI: Run
lemonbeamin a local folder or against a public GitHub URL, and save the guide as Markdown. - 🔌 MCP server: Add LemonBeam to Claude Code, Codex, or another AI tool, and ask your assistant for an onboarding guide.
Setup instructions for the CLI and MCP server are on the website.
Your code isn't stored
LemonBeam has no database. Downloaded repos live in a temporary folder that's deleted when the scan ends, even if it fails. Your API key exists only in memory for that one request. The only code that leaves your machine is the evidence sent to the model through OpenRouter.
The hardest bug
Our pre-MVP pipeline was quietly sending every chunk to the model, which made guides expensive and limited us to a fraction of our target repo size. Fixing it cut the cost per guide from about 70¢ to 2¢ and took our supported repo size from 2 MB to 50 MB. I wrote about the full story here: From 2 MB to 50 MB: The Bug That Almost Killed Our MVP
What's next
- Separate, parallel AI calls with tuned prompts for each section
- Citation checking that verifies the cited lines actually support the claim
- Support for larger repos, monorepos, private repos, and languages beyond JavaScript and TypeScript
- A comparison of embeddings-based retrieval against our rule-based approach
Contribute
LemonBeam is open source under the MIT License. The best way to get started? Use LemonBeam on LemonBeam! Paste github.com/oslabs-beta/lemonbeam into lemonbeam.app to get a cited guide to our own codebase, then check out the contributing guide in the repo.
Built by Kanami Anderson, John DeLong, and Tanisha Thompson-Jones.
Top comments (1)
Citations that are actually checked is the right thing to focus on. One evidence source worth weighting high for the Running Locally and Testing sections: the CI workflow files (.github/workflows/*.yml). READMEs drift, but the install and test commands in CI are the ones that ran green on the last commit. When the README says
npm testand CI runspnpm test --filter coreafter adocker compose up -d db, that mismatch is exactly what a new contributor trips on, and it would be a great thing to put in the Uncertainties section.