Un Claude Skill qui prend un profil de poste plus une rubrique ICP, construit une requête de sourcing AI contre Juicebox, hireEZ ou LinkedIn Recruiter, récupère jusqu’à 200 candidats, score chacun par rapport à la rubrique avec des preuves citées, et rédige un outreach personnalisé pour le top-N — puis s’arrête à une porte de révision humaine. Le recruteur lit la shortlist, édite les messages et envoie. Remplace la boucle de 3 heures booléen-plus-scoring-plus-outreach par une boucle de révision de 30 minutes.
Quand utiliser
Vous sourcez un poste qui revient plus d’une fois par trimestre et la rubrique ICP est assez stable pour être écrite.
Vous avez une rubrique ICP avec des ancres comportementales par dimension (pas seulement des étiquettes vagues). Le modèle de rubrique dans references/1-icp-rubric-template.md du bundle montre la forme ; si vous ne pouvez pas le remplir, vous n’avez pas encore de rubrique contre laquelle ce skill peut scorer.
Vous avez un accès API à Juicebox PeopleGPT, hireEZ ou LinkedIn Recruiter. Le skill refuse de se rabattre sur le scraping d’URLs LinkedIn publiques.
Un recruteur ou un sourcer humain révise chaque shortlist avant qu’un outreach soit envoyé. Le skill écrit des brouillons sur le disque et s’arrête.
Quand NE PAS utiliser
Rejet automatique dans la boucle. Le skill classe ; il ne rejette pas. Les candidats « ignorés » sont présentés avec des raisons pour que le recruteur puisse les infirmer. Câbler une action reject à un seuil de score transforme cela en décision automatisée et déclenche les obligations à haut risque de l’Annexe III de l’Acte AI UE plus les obligations d’audit de biais NYC LL 144 dans l’année précédant l’utilisation. Si vous en avez besoin, faites un audit de biais, pas ce skill.
Scoring sur des proxies de classe protégée. Le prestige scolaire comme dimension autonome, l’origine des noms, la présence de photo, les pénalités de lacune d’emploi, l’âge déduit de l’année de diplôme, le « cultural fit » sans ancres comportementales. La checklist d’équité du skill refuse de s’exécuter si l’un de ces éléments apparaît dans la rubrique. Ne modifiez pas la checklist pour faire passer une rubrique biaisée.
Recommandations de tranche salariale. NYC LL 32-A, Colorado, Californie et Washington exigent des fourchettes affichées et des obligations d’audit de biais sur les décisions de rémunération automatisées. Utilisez un outil de benchmarking de rémunération, pas un skill de sourcing.
Recherches C-suite ponctuelles. Une recherche retenue pour un individu nommé spécifique ou un cadre étroitement défini est plus rapide faite par un humain avec son réseau. Le skill est conçu pour le sourcing répétable de IC et de managers, où la calibration de la rubrique rentabilise son coût de configuration.
Vérifications de références ou recherches de réseau en coulisse. Posture de consentement différente. Workflow différent.
Configuration
Déposez le bundle. Placez apps/web/public/artifacts/candidate-sourcing-claude-skill/SKILL.md dans votre répertoire de skills Claude Code (ou vos Skills personnalisés claude.ai).
Remplissez la rubrique. Copiez references/1-icp-rubric-template.md dans un fichier par poste sous votre propre repo. Remplacez chaque {placeholder}. Le skill capture le SHA-256 de la rubrique dans son journal d’audit par exécution, pour que les modifications ultérieures soient visibles en rétrospective.
Configurez le canal source. Ajoutez votre clé API Juicebox ou hireEZ à la config du skill. Pour LinkedIn, configurez les credentials de l’API Recruiter — le skill refuse de scraper des URLs de profil publiques.
Rédigez les listes do-not-poach et d’exclusion. Un CSV de domaines clients (do-not-poach) et un CSV d’URLs exclude_list (récemment refusés, en période silencieuse, désabonnés). Le pré-filtre déterministe à l’étape 3 du skill applique ces listes avant que le LLM voie un quelconque candidat.
Dry-run sur un poste clos. Lancez sur un poste que vous avez sourcé manuellement le trimestre dernier. Comparez le top-25 du skill à votre top-25 manuel. Affinez les ancres de rubrique si le skill calibre différemment — les ancres, pas la requête de recherche, sont généralement le problème.
Ce que le skill fait réellement
Six étapes, dans l’ordre. L’ordre compte : les filtres déterministes et le pré-vol d’équité viennent avant le classement LLM, parce que laisser un LLM opérer sur un pool contaminé produit une sortie rapide, confiante et inutilisable.
Valider la rubrique par rapport à references/2-fairness-checklist.md. S’arrêter si la rubrique contient des proxies de classe protégée. Le choix d’échouer avant la récupération plutôt qu’après est délibéré — une rubrique biaisée chargée dans l’API d’un outil de sourcing laisse une entrée de journal qui compte déjà comme traitement automatisé sous l’Art. 22 du RGPD.
Construire la requête de recherche dans le format natif du canal. Plafonner les synonymes à 5 par dimension ; plafonner le pool récupéré à 200. Des pools plus grands dégradent le classement parce que le contexte du modèle se remplit de candidats peu pertinents.
Pré-filtre déterministe. Supprimer les correspondances exclude_list, les entreprises do-not-poach, les inadéquations de localisation, et les profils périmés de plus de 18 mois. Ce sont des filtres auditables ; le LLM ne les re-discute pas.
Classement basé sur la rubrique. Scorer 1-5 sur compétences, niveau, pattern d’entreprise, propension à répondre. Chaque score supérieur à 1 cite une chaîne de profil verbatim. Pas de citation → score 1. L’exigence de citation est ce qui maintient le modèle ancré dans le texte du profil plutôt qu’en train d’inférer à partir du nom, de la photo ou de l’école.
Porte de révision humaine. Écrire shortlist.md et les fichiers outreach/<id>.md par candidat. S’arrêter. Le skill ne définit aucune action send.
Journal d’audit. Ajouter une ligne JSONL par exécution avec run_id, rubric_sha256, tailles de pool, canal, modèle. Pas de PII. C’est ce qui rend l’exécution défendable sous NYC LL 144 ou l’interrogatoire de l’Acte AI UE.
Le format de shortlist et la mise en page des preuves par candidat se trouvent dans references/3-shortlist-format.md du bundle. Le format est fixe parce que les consommateurs en aval — recruteur, hiring manager, reviewer d’audit — ont besoin de colonnes prévisibles.
Réalité des coûts
Par shortlist de 25 sur un pool de 200 candidats, sur Claude Sonnet 4.5 :
Coût de récupération — dépend du canal. Juicebox PeopleGPT compte sur votre quota de requêtes mensuel (les plans starter de 200 recherches s’épuisent vite si vous lancez plusieurs postes par semaine). Le nombre d’unlocks-par-mois de hireEZ est la contrainte déterminante. L’API LinkedIn Recruiter a ses propres quotas InMail et de recherche par siège. Rien de tout cela ne change avec le skill dans la boucle ; vous dépensez le même quota de canal que vous auriez dépensé à la main en booléen.
Tokens LLM — typiquement 80-120 000 tokens d’entrée (rubrique + 200 extraits de profils candidats + instructions du skill) et 8-15 000 tokens de sortie (shortlist + 25 brouillons d’outreach). Sur Sonnet 4.5, c’est environ 0,50-0,80 USD par shortlist. Le mois complet pour un sourcer gérant ~80 shortlists représente 40-65 USD en coût de modèle.
Temps du recruteur — le gain est ici, pas dans le coût de modèle. Le booléen manuel + scoring + outreach pour 25 candidats prend 2-3 heures. Réviser la shortlist du skill et éditer les brouillons prend 25-40 minutes, ce qui rend le workflow rentable.
Temps de configuration — 45 minutes pour la rubrique et les listes d’exclusion si la rubrique existe déjà sous une forme quelconque ; plus long si la rubrique est entièrement nouvelle (auquel cas l’entretien structuré est le prérequis, pas ce skill).
Métrique de succès
Suivez trois chiffres par poste par mois, dans l’ATS :
Taux de réponse à l’outreach — devrait correspondre ou dépasser le taux de référence manuel du recruteur. S’il baisse, les brouillons d’outreach sont génériques — généralement la rubrique est trop grossière, pas le modèle.
Taux de passage shortlist vers screen — la part des candidats en shortlist que le hiring manager estime valables pour un screen. Devrait être ≥70 % sur un poste stable. En dessous, la rubrique ICP est mal calibrée ; relancez sur un poste clos et affinez.
Délai d’ouverture du poste au premier screen qualifié — la métrique de débit que le skill est censé améliorer. La réduction de 3 heures à 30 minutes se voit ici, pas dans les dépenses de modèle.
Par rapport aux alternatives
vs Gem AI Sourcing — Gem possède le workflow recruteur de bout en bout (UI de sourcing, séquences, analytics, intégration ATS via Ashby et d’autres). Choisissez Gem si vous voulez un produit géré et que votre équipe vivra dans son UI. Choisissez ce skill si vous voulez la rubrique, la logique de pré-filtre et le journal d’audit dans votre propre repo, versionnés, avec le modèle swappable.
vs le classement AI intégré de hireEZ — l’AI Match de hireEZ est une bonne récupération ; l’écart se situe au niveau de la couche de rubrique. Avec ce skill, vous gardez hireEZ comme canal de récupération et apportez votre propre rubrique + scoring avec preuves citées par-dessus. Si les valeurs par défaut de hireEZ correspondent à votre ICP, vous n’avez pas besoin de ce skill.
vs booléen manuel + scoring sur feuille de calcul — le manuel est la bonne option pour les recherches ponctuelles ou de cadres, où la rubrique est dans la tête du recruteur et l’écrire est une surcharge qui ne se rentabilise pas. Le skill rentabilise son coût de configuration sur les postes qui se répètent.
vs script Python DIY contre les APIs LinkedIn / Juicebox — même qualité de classement si vous rédigez soigneusement le prompt, mais vous construisez aussi la checklist d’équité, le journal d’audit et la porte de révision humaine vous-même. Le bundle les livre.
Points de vigilance
Amplification des biais — protégée par la checklist d’équité dans references/2-fairness-checklist.md, qui arrête l’exécution si la rubrique contient des proxies de classe protégée. Le journal d’audit capture rubric_sha256 par exécution pour que la rubrique utilisée à une date donnée soit reproductible sous revue Acte AI UE ou NYC LL 144.
Données LinkedIn / Juicebox périmées — protégée par le filtre déterministe à l’étape 3 (supprimer les profils périmés de plus de 18 mois) et par la dimension propension-à-répondre dans le scoring (qui pondère la fraîcheur). Les candidats en stockage froid ne noient pas les candidats en recherche active.
Exposition aux CGU LinkedIn — protégée par le refus de scraper des URLs de profil publiques. Le skill utilise l’API Recruiter, Juicebox ou hireEZ, qui ont leurs propres licences de données. Si linkedin_recruiter est sélectionné et que l’API n’est pas configurée, le skill s’interrompt avec une erreur de configuration plutôt que de se rabattre.
Dérive de l’envoi automatique — protégée par la porte de révision humaine (étape 5) et par l’absence de toute action send dans le skill. Les brouillons sont écrits dans les fichiers outreach/<id>.md pour que le recruteur les colle dans la boîte d’envoi ATS / outil de sourcing. Le brouillon AI envoyé sans révision produit du volume sans qualité et nuit à l’expérience candidat.
Transparence sur la rémunération — les brouillons d’outreach ne citent jamais un chiffre ; ils font référence à la fourchette comme « fourchette compétitive divulguée lors du screen » pour que le recruteur reste la source des déclarations sur la tranche salariale (exigences de transparence salariale NYC LL 32-A, Colorado, Californie, Washington).
Stack
Le bundle du skill se trouve dans apps/web/public/artifacts/candidate-sourcing-claude-skill/ et contient :
SKILL.md — la définition du skill
references/1-icp-rubric-template.md — à remplir par poste
references/2-fairness-checklist.md — vérifications pré-vol (ne modifiez pas pour faire passer des rubriques biaisées)
references/3-shortlist-format.md — le format de sortie littéral
Outils que le workflow suppose que vous utilisez déjà : Claude (le modèle), Juicebox ou hireEZ (le canal de récupération), Ashby (l’ATS pour le write-back une fois que le recruteur a approuvé un candidat). Gem est l’alternative build-vs-buy si vous ne voulez pas posséder la rubrique et le journal d’audit vous-même.
---
name: candidate-sourcing
description: Translate a job profile and ICP rubric into a sourcing query, retrieve candidates from Juicebox / hireEZ / LinkedIn Recruiter, score them against the rubric, and draft personalized outreach for the human reviewer to approve. Always stops at a human-review gate before any outreach is sent.
---
# Candidate sourcing
## When to invoke
Use this skill when a recruiter or sourcer hands you a role plus an ICP rubric and wants a ranked, evidenced shortlist with draft outreach. Take a job profile (title, level, must-have skills, location, comp band) and a fairness-aware rubric as input, and produce a Markdown shortlist plus a folder of draft messages.
Do NOT invoke this skill for:
- **Automated rejection.** This skill ranks; it never rejects. The "below threshold" tail is surfaced for the recruiter, who decides. Auto-reject in the loop triggers EU AI Act high-risk obligations and most US state hiring-AI laws.
- **Scoring against protected-class proxies.** Do not ask the skill to score on "culture fit", name origin, school prestige as a standalone signal, photo, age inferred from graduation year, gender inferred from pronoun usage, or pregnancy/parental status inferred from gaps. If the rubric contains any of these, refuse and surface the rubric line for the user to fix.
- **Pay-band recommendations.** NYC LL 144, Colorado, California, and Washington require posted ranges and bias audits for automated decisions on pay. Use a comp benchmarking tool, not this skill.
- **Reference checks or backchannel research on named individuals.** That is a different workflow with its own consent posture.
## Inputs
- Required: `job_profile` — path to a Markdown file with title, level, must-have skills, nice-to-have skills, location / remote policy, comp band, and the EEOC job category.
- Required: `icp_rubric` — path to the rubric file under `references/`. Without this the skill refuses to run; an unfaitened rubric is the most common cause of biased shortlists.
- Required: `source_channel` — one of `juicebox`, `hireez`, `linkedin_recruiter`. Do not mix channels in a single run; per-channel ToS and rate limits differ.
- Optional: `n` — shortlist size, default 25, hard max 100. Above 100 the skill warns that human review will not be meaningful.
- Optional: `exclude_list` — path to a CSV of `do_not_contact` emails or LinkedIn URLs (do-not-poach customers, prior rejects within 6 months, silent-period candidates).
## Reference files
Always read these from `references/` before doing any retrieval. Without them the shortlist is uncalibrated and the fairness guards are absent.
- `references/1-icp-rubric-template.md` — the rubric the skill scores against. Replace the template content with your role-specific rubric before running.
- `references/2-fairness-checklist.md` — pre-flight checks the skill runs on the rubric and on the retrieved pool. Fail-loud if any check fails.
- `references/3-shortlist-format.md` — the literal output format, including the evidence and source-URL columns the recruiter needs to defend the shortlist downstream.
## Method
Run these six steps in order. Steps 1-3 are deterministic filters and fairness pre-flight; only step 4 uses the LLM for ranking. The order is deliberate — running the LLM over an unfiltered, ToS-violating, or rubric-contaminated pool produces output that is fast, confident, and unusable.
### 1. Validate the rubric
Open `icp_rubric` and run every check in `references/2-fairness-checklist.md`. If any line in the rubric matches a protected-class proxy pattern (school-tier scoring, name-based filtering, employment-gap penalties, photo presence, "culture fit" without behavioral anchors), stop and return the offending lines to the user. Do not proceed with retrieval.
The choice to fail before retrieval rather than after is intentional: a biased rubric loaded into a sourcing tool's API leaves a log entry that counts as automated processing under GDPR Art. 22 and the EU AI Act, regardless of whether the skill ever shows the user the result.
### 2. Build the search query
Translate the job-profile must-haves into the channel's native query format:
- `juicebox` → natural-language PeopleGPT prompt, with location and level filters set as structured parameters not free text.
- `hireez` → Boolean string with explicit AND/OR/NOT grouping. Cap synonyms at 5 per dimension; longer Boolean degrades hireEZ's relevance ranking.
- `linkedin_recruiter` → use the Recruiter API with structured filters only. **Do not scrape `linkedin.com/in/` URLs** — that violates LinkedIn ToS and the *hiQ v. LinkedIn* settlement does not change ToS exposure for production sourcing.
Cap the retrieved pool at 200. Larger pools degrade rubric scoring because the LLM context fills with low-relevance candidates and the ranking flattens.
### 3. Deterministic pre-filter
Before the LLM sees any candidate, apply hard filters:
- Drop anyone in `exclude_list`.
- Drop anyone whose current company is on the do-not-poach list.
- Drop anyone whose profile was last updated more than 18 months ago (LinkedIn / Juicebox staleness signal).
- Keep only candidates whose stated location matches the role's location policy (with a configurable radius for hybrid roles).
These filters are deterministic so they can be audited. The LLM does not re-litigate them in step 4.
### 4. Rubric-based ranking
For each remaining candidate, score 1-5 on each rubric dimension (skill-match, level-fit, company-pattern-fit, response-likelihood). For every score above 1, cite the specific evidence string from the candidate's profile. No evidence string → score 1 by default.
Why a citation requirement: it forces the model to ground each score in profile text rather than infer from a name, photo, or school. Scores without evidence are the mechanism by which bias enters AI-augmented sourcing pipelines.
### 5. Human-review gate
Stop. Write the shortlist to `shortlist.md` per the format in `references/3-shortlist-format.md`. Write the draft outreach to `outreach/<candidate-id>.md`, one file per candidate. Do not call any "send" endpoint. Do not mark candidates as contacted in the ATS. Surface the path to both directories and exit.
The recruiter's job from here: read the shortlist, edit the messages, and send through the ATS or sourcing tool's outbox. The skill does not re-enter the loop until the next role.
### 6. Audit log
Append a single line to `audit/<YYYY-MM>.jsonl` containing: `run_id`, `role`, `rubric_sha256`, `pool_size_pre_filter`, `pool_size_post_filter`, `shortlist_size`, `channel`, `model_id`, `timestamp`. Do not log candidate PII to this file. The audit log exists so that under NYC LL 144 or EU AI Act questioning, the recruiter can demonstrate which rubric was used on which date.
## Output format
```markdown
# Sourcing shortlist — {Role title}
Generated: {ISO timestamp} · Channel: {channel} · Pool: {pre} → {post} · Rubric SHA: {short}
| # | Name | Current role | Current company | Skill | Level | Pattern | Response | Aggregate | Source |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Jamie L. | Senior Backend Engineer | Acme Fintech | 5 | 5 | 4 | 4 | 18 | {URL} |
| 2 | ... | ... | ... | ... | ... | ... | ... | ... | ... |
## Evidence — top 5
### 1. Jamie L. (aggregate 18)
- **Skill (5)**: "5y Go, 2y Rust, led migration from monolith to event-driven services" — profile, role 2.
- **Level (5)**: "Senior IC, scope across two teams, mentors three engineers" — profile, current role.
- **Pattern (4)**: "Stripe → Plaid → Acme Fintech" — three fintech roles in sequence.
- **Response likelihood (4)**: profile updated 11 days ago, "open to opportunities" tag set.
### 2. ...
## Skipped — surfaced for review (not auto-rejected)
| Name | Reason |
|---|---|
| ... | "current company on do-not-poach list (Acme Customer)" |
| ... | "profile last updated 2023-11, staleness > 18mo" |
## Draft outreach
Drafts written to `outreach/`. Recruiter reviews and sends; this skill
does not contact candidates.
- `outreach/jamie-l.md`
- `outreach/...`
```
## Watch-outs
- **Bias amplification (NYC LL 144, EU AI Act, EEOC).** *Guard:* the fairness checklist in `references/2-fairness-checklist.md` runs in step 1 and refuses retrieval if rubric contains protected-class proxies. Audit log in step 6 stores `rubric_sha256` so the rubric used on a given run is reproducible.
- **LinkedIn ToS exposure.** *Guard:* skill uses the Recruiter API (or Juicebox / hireEZ which carry their own data licensing), never scrapes public LinkedIn pages. If the channel is `linkedin_recruiter` and the Recruiter API is not configured, the skill aborts with a setup-error rather than falling back to scraping.
- **Stale profile data.** *Guard:* deterministic filter in step 3 drops candidates with `profile_updated > 18mo`. Response-likelihood scoring in step 4 weights profile freshness explicitly so cold-storage candidates do not crowd out actively looking ones.
- **Auto-send drift.** *Guard:* skill stops at the human-review gate in step 5 and writes to `outreach/` files. There is no `send` action defined anywhere in this skill. To send, the recruiter pastes into the ATS / sourcing tool outbox.
- **Rubric drift mid-search.** *Guard:* `rubric_sha256` is captured per run; if the rubric changes between two runs for the same role, the audit log shows both hashes, making it visible in retro.
- **Compensation discussion in draft outreach.** *Guard:* outreach templates in this skill never quote a number; they reference the comp band as "competitive range disclosed on screen" so the recruiter remains the source of pay-band statements (NYC LL 32-A, CO, CA, WA pay-transparency posting).
# ICP rubric — TEMPLATE (per role)
> Replace this template's contents with the rubric for the specific role.
> The candidate-sourcing skill scores against the four dimensions below.
> Each dimension MUST have behavioral anchors — vague labels ("senior")
> without anchors produce noisy and biased scoring.
## Role identity
- **Title**: {e.g. Senior Backend Engineer, Platform}
- **Level**: {IC4 / IC5 / EM1 — your internal scale}
- **Location policy**: {remote-US / hybrid-NYC-2dpw / onsite-Berlin}
- **EEOC job category**: {2 — Professionals (most engineers); see EEO-1}
- **Comp band (recruiter-internal, never sent to skill output)**: {range}
## Dimension 1 — Skill match (1-5)
The candidate's profile shows direct experience with the must-have technologies and the specific problem-shape of the role.
| Score | Anchor |
|---|---|
| 5 | Held a role doing exactly this work for ≥2 years; cites artifacts (talks, OSS, posts). |
| 4 | Held a role doing exactly this work for ≥1 year; no artifacts. |
| 3 | Adjacent work (e.g. Java backend role for a Go role); transferable. |
| 2 | Tangential work; would require ramp. |
| 1 | No evidence in profile. |
## Dimension 2 — Level fit (1-5)
The candidate's stated scope and tenure pattern match the level the role is hiring at. Do NOT use school prestige, employer prestige, or title inflation as a level signal — anchor on scope description.
| Score | Anchor |
|---|---|
| 5 | Profile shows scope at or above target level (multi-team, mentoring, technical strategy). |
| 4 | Scope at target level for ≥1 year. |
| 3 | One level below target; growth trajectory plausible. |
| 2 | Two levels below; reach. |
| 1 | More than two levels off, in either direction. |
## Dimension 3 — Company-pattern fit (1-5)
The shape of the candidate's prior employers matches the shape of yours (stage, scale, regulated/unregulated, B2B/B2C). Anchor on *characteristics*, not brand names — brand-name scoring is the most common bias vector in AI-augmented sourcing.
| Score | Anchor |
|---|---|
| 5 | ≥2 prior employers match {stage/scale/domain pattern}. |
| 4 | 1 prior employer matches; others adjacent. |
| 3 | All adjacent (different domain, similar stage). |
| 2 | Mostly mismatched; one transferable role. |
| 1 | No pattern match. |
## Dimension 4 — Response likelihood (1-5)
How likely the candidate is to respond to outreach right now.
| Score | Anchor |
|---|---|
| 5 | Profile updated <30 days; "open to opportunities" set; recently posted about job search. |
| 4 | Profile updated <90 days. |
| 3 | Profile updated <180 days. |
| 2 | Profile updated <12 months. |
| 1 | Stale profile (>12 months) — *also flagged in pre-filter for drop at >18mo*. |
## Disqualifiers (deterministic, applied in step 3 of the skill)
These cause the candidate to be surfaced in the "skipped" table, not auto-rejected. The recruiter decides.
- Current company is on do-not-poach list (`{path-to-list}`).
- Email or LinkedIn URL appears in `exclude_list`.
- Stated location does not match role's location policy + radius.
- Profile last updated >18 months ago.
## Bias guards (refusal triggers — skill aborts in step 1 if present)
If any of the following appear in this rubric, the skill refuses to run:
- School-tier scoring as a standalone dimension.
- Name-based filtering or scoring.
- Photo-based scoring.
- Employment-gap penalties without a job-related justification.
- Age inferred from graduation year used in any dimension.
- Gender, ethnicity, religion, sexual orientation, parental status, or disability status as a scored or filtered dimension.
- "Culture fit" without behavioral anchors.
## Last edited
{YYYY-MM-DD} — bump on every material change. The skill captures the SHA-256 of this file in its audit log per run.
# Fairness pre-flight checklist
> The candidate-sourcing skill runs every check below in step 1 (rubric
> validation) and step 3 (post-filter pool review). Any failed check
> halts the run with a message naming the failure. Do not edit this file
> to make checks pass — fix the rubric or the search instead.
## A. Rubric checks (run before retrieval)
A1. **No protected-class proxies.** Scan the rubric for any of the following terms or patterns. Any hit halts the run:
- `school`, `university`, `Ivy`, `tier-1`, `top-N` (when used as a scoring dimension, not as one signal among many)
- `name origin`, `surname`, `first name`
- `photo`, `headshot`, `appearance`
- `age`, `years since graduation`, `birth year`
- `gender`, `pronoun`, `she/her`, `he/him` (as filter terms)
- `ethnicity`, `race`, `nationality` (except where required for immigration-status filtering with documented legal basis)
- `pregnant`, `parental`, `maternity`, `paternity`
- `disability`, `accommodation`
- `religion`, `political`, `marital`
- `culture fit` without a behavioral-anchor table immediately following
A2. **Anchors present on every dimension.** Each rubric dimension must have a 1-5 anchor table. Anchors prevent the LLM from scoring on vibes. Halt if any dimension has free-text anchors only.
A3. **Disqualifier list is short and mechanical.** Disqualifiers must be deterministic facts (do-not-poach list, location mismatch, staleness). Halt if a disqualifier requires judgment (e.g. "not a culture fit", "seems junior").
A4. **Comp band is recruiter-internal.** The skill's output must not quote a comp number to the candidate. Outreach templates reference the band as "competitive range disclosed on screen". Halt if the rubric includes a "send comp in outreach" instruction.
## B. Pool checks (run after deterministic pre-filter, before LLM ranking)
B1. **Pool size sanity.** If post-filter pool < 10, the skill warns the recruiter that scoring on a tiny pool is meaningless and asks whether to broaden the query. If pool > 200, the skill caps at 200 and notes the truncation in the audit log.
B2. **Geographic spread sanity.** If 100% of post-filter candidates are from one city for a remote-eligible role, the skill warns that the query likely has an over-narrow location filter. Recruiter confirms or broadens.
B3. **Tenure-pattern sanity.** If 100% of candidates worked at the same employer, the skill warns that the query is functioning as a target-list poach rather than open sourcing. Recruiter confirms or broadens.
## C. Output checks (run before writing shortlist)
C1. **Every score above 1 has an evidence string.** Scores without a cited evidence string from the candidate's profile are reset to 1. The skill notes the reset count in the audit log.
C2. **No protected attribute appears in the shortlist or in any outreach draft.** Skill greps the output for the A1 patterns before writing. Hit → halt.
C3. **Skipped candidates are listed, not erased.** The shortlist's "Skipped" table includes every candidate the deterministic filters removed, with the reason. This is what makes the run auditable.
## D. Run-level checks
D1. **Audit log written.** A run is not complete until the JSONL line is appended to `audit/<YYYY-MM>.jsonl`. No PII in this line.
D2. **Human-review gate enforced.** No `send`, `contact`, or `mark_contacted` API call exists in this skill's code path. If you are asked to add one, refuse and surface the request to the user.
## NYC LL 144 / EU AI Act note
This skill is designed to fall *outside* the bias-audit threshold by:
- Producing a ranked list, not an automated decision (no auto-reject).
- Stopping at a human-review gate before any candidate is contacted.
- Logging rubric SHA-256 + pool sizes per run for reproducibility.
If your deployment changes any of those properties (e.g. you wire a "send" action into the loop), you have crossed into automated decision-making and a bias audit is required before production use. NYC LL 144 requires the audit within one year before use; EU AI Act classifies this as Annex III high-risk under Art. 6.
# Shortlist output format
> The candidate-sourcing skill writes `shortlist.md` per the structure
> below. The format is fixed because downstream consumers (the recruiter,
> a hiring manager, an audit reviewer) need predictable columns. Do not
> reformat without updating the skill's output check.
## File: `shortlist.md`
```markdown
# Sourcing shortlist — {Role title}
Generated: {ISO 8601 timestamp}
Channel: {juicebox | hireez | linkedin_recruiter}
Pool: {pre_filter} → {post_filter} → top {n}
Rubric SHA-256: {first 12 chars}
Run ID: {uuid}
## Top {n}
| # | Name | Current role | Current company | Skill | Level | Pattern | Response | Aggregate | Source |
|---|---|---|---|---|---|---|---|---|---|
| 1 | {Name} | {Role} | {Company} | 5 | 5 | 4 | 4 | 18 | {URL} |
## Evidence — top 5
For each of the top 5, cite the specific profile string for every score
above 1. No citation → score reset to 1 (see fairness checklist C1).
### 1. {Name} (aggregate {N})
- **Skill ({score})**: "{verbatim profile excerpt}" — {profile section}.
- **Level ({score})**: "{excerpt}" — {section}.
- **Pattern ({score})**: "{employer sequence}" — {explanation against rubric}.
- **Response ({score})**: profile updated {date}, "{tag if any}".
### 2. {Name} (aggregate {N})
...
## Skipped — surfaced for review (NOT auto-rejected)
| Name | Reason | Source |
|---|---|---|
| {Name} | "current company on do-not-poach list ({customer})" | {URL} |
| {Name} | "stated location {city} outside role policy {policy}" | {URL} |
| {Name} | "profile last updated {date}, staleness > 18mo" | {URL} |
## Suggested talk-track per top candidate
The recruiter uses these as talk-track scaffolding for the first
screening call. They are NOT scripts.
### 1. {Name}
- **Open with**: their {recent role / talk / OSS contribution} — specific
reference, not a generic compliment.
- **Likely motivation hypothesis**: {evidence-based, e.g. "third fintech
role in a row, may be looking for a non-fintech reset; ask"}.
- **Hesitation to surface**: {e.g. "current company is well-funded; ask
what would have to be true for them to consider a move"}.
### 2. {Name}
...
## Outreach drafts
Drafts written to `outreach/{candidate-id}.md`, one file per candidate.
The recruiter reviews, edits, and sends through the ATS or sourcing
tool's outbox. The skill does not contact candidates.
- `outreach/{id-1}.md`
- `outreach/{id-2}.md`
- ...
```
## File: `outreach/<candidate-id>.md`
```markdown
# Outreach draft — {Name}
Channel: {LinkedIn InMail | email | Juicebox sequence}
Subject: {≤60 chars, references a specific signal from the profile}
---
Hi {first name},
{One sentence referencing a specific, recent thing from their profile —
the {recent role / talk / project / post}. Not a flattery line.}
I'm hiring a {role title} at {company}. The reason I reached out is
{specific connection between their background and the role — cite the
profile signal}. The role's {one specific differentiator that would
matter to someone with this background}.
If you're open to a 15-minute conversation, I'm happy to share more. The
comp range will be disclosed on screen if we get to that step.
{Recruiter name}
---
## Recruiter-only metadata (strip before sending)
- Aggregate score: {N}
- Top evidence string: "{excerpt}"
- Source URL: {URL}
- Run ID: {uuid}
- Reviewed by recruiter: [ ]
- Sent: [ ]
```
## Why these fields are non-negotiable
- **`Source` URL on every row** — required for the recruiter to spot-check the LLM's evidence claims against the actual profile.
- **`Pool: pre → post → top N`** — surfaces how many candidates were filtered out deterministically vs. by the LLM. Big LLM-side cuts on a small post-filter pool is a signal of overfitting to rubric noise.
- **`Rubric SHA-256`** — proves which rubric was used on this run (NYC LL 144 audit defense + EU AI Act traceability).
- **`Skipped` table** — candidates filtered out are listed with reasons, not erased. Erasing them turns the workflow into automated rejection.
- **Recruiter-only metadata in outreach** — stripped before sending; its presence in the draft is what reminds the recruiter the message is a draft, not a finished product.
