Build evidence-linked candidate shortlists

Recruit turns a job post or supplied job description into a ranked candidate shortlist through Treg. It extracts role criteria, searches title variants, deduplicates results, applies hard filters, and writes a specific reason for each ranked candidate. Optional evidence collection can revise those rankings.

Every stage is counted and recorded in a run file, including contact-provider attempts and actual charges. The result supports a person's recruitment review; it does not make hiring decisions or send outreach automatically.

Use it to source people for a defined role or rank supplied applicants against job-related requirements. Before spending, show the extracted criteria and estimated total cost and work within an explicitly approved budget.

Ranking uses qualifications relevant to the role rather than sensitive or protected traits. Authorized business-contact enrichment is optional and separate from sourcing. Private personal emails, home addresses, and personal phone numbers are outside its scope. If supplied applicant records answer the task, the workflow can use them without expanding into contact discovery.

The skill needs an existing authorized Treg connection or CLI. Catalog installation alone grants no account access or spending permission. Current endpoint details take precedence over pinned provider examples and historical prices.

Read a job URL through an appropriate discovered endpoint, or use pasted text. Extract the posted title plus two to four equivalent titles, must-have skills, seniority, locations, remote eligibility, and hiring company. Exclude the hiring company from sourcing.

Search each title and relevant location combination. The documented example illustrates a bounded initial query:

treg call treg.people.search --data '{"title":"Staff Backend Engineer","location":"Berlin, Germany","country":"DE","keywords":["go","kafka"],"limit":25}'

The limit controls row volume and therefore potential cost. Check ignored_filters because a provider may return a broader search than requested. Deduplicate normalized LinkedIn URLs, falling back to name and company when necessary.

Hard filters reject hiring-company employees, wrong locations, unsuitable seniority, unrelated job families, and rows without a usable profile URL. Record a reason for every rejection. Rank survivors only when a concrete fit explanation can be written in the user's terms; the default shortlist is twenty.

Optional evidence collection covers the top candidates within a per-person cap. Sources can include their recent posts, relevant GitHub work, talks, writing, job changes, tenure, and company news. Do not guess handles. A returned item must actually name or belong to the candidate before it supports a claim, and post feeds require checking authorship and recency. Evidence-backed or contradicted claims can change the score.

Contact enrichment favors candidate-provided or published professional details. Other business-email lookups require authorized identifiers, a company or domain match, a current schema, and approved enrichment limits. Unsupported contact fields stay empty, and billed lookups are not repeated for the same person.

The timestamped recruit-run JSON file is updated after every stage. It contains job criteria, stage counts, rejection reasons and samples, ranks, evidence, contact results, provider attempts, and totals. Evidence records retain the retrieval endpoint, claim, available URL, and charge. Shared company-news charges are counted once.

Actual cost comes from returned charged_micro and verification cost fields rather than a price list. Provider attempts preserve hit, miss, or skipped outcomes. Contact verdicts retain the provider's own wording, and misses remain null. The final handoff gives the shortlist, run file, coverage counts, and total settled cost.

Treg MCP or CLI catalog discovery and call operations connect the research stages. Routed people search and authorized business-email lookup support sourcing and optional enrichment, while discovered evidence providers supply cited facts. Availability, filter support, prices, and live results require inspection of the current connected service.