# The Repo-Evidence Skill Standard for Technical Shortlists

*You will grade any candidate's public code evidence against a fixed bar and land on one of three verdicts, so two sourcers reach the same call.*

- Canonical URL: https://www.refolk.ai/guides/repo-evidence-skill-standard
- Pillar: Recruiting and sourcing
- Format: Standard
- Published: 2026-08-18
- Last reviewed: 2026-08-18
- Reading time: 13 min

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.

| Verdict | What it means | What you may write on the shortlist |
|---|---|---|
| Proven | Authored, non-fork evidence in the skill, inside the window, identity confirmed | "Proven in X" with commit URLs |
| Needs interview check | Real signal, but attribution, depth, or authenticity is ambiguous | "Likely X, confirm in screen" |
| Unproven | No qualifying public artifact found | Nothing about this skill from code |

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.

> **Rule:** One skill, one artifact, per person
>
> Grade one named skill against one qualifying artifact per candidate. A shortlist claim is per-person, so identity and authorship come before any company or org-level sourcing, not after.

## 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.

#### How a commit gets attributed

1. **Author writes changes** - author name and email are set and preserved
2. **Committer applies them** - cherry-pick or rebase rewrites committer, author stays
3. **Email tied to account** - only then does GitHub count it as that user's contribution
4. **Signature checked** - a valid GPG, SSH, or S/MIME signature marks it Verified

*Read the author field, because everything downstream can rewrite the committer.*

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.

**2 - identities stored in every git commit**

Author wrote it, committer applied it; only the author field attributes the work.

## 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.

| Field or signal | What it proves | Where you read it |
|---|---|---|
| author vs committer | who wrote the change vs who applied it | git log --format=fuller |
| Co-authored-by trailer | shared authorship credit on one commit | commit message body |
| Verified badge | cryptographic identity of the signer | commit or PR commits tab |

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.

> **Watch out:** A green language bar on a fork proves nothing
>
> Forking a Rust project paints the profile with Rust without a single line written. Check the fork flag and parent field, then confirm the candidate authored commits in that fork before it counts.

## 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.

**4.25x - more US Go/backend profiles than exact-Rust-titled profiles**

From Refolk's index sample; for scarce skills, tighten the per-commit bar without draining the funnel.

| Skill or title band | Profiles | Ratio to Rust |
|---|---|---|
| Rust title + Rust skill | 4 | 1.0x |
| Go/backend title + Go skill | 17 | 4.25x |

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.

| Market | Profiles (exact Rust title + skill) | Sample top employers |
|---|---|---|
| United States | 4 | WalletConnect, Tangle Network, VeroID Security |
| Germany | 5 | Zed Industries, JetBrains, CoW DAO |
| Germany/US ratio | 1.25x | - |

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.

I ran this search: `Engineers who authored merged pull requests in Rust in the last 12 months, not forks, based in Germany.` - [see the full result list](https://www.refolk.ai/s/r4qvdqmyva).

*Returns candidates whose authored, non-fork Rust work is already scoped to a window and geography, so you start grading at the attribution step instead of hunting for the right accounts.*

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.

#### Grade one skill against the bar

1. **Fix the skill and its evidence definition** - Name the single skill and the exact artifact that would prove it, such as authored, merged code in a non-fork repo. Write one line two people would read identically.
2. **Confirm identity linkage** - Match the account to the candidate using a consistent README, pinned repos, name, location, and primary languages that align with the resume. The account must be the person, not a namesake.
3. **Separate original repos from forks** - Use the fork flag and parent and source fields, or the forked-from banner, to drop forks with no authored change. Every evidence repo is a non-fork or a fork carrying the candidate's own commits.
4. **Attribute the commits** - Inspect author vs committer and any Co-authored-by trailers, and prefer Verified commits. The proving commits carry the candidate as author on an email tied to their account.
5. **Check recency and depth** - Apply a dated push filter and read release history and issue activity, not just the graph. Evidence falls inside your active window and shows sustained work.
6. **Grade against the bar** - Assign proven, needs interview check, or unproven. Record one verdict with the specific commit URLs cited.
7. **Second-reviewer calibration** - A different reviewer regrades from the same links. Verdicts match, or the disagreement is logged and the bar tightened.

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.

> A busy contribution graph is not proof of authorship until you have read the author field.

## 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.

| Failure mode | What the false positive looks like | The check that voids it |
|---|---|---|
| Namesake match | A perfect skill match on the right name | Cross-reference README, location, linked sites, and commit email domain |
| Fork mistaken for authorship | A green language bar on a fork | Check fork flag and parent, confirm authored commits exist |
| Star and follower inflation | High stars read as competence | Open the commit list, not the star count |
| Tutorial and clone repos | To-do apps and site clones look like projects | Read repo depth, release history, issue activity |
| Committer-not-author confusion | Candidate shows as committer on others' code | Read the author field specifically, not the committer |
| Unsigned trailer spoofing | A Co-authored-by line naming the candidate | Prefer Verified commits; treat unsigned trailers as claims |
| Agent-generated commits | Bulk output inflates the graph | Check size and cadence anomalies; grade needs-interview-check |
| Absence read as disproof | A quiet profile looks like no skill | Never mark unproven from silence; route to interview |

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."

> **Note:** "GitHub verifies skill" is a myth to retire
>
> No GitHub product certifies that a candidate's skill is demonstrated from their code for hiring. The similarly named Copilot agent skills feature is folders of instructions that configure an assistant, not an adjudication of human competence.

## 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."

#### Before you claim a skill is proven

- [ ] The one skill and its proving artifact are written in a single line two people read identically.
- [ ] The account is linked to the candidate by README, location, and language alignment, not just a matching name.
- [ ] Every evidence repo is a non-fork, or a fork containing the candidate's own authored commits.
- [ ] The proving commits show the candidate in the author field, not only the committer field.
- [ ] The author email on those commits is one tied to the candidate's GitHub account.
- [ ] Unsigned Co-authored-by trailers are treated as claims, and Verified commits are preferred where available.
- [ ] The evidence falls inside the team's declared active window, set with a dated push filter.
- [ ] Repository depth, release history, or issue activity confirms sustained work, not a tutorial or clone.
- [ ] The verdict is one of proven, needs interview check, or unproven, with commit URLs cited.
- [ ] A second reviewer reached the same verdict from the same links, or the disagreement is logged.

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.

## Frequently asked questions

### Does GitHub prove coding skill on its own?

No. GitHub exposes evidence, not a verdict. It has no product that certifies a candidate's skill is demonstrated from their code for hiring; the similarly named Copilot agent skills feature configures assistant behavior and has nothing to do with human competence. Public activity can attribute code to the wrong person, sit on a fork, or be agent-generated, so a human still has to read the author field and grade the evidence against a fixed bar.

### How do I attribute a commit to a specific GitHub user?

Read the author field, not the committer field, because cherry-pick, rebase, patch application, and web edits rewrite the committer while preserving the author. Confirm the author email is one associated with the person's GitHub account, since that is what makes it count as their contribution. Prefer commits marked Verified, which means a GPG, SSH, or S/MIME signature was cryptographically checked. Treat unsigned Co-authored-by trailers as claims, not proof.

### Does a quiet GitHub profile mean the candidate lacks the skill?

No. Private and internal activity surfaces only as anonymized counts that hide repository names, commit messages, and diffs, and showing them at all is a toggle the developer controls. Absence of public evidence never proves absence of skill; it only means the evidence is not public. A rule that penalizes quiet profiles systematically discards senior engineers whose employers forbid public code, so route silence to an interview check rather than marking it unproven.

### How recent does the code evidence need to be?

There is no platform-wide standard window, so set one as team policy and apply it with a dated push filter such as pushed:>2025-01-01. What matters is that you define the active window explicitly and grade every candidate against the same one. Read behavioral signals like cadence and depth inside that window rather than trusting the contribution graph, which can be inflated by applied commits the candidate did not author.

### Can a Verified badge tell me the code is good?

No. Verified proves who signed the commit at commit time, not that the code is competent or complex. It is also 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 the badge to strengthen identity attribution, then judge quality separately from repository depth, release history, and the specific diffs.

---

*From the Refolk guide library. I revise these guides rather than replacing them, so the current version is always at https://www.refolk.ai/guides/repo-evidence-skill-standard*