dev-match.xyz

DevMatch finds engineers by verified GitHub contributions. Use these tools to search by role or project, look up a handle, or discover similar open-source projects. AGENT MODE (default for automations, Codex, Cursor agents) - Every tool returns full records in structuredContent with a view discriminator (candidates | profile | similar_projects). - Read structuredContent only. Do NOT parse content[0].text for data — it is a short summary for logs and human hosts. - Chain tools: find_similar_projects → find_candidates for hiring; do not call get_profile for logins already inline in find_candidates unless deeper detail is required. - Dedupe by login across multiple searches for the same role. Scope each response to the current request unless asked to merge. INPUT STRATEGY - Job descriptions are the most common input — pass the full JD when the user provides one. Longer, more specific text ranks better. - When a public GitHub repo is relevant: review README, topics, languages, and project purpose first, then pass a synthesized search brief combining a short project summary with role requirements. A bare repo URL works (server fetches README), but an evaluated summary usually ranks better. - Use the richest context available: JD, informal brief, README excerpt, repo-derived summary, or a mix. Do not require a repo when the user only has a JD. SEARCH SCOPE - find_candidates returns up to limit candidates per call (default 20, max 20 on MCP/Connectors). For more, run multiple targeted searches and dedupe. - find_similar_projects finds repo leads, not JD-ranked hires — follow with find_candidates for hiring matches. TOOL USAGE - find_candidates returns full inline profiles in structuredContent. Do not call get_profile for handles already in those results unless the user asks for deeper detail. ERRORS - On 500 or 503, retry once before reporting failure. Include the error body when available. HUMAN MODE (recruiter reading chat) - When the host shows the DevMatch MCP App panel (find_candidates / get_profile), reply in ONE short sentence pointing them to the panel — do not dump candidate tables in chat. - When no MCP App panel is available, present find_candidates results using the format below. PRESENTING RESULTS (text-only hosts) - find_candidates structuredContent contains full candidate objects. Present them as clean, scannable cards that STILL contain every email and url verbatim. - Across each candidate you MUST account for ALL of: recommended_contact, recommended_contact_kind, every contact.emails[] entry (with kind), every contact.guessed_emails[] entry, and EVERY contact.urls key-value pair. - Empty arrays render as "(none)"; never omit. Never write "GitHub only" or "no public email" instead of listing actual URLs. REQUIRED OUTPUT FORMAT (find_candidates) After every find_candidates call, show a discovery badge BEFORE the candidate cards whenever structuredContent.discovery_source is non-empty, then present EACH candidate in rank order as a card followed by a compact contact table. ## Discovery badge (when discovery_source is present) - **Corpus:** {discovery_source} — artifacts = work_artifacts index; projects = legacy serving.projects index - **Fallback:** when discovery_fallback is true, say "Auto-fell back to legacy projects index (artifact coverage thin)"; omit this line when false - **Quality:** when degraded is true, state degrade_reason. Corpus auto-fallback sets degraded=true with degrade_reason=discovery_fallback. ## {rank}. {name} · @{login} {location} · {followers} followers · reach p{reach.percentile} on {reach.max_platform} [omit a segment only when its value is empty; drop the whole reach segment when the candidate has no reach object; never invent one] > {bio} [omit the quote line entirely when bio is empty] Match: {matched_projects[0].repo} · {contribution_count} contributions · sim {project_sim} [list up to the 2 strongest matched_projects, comma-separated] | Contact | Value | |---|---| | Verified email | {the contact.emails[] entry with deliverable=true, else "(none)"} | | Best guess | {recommended_contact} ({recommended_contact_kind}) — or "(none)" when empty | | Other emails | {every remaining contact.emails[] as email (kind), comma-separated; "(none)" if none} | | Other guesses | {every contact.guessed_emails[] not already shown as Best guess, comma-separated; "(none)" if none} | | Links | {every contact.urls value as a markdown link [key](url), separated by " · "; "(none)" if the map is empty} | COMPLETENESS RULES (still mandatory under the cleaner layout): - Every contact.emails[] entry must appear somewhere in the table (Verified or Other emails), with its kind shown. - Every contact.guessed_emails[] entry must appear (Best guess or Other guesses). Generic addresses (e.g. hello@, info@, contact@, or org@org-domain) may be listed last but must not be dropped. - Every contact.urls key must appear in Links — never collapse to "GitHub only", "full socials", "see profile", or "no public email". - Empty arrays render as "(none)" in their cell; never omit the row. After the per-candidate cards, you MAY add one short "Notes" paragraph (deliverability caveats, location/seniority fit, employer conflicts). Keep it brief — the cards carry the data.