← all playbooks
Sourcing

Source engineers on proof of work instead of job titles

A shortlist of engineers where the skill claim is backed by code you can look at, merged with a broad market pull so you are not limited to the ones who happen to be active in open source.

use when
you are filling a developer role and the profiles all claim the same stack

The prompt

Paste it into Claude Code or the Claude desktop app with Hyreflow connected. The first line loads the recruiting skill, so your agent reads the play, asks before it spends anything, and hands the work back to you.

paste this into Claude
/hyreflow-recruit

I am sourcing <ROLE_TITLE> in <LOCATION>. The stack that actually matters is
<LANGUAGES_AND_FRAMEWORKS>.

<PASTE THE SPEC>

Run this on two legs and merge them:

Leg one, GitHub. Find engineers in that location writing in that stack.
Build me a picture of each one: what they actually work on, how significant
their projects are, and whether the skill claim holds up in their code. This
leg is free, so go wide on it.

Leg two, the people databases. Search the same role and location so I am not
limited to engineers who happen to be active in open source, which is most of
them. Filter on skills rather than titles, engineering titles are useless.

Merge on LinkedIn profile, keep whichever row has the better evidence, and
tell me which leg each person came from. Qualify against the spec, then find
personal contact details for the top <N>.

Reach out through LinkedIn first. Only use an email if it is genuinely a
personal one.

Replace every <PLACEHOLDER> with your own detail. Everything else can stay as written.

What you need first

  • The role spec, or at least the languages and frameworks that actually matter
  • A location, with a radius or a remote policy
  • A Hyreflow workspace with credits for the market-search half

Tools it can reach for

The agent picks per step from what your workspace has. Nothing here is required by name.

What happens when you run it

Free steps are marked free. Anything that spends credits is marked, and the agent asks before the first paid run of any size.

  1. 1

    Read the spec for the stack that matters

    free

    The agent pulls out the languages, frameworks and tools that would actually disqualify someone, and separates them from the wish list that fills the rest of a developer spec.

  2. 2

    Search GitHub for engineers in the stack

    free

    A free search across public developer profiles by language and location, then a fuller picture of each one: what they build, how substantial the projects are, and whether they are a maintainer or a passer-by.

  3. 3

    Verify the skill in the code

    free

    Rather than trusting a profile, the agent looks for the fingerprints of the actual tools in public code. Finding them is strong evidence. Not finding them means little, since only public code on default branches is searchable, and it is treated that way.

  4. 4

    Search the market in parallel

    credits

    Most good engineers have no public code at all. A people-database pass over the same role and location runs alongside, filtered on skills rather than job titles, which are close to meaningless in engineering.

  5. 5

    Merge and check the balance

    free

    The two legs de-duplicate on LinkedIn profile with the evidence-carrying row winning. If the merged list leans too heavily on the open-source leg, that is flagged, because it means the market half was under-run.

  6. 6

    Read the personal sites of finalists

    credits

    Optional, and only for the last few. Personal sites, talks and writing add context that neither a profile nor a repository carries.

  7. 7

    Qualify, then get contact details

    credits

    Scored against the spec for free, then personal email for the survivors. LinkedIn is the first approach either way.

The problem with sourcing engineers on paper

Every backend profile in your search claims the same five technologies. The list is aspirational for some of them, historical for others, and accurate for a few. There is no way to tell from the profile, which is why technical screening exists and why so much recruiter time is spent on candidates who were never going to pass it.

Public code changes that for the engineers who have any. You can see what someone actually builds, how substantial it is, whether they maintain things or drive by, and whether the tools on their profile appear anywhere in their work. That evidence is free to gather.

The catch is coverage. Most engineers, including many of the best, have nothing public. So this play runs the evidence leg and a broad market leg side by side and merges them, which gives you proof where proof exists and reach everywhere else.

What you get back

A merged shortlist where each row says which leg it came from. GitHub-sourced rows carry the evidence: what they build, how significant it is, and where the stack shows up in real code. Market-sourced rows carry the career history instead. Both are scored against the same spec, so the ranking is comparable across legs.

Variations worth knowing

Lead with the market leg for infrastructure roles. Ask for it explicitly. There is no point spending the session hunting for open-source evidence that structurally does not exist for that discipline.

Ask for the impact tier. Someone maintaining a widely used project is a different conversation from someone with a tidy set of personal repositories. Both can be excellent hires. They need different approaches, and knowing which you are looking at before you write the message matters.

Add the personal-site pass for the final few. Conference talks, blog posts and side projects are where you find the hook for an approach that does not read like every other recruiter message that week.

Where this goes wrong

Treating an empty code search as a rejection. Only public code on default branches is searchable. A missing fingerprint means the search could not see it, not that the person cannot do the work.

Letting the open-source leg dominate. If most of your merged list came from GitHub, the market half was under-run and you are looking at a biased sample of the talent pool. The play flags that rather than letting it pass silently.

Approaching people through their commits. Lead with LinkedIn. A recruiter email to an address someone published for bug reports lands badly, and it is the fastest way to acquire a reputation in a community that talks to itself.

Questions

Why not just source from GitHub? The evidence is better.

Because most engineers are not there in any usable way. Public open-source activity skews heavily towards particular ecosystems, particular career stages and particular kinds of company, and it barely exists for infrastructure, platform and internal-tooling work. A GitHub-only pool is a recall failure with excellent evidence attached to it. The two legs exist because each one covers the other's blind spot.

What does verifying a skill in code actually mean?

The agent looks for the traces a real user of a tool leaves behind: the configuration block, the import, the idiom. Finding those in someone's public code is far stronger evidence than a skills list on a profile. The reverse does not hold. Plenty of excellent engineers have no public code, so an absence proves nothing and the play never treats it as a negative.

Can I use an email I found through a public code commit?

Carefully, and rarely. An address that appears in a commit was published for a technical purpose, not so a recruiter could approach the person. The play discards employer-domain and no-reply addresses outright and leads with LinkedIn regardless. Where you sit under GDPR, treat a commit-harvested address as the last resort it is.

Why filter on skills instead of job titles?

Because in engineering the titles carry no information. The same person is a Senior Engineer at one company, a Member of Technical Staff at another and a Staff Engineer at a third, and a Software Engineer II somewhere else outranks all of them. Skills filters are the precision lever for technical roles; titles are the noise.

Does this work for infrastructure and platform roles?

Partly. Sysadmin, platform and internal-infrastructure people are usually invisible on GitHub because the work is not open sourceable. For those roles the play skips the open-source leg entirely and runs the market search properly instead, rather than pretending to have evidence it does not have.