Six signals produce one opinionated grade
GitHub Ranking Audit fetches 6 pieces of public repository data and converts them into scores from 0 to 100. Name match gets 25% of the final grade, stars get 20%, description, topics, and README get 15% each, and recent activity gets 10%. You can audit one repository, pass several at once, add a target query, or ask for JSON output.
That makes the tool easy to understand. It also defines its limit. The README says GitHub does not publish the exact weights behind its Best match order. The percentages here are therefore the author's model, not a reconstruction validated against search results. An A means a repository satisfies these thresholds. It does not mean the repository will appear above a B for a given user, query, or date.
The checklist catches neglected repository metadata
A missing description scores 0, fewer than 5 topics score 40, and a README under 50 words scores 20. Those thresholds can surface obvious presentation gaps before a launch. The CLI also prints direct tips when name matching, topics, README length, activity, or stars fall below its cutoffs. For a maintainer who has never reviewed the repository page as a search result, that five-minute pass can be useful.
Some tips deserve restraint. Activity is calculated only from the last push date: 7 days or less earns 100, while more than 180 days earns 10. The code cannot tell a documentation fix from an empty commit, nor can it judge whether a stable project needs frequent changes. Treat that result as a prompt to explain maintenance status. Do not manufacture activity for a higher grade.
What happened when we ran it
Our measurement setup cloned commit 59281fd into a fresh unprivileged Debian container with 3 CPUs, 8 GB of RAM, Python 3.12, and no secrets. Installation finished in 39 seconds, bringing in 36 packages and using 37 MB on disk. The build completed in 6 seconds. Pip-audit reported 0 known vulnerabilities in the installed environment.
Pytest took 8 seconds and reported 26 passed with 0 failed. The repository contained 18 files, about 426 lines of source, 1 CI workflow, and a tests directory. There was no Dockerfile, which is reasonable for a one-file Python CLI. Our run covered installation, packaging, scoring functions, and CLI tests. It did not validate the grade against GitHub search outcomes.
The distinction matters because a green suite proves the code follows its formula. It cannot prove the formula predicts ranking. The tests check exact thresholds for description length, topic count, README length, stars, and push age. They also check query-name overlap and basic CLI errors. No test compares an audit score with a search result position or later traffic.
README relevance is reduced to word count
The README says the tool checks keyword presence in the first 200 words. In ranking_audit.py, the function creates a lowercase first_200 value but never uses it. The returned score depends only on total length: fewer than 50 words gets 20, 50 to 199 gets 50, 200 to 499 gets 75, and 500 or more gets 100. A long README about the wrong subject can therefore ace this signal.
Name scoring behaves differently. Without a target query, every repository name receives 100. With --query, it treats hyphens and low-line characters as separators, then scores the overlap with query words. This is predictable and transparent, but it ignores description and README query matches when calculating that name score. Use the query mode to spot missing words, then inspect real GitHub results before renaming a repository and breaking links.
GitHub.com and its rate limits define the operating boundary
The script makes 3 API requests per repository: repository metadata, README content, and topics. It reads GITHUB_TOKEN when present and otherwise sends unauthenticated requests. That is enough for a small manual audit, while batches can hit GitHub's lower unauthenticated limit. The CLI has no cache, retry policy, backoff, or option for a GitHub Enterprise Server URL.
JSON mode prints the regular human report before the JSON array, so consumers expecting stdout to contain only valid JSON should test their parser against the actual command. The result object contains the six scores, rounded overall score, grade, and repository name. It leaves out the fetched metadata and tips, limiting what a downstream report can explain without calling GitHub again.
One launch-day release is too little history to judge durability
The repository was created, released as v1.0.0, and last pushed on September 17, 2026. GitHub showed 211 stars and 0 open issues or pull requests on October 5. There is no issue activity to examine, and no later release yet. That is a young project with a clean queue, not evidence of long-term maintenance or abandonment.
Use GitHub Ranking Audit when you want six repository-page checks in a readable terminal report. Its 26 passing tests and 426-line codebase make the rules cheap to verify. The final grade should stay in that narrow role. For an actual discoverability decision, record the target query, inspect GitHub's live results, and compare referral traffic after a meaningful metadata change.