पद्धति

Every language share, health score, insight and recommendation shown on a profile page is calculated from a single GitHub GraphQL response - nothing is fetched from anywhere else, nothing is estimated from outside data, and nothing is invented when a fact isn’t available. This page documents exactly how each number is produced, so you can judge it rather than take it on faith.

What data this is based on

When you request a profile, the server makes one GraphQL query to GitHub’s public API for: the account’s public, non-fork repositories (up to 100, sorted by stars); each repository’s stars, forks, watchers, open issues, size, license, topics, description, homepage URL, primary language and per-language byte counts; the pinned repositories; the public contribution calendar and yearly totals, split into commits, pull requests, issues and reviews; and public profile fields such as bio, location, company, followers and social accounts. Anything not in that list - README contents, CI/CD configuration, commit messages, private activity, or data about other people - is not used anywhere on the site, because it is not fetched.

Analysis coverage

The repository fetch is capped (currently 100 owned, non-fork repositories). For most accounts that is every public repository they have; for a small number of very prolific accounts it isn’t. Every repository-scoped statistic on a profile page - languages, health scores, recommendations - is computed only over the repositories actually fetched, and the page says so explicitly (“analyzed repositories”) wherever the fetched count is lower than the account’s total public repository count, rather than silently implying it covers everything.

Language analysis

Each repository reports its languages as a byte count per language (how much source code GitHub detected in each). Those byte counts are summed across every analyzed, non-fork repository, and the six largest languages become the language chart; everything smaller is grouped into “Other.” This measures the language mix of code actually written across the account’s repositories - it does not measure framework or library expertise, which GitHub’s API does not report directly. Where the site mentions a framework, database or tool, it is read from repository topic tags the account owner added, and is labelled as a detected topic rather than a verified skill.

Repository ranking and portfolio concentration

The repository showcase ranks repositories with a weighted score built from stars, forks, watchers, topic count, license presence, description presence, whether the repository is pinned, and recency of the last update. Portfolio concentration separately looks only at stars: it compares how much of the account’s total stars sit in its single most-starred repository versus its top three and top five, and labels the result concentrated, balanced or distributed based on that share.

Repository maturity and health

Every analyzed repository is scored on three independent dimensions, so that a popular repository is never assumed to also be well-maintained or easy to discover:

• Popularity - stars, forks and watchers, weighted and normalized against the strongest repository in that account’s own analyzed set (not a fixed, cross-account scale).
• Discoverability - how many of four signals are present: a description, at least one topic tag, a detected license, and a homepage/demo URL.
• Maintenance - how recently the repository was last pushed to, on a sliding scale (full credit within 30 days, tapering to zero past two years; archived repositories always score zero here).

Those three scores combine with the repository’s age and last-push date into a maturity label - experimental, developing, maintained, established, dormant or archived - shown with the evidence behind it. A label like “licensed” describes what is present in the data; it is never read as a guarantee of code quality.

Documentation and CI signals

For a profile’s top-ranked repositories - the same ones shown under Repository Health, up to twelve - a second, separate GitHub request checks for three specific files on the default branch: a README.md, a CONTRIBUTING.md, and any files directly under .github/workflows (GitHub Actions). Only file presence and size are read; file contents are never fetched or stored. This detection is filename-exact and default-branch-only, so it under-counts repositories that use a different filename, casing, or extension for their README or contributing guide - a badge saying “No README” means no exact README.md was found at that path, not that the project has no documentation anywhere. Because this is a second, separate request, it can fail independently of the main profile data; when it does, or for repositories outside the enriched top twelve, no badge is shown at all rather than a guessed one - showing nothing is preferred over a wrong claim.

Profile health

Profile health is five separate, explainable scores rather than one black-box number:

• Activity - trailing-year contribution volume plus current and longest streak length.
• Portfolio - the share of analyzed repositories rated established or maintained, plus whether the account has stars and pinned repositories.
• Discoverability - the average discoverability score across analyzed repositories, and how many are missing a description, topics or a license.
• Maintenance - the share of analyzed repositories pushed to within the last six months.
• Collaboration - the share of trailing-year activity that is pull requests and code reviews rather than commits, plus repositories starred.

Every score on a profile page is shown with the evidence bullets that produced it, so a low score is always accompanied by a reason rather than presented as a verdict.

What to improve

Recommendations are generated only when the data supports a concrete, specific gap: a pinned repository with no description, topics or license; a pinned repository that is dormant or archived; an unpinned repository that scores clearly stronger than a currently pinned one; or a cluster of stale, zero-signal repositories worth archiving. The list is capped at seven, sorted by impact, and is empty when a profile is already clean - it is never padded with generic advice to hit a target length.

Recruiter snapshot

The recruiter snapshot is a direct readout of numbers computed elsewhere on this page - technical focus from the language analysis, project depth from repository maturity, collaboration from the trailing-year contribution split, community signals from summed stars and forks, and recent activity from the contribution calendar (distinct calendar months with at least one tracked contribution, out of the last twelve). It reports evidence, not a hiring judgement: resumefromgit.com never infers seniority, employment, education, or any personal characteristic from public GitHub activity.

Resume generation

The résumé builder pre-fills suggested bullet points from the same repository and contribution data described above - project names, languages, stars, and activity dates - which you can edit, remove or replace entirely before exporting. Nothing is added to the exported résumé that wasn’t either in that data or typed in by you, and the fields you fill in are stored in your browser rather than on our servers.

When a profile isn’t indexed

A GitHub account with no public repositories and no tracked contribution activity has nothing for this analysis to work with, so its profile page renders a short empty state instead of the full dashboard. Those pages are marked noindex, follow: the page still resolves normally for a direct visit or an incoming link, but it is not offered to search engines as a content page, since there is no analysis on it yet.

Limits worth knowing

GitHub’s public contribution calendar excludes private repositories (unless the owner opts in), commits on non-default branches, work in unmerged forks, and commits authored with an email not registered to the account - see the dedicated write-up. Where a metric can’t be calculated from available data, the site says so rather than guessing.

Questions about a specific number on your profile? The contact page reaches the person who built this directly.