End-to-end pipeline: find engineering candidates, verify LinkedIn URLs via Crustdata, find emails (Crustdata + GitHub commits), write personalized outreach, create Gmail drafts. Use when someone wants to go from "I need candidates for role X" to ready-to-send drafts. Trigger on: "source and email ca

Candidate Sourcing Pipeline An end to end skill that takes a hiring role and produces ready to send Gmail drafts for strong candidates — handling discovery, LinkedIn verification, email enrichment, personalized copy, and draft creation in one continuous workflow. The pipeline has five phases. Each phase feeds into the next, and the skill is designed to run them in sequence with minimal human intervention. The user reviews the final Gmail drafts and clicks send. Phase 1: Define the search and find candidates Clarify the role and company Before searching, extract or confirm these details from the user. Do not assume any of these — always ask if not provided: About the hiring company (needed for outreach in Phase 4): Company name What the company does (1 2 sentences) Stage/traction (e.g., "Series A, $10M raised" or "500 person public company") Location / remote policy The sender's name and title (for the email signature) About the role and ideal candidate: The role title (e.g., "Founding ML Engineer") 2 3 core technical problems the role involves Target companies, research labs, or communities to search Any school/alumni connections to prioritize (e.g., "IIIT Hyderabad alumni") Location preferences or constraints How many candidates the user wants in this batch About the ideal candidate profile: Seniority level (e.g., "3 7 years", "senior", "staff+") Must have technical skills or domain expertise Nice to have signals (open source contributions, publications, specific frameworks) Any deal breakers or filters (e.g., "no FAANG lifers", "must have startup experience") Use the company and role details to research what makes this company compelling to candidates — check their website, recent funding, product launches, or press mentions via the Crustdata MCP's web search live tool. This research informs the company blurb in Phase 4. Search by technical output, not job title Three signals matter more than years of experience or company prestige: Proof of work — papers they authored, tools/repos they built with real usage, blog posts with technical depth, open source contributions, demos or benchmarks they released. Hunger — technical opinions posted publicly, Medium/Substack articles, conference talks, being cited by others, active GitHub beyond just commits. Relevance — their specific work maps to the actual problems in the role, not just adjacent domains. Search sources and patterns Crustdata person search (via the Code Mode execute tool) for structured search: Research papers — search arXiv, Google Scholar, Semantic Scholar for the core technical problem. Look at first/second authors, especially those not at top 5 labs. GitHub — search repos by topic/keyword, look at meaningful contributors (not just maintainers). Crustdata web search ( web search live ) — "[technical problem]" site:arxiv.org , "[name]" "[company]" github , "[community]" alumni engineer ML . Output from Phase 1 A list of candidates, each with: full name, current role, current company, any school/community connection, and one specific piece of work that makes them relevant (paper, repo, tool, post). This "proof of work" note is critical — it becomes the basis for the outreach email opener in Phase 4. Phase 2: Verify LinkedIn URLs Never guess or construct LinkedIn URLs. This is the single most common source of errors in outreach. Guessed URLs like firstname lastname or firstname lastname school frequently 404 or point to the wrong person. Real LinkedIn slugs are auto generated and look like david park 086833264 or hongjunchoi92 — they are not predictable from a person's name. Waterfall approach Use this exact priority order. Stop as soon as you get a confident match. Step 1: person search (always try this first) Extract social handles.professional network identifier.profile url — this is the verified canonical LinkedIn URL. Tips: Company names have variations ("Google DeepMind" vs "DeepMind" vs "Google") — try shorter names first, then variations If 0 results, try past employers ( experience.employment details.past.company name ) or just the person's name with a broader filter If multiple results, match by headline, location, or education Run these as a single execute script that fans out independent lookups with parallelMap (batch the candidate list, then map) for efficiency Step 2: web search live (fallback when Step 1 returns 0) Verify the result matches by checking the snippet for employer/role alignment. Don't just grab the first LinkedIn URL. Step 3: Mark as unverified (if both fail) Keep whatever URL exists but add a note: "LinkedIn URL unverified." Never fabricate a URL. Slug comparison When verifying an existing URL: extract the slug (part after linkedin.com/in/ ), strip trailing slashes, compare case insensitively. Different slugs = wrong URL, use the verified URL from social handles.professional network identifier.profile url instead. Real mistakes this prevents These are actual errors from production outreach campaigns: Guessed slug Actual slug What happened david park princeton david park 086833264 404 — made up slug vincent chen mit vincent chen 662a031b5 404 — school suffix doesn't work benoit rostykus benoitrostykus Wrong person — different profile hongjun choi hongjunchoi92 Wrong person — different profile abhay gupta cmu gupta abhay Wrong person — completely different slug format benedict arockiaraj benedictflorance Wrong person — person uses a different name on LinkedIn initeshmethani nitesh methani 7554b3121 Wrong person — typo in guessed slug URL format Always use https://www.linkedin.com/in/{slug} — never bare linkedin.com/in/ without the protocol. Characters like ü need URL encoding ( %C3%BC ). Phase 3: Find email addresses Every candidate needs an email address for the Gmail draft. Use this priority chain. 3A: Business email via Crustdata enrichment Use person enrich (via the Code Mode execute tool). It takes an array of LinkedIn URLs in professional network profile urls (≤25 per call — chunk(urls, 25) then parallelMap ), and field GROUPS (not leaf names) in fields . The contact group returns emails and phone numbers: The contact field group is critical — the default ( basic profile only) response does NOT include emails. Map each result back to its input URL via matched on . Expected hit rates: ~70 80% for professionals at known companies, ~40 50% for independent operators, ~20 30% for people between roles. 3B: Personal email via Crustdata contact enrichment For contact only needs, prefer person contact enrich over person enrich on cost. person enrich can return personal email (+2) and phone (+2) via its contact group, but it also bills a base profile charge (base 1 + contact tiers, cap 7). person contact enrich is the contact only tool — it skips the base profile charge (cap 5), so it's cheaper when you only want contact data. Try this before falling back to GitHub. person contact enrich takes the same professional network profile urls array (≤25 per call) and returns a contact object with business emails , personal emails , and phone numbers . Pick tiers via dotted fields : The response person data.contact object has a personal emails array of objects ( { email, status } — read .email , like business emails ; Gmail, ProtonMail, etc.) and a phone numbers array of bare strings. Credit cost: person contact enrich has no base charge and is priced per contact tier — roughly +1 business email, +2 personal email, +2 phone number, capped at 5 per profile. These per tier numbers are a marginal/ceiling estimate, not a guaranteed cap: requesting a single dotted tier does NOT reliably limit the bill to that tier's increment — a fields: ["contact.personal emails"] call has been observed billing the full 5 credit cap and returning all three tiers. It's still cheaper than person enrich for contact data because it skips the base profile charge, but don't assume one dotted field bounds the cost below the cap. Batch limit: Up to 25 LinkedIn URLs per call. Recommended approach: person contact enrich returns business, personal, and phone in one call — request the tiers you need together to save round trips. person enrich (Phase 3A) can also return all three contact tiers via its contact group, but it adds a base profile charge, so prefer person contact enrich when you only need contact data. If personal email is found, prefer it over business email for cold outreach (higher response rate, less likely to be filtered by corporate spam). If this returns no personal email for a candidate, fall through to GitHub commit extraction below. 3C: Personal email via GitHub commit history (fallback if 3B returns nothing) This is the most powerful technique for technical candidates. Git records the author's email in every commit, and this metadata is accessible even when profile email privacy is enabled. Step 1: Find GitHub username Native first: person enrich with social handles in fields returns a dev platform identifier (the GitHub handle), and adding dev platform profiles (the dev add on, +1 credit) returns the full GitHub profile — repos, org memberships, and sometimes a public email . If that email is present and not a noreply address, use it and skip straight to Step 5 dev platform enrich({ crustdata person id }) fetches the same standalone for a person you already resolved Web search: "[Name] [Company] GitHub site:github.com" Check their personal website or Twitter bio Step 2: Verify the GitHub profile belongs to this person Confirm at least 2 of: bio mentions known company/role, profile name matches, repo topics align with known expertise, web search confirms the connection. Step 3: Find oldest non fork repo If Step 1 ran a dev enrichment, its dev platform profiles[].repos entries already carry full name , is fork , and github created at — pick the oldest non fork, no extra call needed. Otherwise list via the GitHub API: Pick first repo where "fork": false . Older repos (pre 2019) are more likely to have real emails. Step 4: Extract email from commits Method A — Commits API: Look in [0].commit.author.email within the fetched content . Method B — .patch endpoint (bypasses privacy settings): Extract from From: Name <email header line in the fetched content . Step 5: Validate — discard @users.noreply.github.com , noreply@github.com , and any email containing noreply . 3D: Web search fallbacks When both Crustdata personal email enrichment and GitHub don't work, try these in order: 1. GitHub issues/READMEs: "[name]" "@gmail.com" site:github.com 2. Competitive programming: "[name]" site:codeforces.com 3. Personal websites: "[name]" "[company]" email contact 4. Conference speaker pages: "[name]" "[company]" speaker email 5. Academic profiles: "[name]" site:scholar.google.com 3E: Handle GitHub API rate limits GitHub allows 60 unauthenticated requests/hour. Workarounds: Prefer the native dev enrichment for handle + repo discovery (Steps 1/3) — those calls never touch the GitHub REST API Use .patch endpoints (don't count against REST API limits) Fetch HTML commit pages and extract SHAs with regex, then use .patch Pass multiple URLs in a single web enrich live call ( urls: [...] ) Process in waves — API dependent steps first, then non API methods while rate limit resets Email priority When you have multiple emails for a candidate, prefer in this order: 1. Personal Gmail/ProtonMail — highest response rate for cold outreach 2. University email — if they're still in academia 3. Business email — last resort for cold outreach (often filtered by corporate

candidate-sourcing