How the ratings work

What RepoScout reads, what it asks, how a yes or a no is reached, and where it can be wrong.

The short version

RepoScout does not write an opinion about a repository. It asks a judgment model a fixed set of narrow yes-or-no questions about the repository and about you, gets a probability back for each, and then decides every action in plain code from those probabilities and a few facts GitHub states outright. You can open the Why panel on any verdict and see every number it rested on.

Three ideas carry the whole design. Each question asks one thing. Each answer is read in three bands, never as a coin flip. And the profile you wrote is sent as things you said about yourself, never as a conclusion about you.

What it reads

Everything comes from GitHub’s public API, straight from your browser. Nothing is read from a private repository: the page says whether the repository is public, and RepoScout checks that before reading anything.

• The repository’s description, topics, primary language, licence, star, fork and open-issue counts, creation date, last push, and whether it is archived, a fork or a template
• The README, up to 6,000 characters: the opening, plus any lines about installing, sponsoring, licensing, contributing or AI-assisted contributions from further down
• CONTRIBUTING.md (up to 3,000 characters), the pull-request template (1,500) and the FUNDING file (600), when they exist. A file that does not exist is recorded as absent; a file that could not be read this time is recorded as unavailable. The two are never confused
• The newest 25 open issues: number, title, labels, comment count, age, and the first 300 characters of the body. Plus any issues labelled good first issue or help wanted
• The last 10 closed pull requests, reduced to how many merged and how long they took
• The top 5 contributors, reduced to the share of commits the top one holds

Repository data is cached on your machine for 6 hours and answers for 7 days, so reopening a repository costs nothing. Editing your profile or criteria clears the answers for every open tab.

Who is asking

Your profile is three things: topics you care about, technologies you can work in, and what you would use a repository for. They go with every request, worded as stated interests, stated skills and stated use. The model is told they are things you typed and that they carry no claim about whether the repository suits you. That wording matters: a field named as a conclusion would answer the question before it was asked.

Without at least one topic or technology, RepoScout stays quiet. There is nothing to compare a repository against.

The engine, and what a percentage means

The engine is Jev, TypeSafe’s System One model, called with your own API key. It returns typed answers with probabilities rather than prose. RepoScout asks eleven yes-or-no questions, one multiple-choice question, and one yes-or-no question per open issue, all in a single request per repository.

Every yes-or-no answer is read in three bands. Above a threshold it is a yes. Below a lower threshold it is a no. Between the two it is unsettled: the repository does not say, and RepoScout shows that as its own outcome rather than rounding it either way. No threshold sits at 50 percent, because a probability near one half means the model does not know, not that the answer is medium.

The percentage beside an action is the probability of the side named. “88% yes” means the model put 88 percent on yes. “96% no” means it put 96 percent on no. An unsettled row shows the raw number with no side.

The thresholds shipped today are starting points, not measurements. Until they have been tuned on a set of real repositories, every verdict carries the line “thresholds not measured”. That line is honest and it will go away when the tuning is done.

The eleven questions

Each asks exactly one thing, and each is told what “there is nothing of this kind here” looks like, so a repository that says nothing gets a quiet no rather than a nervous maybe. In plain words:

• Does the subject of the repository overlap the topics you listed?
• Do the technologies you listed cover the stack the repository is built with?
• Does the README give steps to build or run it locally?
• Does the README present it as a package other software pulls in as a dependency?
• Does the README present it as a starter, template or boilerplate?
• Is it reference reading: a guide, tutorial, list or set of notes?
• Does the README present a finished, usable project rather than an experiment?
• Does the repository ask for sponsorship or donations?
• Does the README say the project is deprecated, archived or unmaintained?
• Does the README warn against relying on it: alpha, experimental, not for production?
• Do CONTRIBUTING.md and the pull-request template describe concrete steps a newcomer would follow?

No question asks two things at once. When an action needs two conditions, RepoScout asks two questions and combines them itself. A combined question is meaningless when half of it is absent, and a meaningless question lands near 50 percent, which a careless threshold would read as a finding.

How each action is decided

Every action is one or more of the questions above plus facts GitHub states outright, combined in code. For an action that needs everything to hold: any part that is a no makes the action a no; a part the repository does not settle leaves the action unsettled; a part that could not be read this time cannot push the action either way.

Reporting an issue is not rated. RepoScout cannot know whether you hit a bug, so it offers a shortcut to the new-issue page and nothing more.

What the repository is

One multiple-choice question asks what the repository is: a library or package, an application or tool, a mobile app, a web app or service, a framework, a plugin or extension, a starter or template, reading material, data or a model, or unclear. The threshold for a multiple-choice answer is derived from the number of options, because ten options spread the probability thin and a top pick at 40 percent over ten is a strong answer, not a weak one.

Two kinds of “unclear” are shown differently. When the model spreads its probability across several real options, the line reads “could not tell what it is”. When it confidently picks unclear, the line reads “does not say what it is”. Those are opposite situations and they are never collapsed into one word.

What a plugin is for, or which language a framework serves, is not asked. It sits beside the answer, from the language and topics GitHub already states.

Potential to contribute

This one has three layers, and the first costs nothing.

• Hard filters, checked in code before anything is sent: last pushed within the months you set, a minimum star count, must have open good-first-issue or help-wanted issues, must have a CONTRIBUTING.md. A repository that fails one is marked “filtered out” with the reason, and none of the contribution questions are asked.
• Your own conditions, one line each, such as “allows AI-assisted contributions” or “welcoming to first-time contributors”. Each becomes its own yes-or-no question, tested against the CONTRIBUTING file, the pull-request template and the README. Your wording lives in the question, never in the data about the repository.
• Then the action holds when: your skills cover the stack, the contribution process is written down, good-first-issue or help-wanted issues are open, CONTRIBUTING.md exists, and every condition you wrote holds.

The wording is deliberate. “Potential to contribute” means you have the skills and the repository is set up for newcomers. It never means you should contribute now: RepoScout knows nothing about your time.

Issues you could take

When potential to contribute is being judged, the newest 25 open issues go into the request as a list, and one yes-or-no question per issue asks whether someone with the technologies you listed could do the work that issue describes, going only by the technologies and the kind of change in its title, labels and opening lines. Documentation, examples, tests in a language you listed and reproducible bugs in your stack count as within reach; a question, a discussion or a tracking issue with nothing to do does not.

Issues that come back yes or unsettled are listed with links, confident ones first, then by probability, then the ones with the fewest comments first, since an issue nobody has commented on is the one nobody has claimed. Issues that come back no are dropped.

The first 25 go with the verdict. A “Judge 25 more” button fetches the next page and judges it, on your own GitHub quota and your own key, and keeps offering until a page comes back short. There is no cap. Every page is cached, so a reload and a second click cost nothing.

What this does not judge: how hard or how large an issue is, whether someone is already assigned, whether the maintainers want outside pull requests, or anything past the first 300 characters of the body. The comment count is only a proxy for “claimed”.

The licence note

The licence note is not a judgment call. It is a lookup from the SPDX identifier GitHub reports to a category, and a rule that compares the category with the use you stated. A strong or network copyleft licence against a proprietary use, a non-commercial licence against any commercial use, a source-available licence, or no licence at all against any use that relies on the code, each produces a note in “may” wording.

It only ever warns. It never says a repository cannot be used, because that is legal advice and this is a browser extension. When it fires, “use as a dependency” is capped at unsettled rather than turned into a no.

Where it can be wrong

• The thresholds are untuned. Until the calibration run is done, every verdict says so.
• The README is cut at 6,000 characters. The opening is kept, plus lines about installing, sponsoring, licensing and contributing from further down. A subject can be in the file and missing from what the model saw, and the model is told that, so it does not read a cut as the file ending.
• Issue bodies are cut at 300 characters, and issues are judged on skills alone.
• A rate-limited GitHub call leaves a field unavailable. An unavailable field is never read as absent: it cannot make an action a no, and it leaves the action unsettled. The Why panel lists what could not be read.
• The model can misread. The Why panel shows every probability so you can see which question a surprising verdict rested on, and fix the question that matters most: your own profile.

What it never does

• It never stars, watches, forks, sponsors, comments or posts on your behalf. Every action is yours to take.
• It never reads a private repository, and never reads what you type on GitHub.
• It never sends anything to a server of ours. Requests go from your browser to GitHub’s public API, to TypeSafe with your key, and, only when you export, to Notion with your token.
• It never meters judgments. You are paying for your own inference, so there is no limit on how many repositories it will judge.

Last updated 2026-09-22.