Evidence finds the issue
Your public work is matched to open, unassigned issues — biased toward under-served repos and maintainers who registered here asking for help.
OPEN SOURCE HAS A TRUST PROBLEM
The test happens before the code.
Litmus matches contributors to issues they can actually land, pressure-tests their approach against the real codebase before a line is written, and hands maintainers a queue where work that can explain itself rises to the top.
Powered by GPT-5.6 reading real repositories · Litmus never guesses who wrote the code — it tests whether the work can explain itself.
CONTRIBUTOR MATCHING
Work that fits the work you've already done.
Evidence over self-reporting: Litmus reads your repositories, languages, and topics, then finds open, unassigned issues in repos that actually want the help.
Reading repositories, languages, and topics… then searching live GitHub issues…
Your next good contribution is out there.
Enter a public GitHub username. You'll get a skill map built from real evidence and a shortlist of issues where that evidence gives you the best chance of a merged PR.
CONTRIBUTION TRAIL
Proof you did the thinking, not just the typing.
Every orientation, plan, revision, and trust brief is recorded here. Revising a plan after repository feedback is the strongest signal Litmus can show a maintainer.
HOW LITMUS WORKS
Four steps, and the code comes last.
A tour before you touch anything
Litmus reads the implicated files, their callers, the tests, and the constraints that trip people up — and briefs you in sixty seconds.
Your approach meets the real code
State your intended approach. Litmus surfaces the specific collisions a naive plan would miss, tied to real functions with file:line evidence.
Your PR arrives pre-explained
The maintainer gets a trust brief: what the change does, whether you revised when corrected, and one sortable verdict.
PRIORITY WORKSPACE
Tell it what matters. It rebuilds the queue.
Litmus reads your open issues and PRs against the repo's structural memory, then ranks both around your stated intent — auth refactor first, public API changes first, first-timer-friendly first. Your call.
Connect a repository first (Repositories tab).
A queue with context, not guesses.
Connect a repository, say what matters this month, and Litmus ranks real open issues and PRs — weighing structural risk, planning trails, and cross-PR collisions.
REPOSITORY MEMORY
Connected once. Remembered after.
On first connection Litmus builds a durable map of the repo — modules, dependency edges, tests, conventions, constraint signals — and refreshes it only when the default branch moves. Every plan check and trust brief runs against that memory, not a cold read. Registered repos are also surfaced first to matched contributors.
github.com/
Public repositories only in this demo. The structural index is stored locally and keyed to the branch revision.
LITMUS BOT · GITHUB
One question, asked where the work happens.
Turn the bot on and Litmus answers volunteers on your issues with a single question drawn from the code that issue touches — the kind only someone who opened the file can answer. It reads the reply, judges it against the repo, and records the result on the contributor's trail. You never type a word.
No repository connected
Connect a repository in the Repositories tab first.
STANDALONE TRIAGE
Any PR, one trust brief.
Paste any open pull request URL. Litmus reads the diff against the repo's memory and any Litmus planning trail, then renders the verdict a maintainer actually needs.
CONTRIBUTION PRE-FLIGHT · ISSUE
Make the right change the first time.
Repository-aware contribution guidance
1Orient
2Plan
3Revise
4Brief