The Repo-Evidence Skill Standard for Technical Shortlists

This standard fixes the bar for a single decision: does a candidate's public repository activity actually prove the one skill the role requires, before you put them on a shortlist and claim it? It is for in-house recruiters, sourcers, and hiring managers who write notes like "proven in Rust" next to a name. Adopt it as team policy so that note means the same thing from every sourcer, and so borrowed, applied, or agent-generated commits never get miscredited as the candidate's own work.

The existing library covers which signals to read, how to triage a profile, and how to source from a contributor graph. None of them set the pass/fail line for asserting a specific skill is proven by the code itself. That line is what this document is.

What "proven by the code" has to mean

A skill is proven by public code only when a specific artifact shows the candidate as the author of work in that skill, in a repository that is not a bare fork, within your active window, and the identity linking that account to the candidate holds. Everything short of that is a lower verdict, not a softer version of the same one.

The standard produces exactly three verdicts. Keeping it to three is what makes two sourcers agree.

Note the asymmetry. "Unproven" means the public evidence does not clear the bar, not that the candidate lacks the skill. Those are different claims and the difference matters, because private and internal activity surfaces only as anonymized counts that hide repository names, commit messages, and diffs. A silent profile is not a disproof.

Why the contribution graph is not the evidence

The green contribution graph shows activity, not authorship, and the two come apart routinely. Every git commit stores two identities: the author, who wrote the changes, and the committer, who uploaded them to the repository. Cherry-pick, rebase, patch application, and web edits keep the author but rewrite the committer to whoever applied the change.

So a busy graph can belong to someone who authored none of the code it counts. This is the single most common way a repo read goes wrong, because the graph is the first thing a recruiter sees and the last thing that proves anything.

Two facts about the Verified badge keep reviewers honest. First, it proves identity, not quality: it confirms who signed the commit, never that the code is any good. Second, verification is persistent. If a signing key is later revoked or expired, previously verified commits keep their verified status and GitHub will not re-verify them. Use Verified to strengthen attribution, then judge quality separately from repository depth and the diffs themselves.

The attribution fields and what each one proves

Attribution is a small set of fields, and each one answers a narrow question. Read them in order and record which one carried the verdict.

Two of these lie in predictable ways. A Co-authored-by trailer can name anyone, because it is just a line of text in the commit message; without a verifiable signature it is a claim, not proof. And for any credit to attach to a real account at all, the email used must be one associated with that person's account on GitHub. An unrecognized email is an unlinked commit no matter whose name it carries.

The fork boundary is the other structural check. The REST repository object extends a fork response with a parent field, the repo it was forked from, and a source field, the ultimate root, alongside a boolean fork flag. A fork with the right language bar but no authored commits from the candidate is not evidence. Confirm authored commits exist inside the fork before you count it.

The scarcer the skill, the stricter you can be

For a scarce skill, a single strong authored repo should move the verdict further than it would for a common one, because raising the per-commit bar does not empty a funnel that was already small. Supply tells you how strict you can afford to be.

In Refolk's index sample, US profiles with an exact Rust engineer or developer title plus a Rust skill number just four. The same exact filter returns seventeen Go or backend-titled profiles with a Go skill. That is a 4.25x gap, and it changes the standard's economics.

Counts are from Refolk's index; the ratio is derived and the sample is small, so treat it as directional. The point stands regardless of the exact numbers: when a skill is rare, you can and should demand cleaner authored evidence, because you are not choosing between many candidates.

Geography moves where the proof clusters. In Refolk's index sample, Germany returns five exact-Rust profiles concentrated in a few employers, including Zed Industries, JetBrains, and CoW DAO, while the US set is smaller and more scattered.

Where supply concentrates in a handful of orgs, org-first sourcing finds the people faster. Where it scatters, profile-first works better. Either way, the per-person attribution bar in this standard does not change; only the path to the profile does.

Getting to a clean, non-fork, authored, in-window list by hand means filtering the contributor graph, opening repos to check the fork flag, and reading commit authors one by one. Refolk takes the query in plain English and returns people who already match those constraints, which removes the sourcing friction and leaves you the judgment the standard actually cares about.

The grading procedure

Run these seven steps in order for every candidate whose skill you intend to claim. The whole pass is roughly forty minutes and ends with one verdict and a citation.

On recency, no primary source sets a fixed platform window, so set one as team policy and apply it consistently with a dated push filter such as pushed:>2025-01-01. The strongest signals are behavioral: how often someone contributes, to what repos, how they communicate, and whether activity is recent and consistent. Depth and cadence inside your window beat any single snapshot of the graph.

How this goes wrong: failure modes that void a claim

Most bad shortlist claims trace to one of eight failure modes, each with a false positive that looks convincing until you check the specific field. Treat this section as the heart of the standard: knowing the ways evidence lies is what makes the bar hold.

A few of these deserve more than a row.

Stars and followers carry nothing. They add context but are supporting signals only and should never carry an evaluation on their own. A repo can collect stars for a README, a demo, or a trend and contain no authored work by the person you are grading.

Tutorial repos read as portfolios. Repositories that feature basic projects like to-do apps or simple website clones are often beginner exercises and do not showcase advanced problem-solving. Language presence is not depth. Depth shows up in release history and issue activity, not in the language bar.

Agent-generated commits are the newest trap. Bulk AI-generated commits can inflate output and paint a convincing graph. There is no clean public field that flags them, so look for size and cadence anomalies and never grade them "proven" from the code alone. Route them to "needs interview check," where the question is whether the candidate can explain the code they are credited with.

Absence is structurally uninformative. Private and internal activity surfaces only as anonymized counts, and showing even that much is a toggle the developer controls. A rule that penalizes quiet profiles systematically discards senior engineers whose employers forbid public code. Silence routes to an interview, never to "unproven."

The definition-of-done checklist

Before you write a skill claim on a shortlist, every item below must be true. If one fails, the verdict is "needs interview check" or "unproven," never "proven."

The second-reviewer step is not ceremony. It is the mechanism that keeps the standard calibrated. When two sourcers disagree from the same links, the disagreement tells you exactly where the bar is ambiguous, and tightening the written definition at that point is how the standard stays sharp over time.

Keeping the standard current

Re-check the mechanical parts of this standard on a cadence, because the platform underneath it moves even when the principles do not. The fields you read change less often than the tools around them, so anchor your checks to the mechanisms rather than to any current value.

Three things are worth a periodic look. First, the fork response schema: confirm the parent and source objects still carry the network relationship you rely on, since the REST API is versioned by a dated header. Second, signature verification requirements: SSH signature verification needs Git 2.34 or later and S/MIME needs Git 2.19 or later, so a reviewer on an older client may see fewer Verified badges than exist. Third, your own active window: the dated push filter is a policy number, and it should march forward on a schedule your team agrees, not drift silently.

The one thing that will not change is the reason this standard exists. A skill note on a shortlist is a claim you are asking a hiring manager to trust. Read the author field, hold the fork line, treat silence and stars and unsigned trailers as the non-evidence they are, and two sourcers grading the same profile will write the same word next to the same name.