GitHub Profile Score
0/100Measures public portfolio presentation and discoverability - not engineering skill.
Enter a GitHub username to get a transparent 0–100 score and actionable recommendations for improving how the public profile and repositories present themselves.
Profile auditRepository explorerMarkdown export
Audit repositories you authorize, including private repositories.
Signed in as
Building portfolio audit
Fetching repositories, checking presentation signals, and preparing recommendations.
Signed in as
GitHub Profile Score
0/100Measures public portfolio presentation and discoverability - not engineering skill.
Prioritized from your data
Scores use deterministic checks for names, descriptions, root READMEs, topics, licenses, demo links, update recency, and portfolio focus. Unknown README data receives a neutral score and is labeled as unverified.
The Pinned optimizer tab answers a third question, separately again: which combination of repositories forms the strongest set to feature. It reads the finished audit and changes no score.
Each repository also receives a portfolio candidacy label, which is judged separately from the score. The score measures how well a repository presents itself; candidacy measures whether it is a good repository to feature prominently. A polished fork can score well without being a strong candidate, because GitHub's fork flag cannot show how much of the work belongs to the profile owner, and an archived project can be presented well while still being a weaker choice to lead with. Evidence that could not be verified is treated as unknown rather than missing.
Lowest scores first
Fetched GitHub data
Select repositories here to use the “selected only” Markdown option.
Attributable public work
Public repositories outside this profile with attributable merged contributions. These projects are not included in the portfolio score.
Public follower network
The public followers and following lists for this profile, retrieved when this tab is first opened. GitProfileLens never follows or unfollows anyone.
Accounts appear in the order the GitHub API returned them. GitHub does not record when a follow happened and does not document an order for these lists, so this is not a newest-to-oldest follow history.
Preview and export
GitProfileLens never unfollows anyone automatically. There is no bulk action here: every unfollow is one account you choose, one at a time.
These are accounts you follow that were not in the followers list GitHub returned. That is all it means. GitProfileLens cannot know why an account does not follow back.
Which repositories to feature
GitHub profiles pin up to six repositories. GitProfileLens recommends a set from portfolio candidacy and observable repository metadata, and recommends fewer than six when fewer repositories meet the criteria. It cannot know your goals, so every suggestion is advisory.
These authorized private repositories read as strong portfolio work. A public GitHub profile cannot pin them, so they are listed apart from the recommended set. GitProfileLens does not suggest publishing them.
The recommendation is a set decision, not another repository score. No repository score, category score, or candidacy label changes when it runs.
Repositories are first filtered for eligibility: a repository classified De-emphasize is not recommended, nor is one with an open high-priority presentation finding, nor one with no verified description or README content a visitor could read. Private repositories are recognized separately, because a public profile cannot feature them.
The remaining repositories are chosen one at a time using a fixed order of rules: portfolio candidacy first, so that between repositories presenting comparably well a Strong candidate is considered before a Worth polishing one; then confirmed original work ahead of unreported fork status, which is ahead of a GitHub-identified fork; then active work ahead of archived work; then, again between repositories that present comparably well, how much a repository repeats the primary language and topics of the repositories already chosen; then presentation score, maintenance evidence, verified metadata, and finally repository name, so the result never depends on the order GitHub returned repositories in.
Breadth is credit for verified distinctness. A repository with no reported language, or no topics, earns no breadth claim and takes no penalty for it. GitProfileLens has no reliable project or domain categories, so it does not invent any: the only set-level signals it uses are primary language and topic overlap.
Candidacy and breadth both decide between repositories only when their presentation scores are within five points of each other. Most of what makes a repository a Strong candidate — its README, description, topics, maintenance and open findings — is already counted in its presentation score, so letting the label outrank the score by any margin would count the same evidence twice. Fork status and archive status are not counted in the score, and those keep deciding on their own.
Breadth decides between repositories only when their presentation scores are within five points of each other. Further apart than that, the stronger presentation evidence decides and breadth does not apply. Representing a language no other repository represents is a fact about the set, not a measure of how good a project is, and GitProfileLens cannot observe implementation complexity, engineering effort, or production use — so breadth settles close calls rather than overriding the evidence it can actually read.
Your current pins are used only for the comparison on this tab. They are never evidence that a repository deserves to be recommended.
Preview and export
Private repository metadata is included only in this local, user-initiated export. Do not publish it unless you intend to disclose those repository details.