Personalize sourced-candidate outreach at scale with Claude

---
name: candidate-personalization-at-scale
description: Personalize outreach messages for a sourced candidate list using LinkedIn profile data, GitHub activity, and job description signals. Returns a personalized subject line and first paragraph for each candidate, grounded only in verified public information. Use for sourced outreach at scale — not for inbound applicants, not for roles where personalization can expose protected-class proxies, and not when no public signal exists for the candidate.
---

# Candidate personalization at scale

## When to invoke

Invoke when you have a sourced list of candidates (from Gem, LinkedIn Recruiter, or a CSV export from any sourcing tool) and want to write a personalized first outreach that references something real about each person — a recent project, a company they worked at, a specific skill in their GitHub — rather than sending a mail-merge template that reads like a mail-merge template.

The skill takes a candidate row (name, title, current company, LinkedIn URL, and optionally GitHub handle and the role's JD) and returns a personalized subject line and a 2-3 sentence opening paragraph. The personalization is grounded only in public signals the skill can verify — it never invents details. If no qualifying signal exists for a candidate, the skill returns a clean generic fallback rather than making one up.

Typical entry points:

- A **Gem sequence** where the first touchpoint is personalized per-candidate using this skill before bulk enrollment.
- A **recruiter manual workflow** where the sourcer pastes a CSV, gets personalized drafts back, reviews and edits, then sends.
- A **script over a LinkedIn export** that runs the skill per row and writes the personalized draft to a new column alongside the source data.

Do NOT invoke this skill for:

- **Inbound applicants.** Personalization for applicants should reference their application, not their public profile — a different context and a different skill.
- **Candidates where the only available signal is demographic.** If the only public signal is a name, a photo, or a school associated with a specific demographic group, the skill returns a generic fallback. Do not modify the prompt to override this. See the protected-class proxy guard.
- **Roles where mentioning specific public projects could be legally sensitive** (defense clearance roles, certain financial regulatory roles). The skill generates outreach grounded in public information; if your compliance team has restrictions on using public profile data in hiring communications, don't use this skill without legal sign-off.
- **Mass volume above 500 candidates in a single run without a human review step.** At that volume, errors compound and context-free automation feels automated. Build in a sample-review step.

## Inputs

Required:

- `candidate` — object with fields: `name` (string), `current_title` (string), `current_company` (string), `linkedin_url` (string). Minimum useful input. More fields narrow hallucination risk.
- `jd` — string or path. The job description for the role being sourced. Used to identify which candidate signals are relevant to this specific role. Without the JD, the skill cannot discriminate between a signal that matters for this job and one that does not.

Optional:

- `github_handle` — string. If provided, the skill uses public repository activity (pinned repos, recent commit language, README content) as a personalization source. More specific than LinkedIn for technical roles.
- `candidate_notes` — string. Any recruiter notes about the candidate that should inform the outreach (e.g., "referred by Jane Doe," "spoke at PyConf last year"). These are incorporated as first-priority signals.
- `personalization_config` — path to or inline contents of `references/1-personalization-config.md`. Contains the tone register, maximum message length, fallback template, and the fabrication guard thresholds. If omitted, the skill uses the defaults.
- `batch_candidates` — array of candidate objects. For batch runs, pass the full list. The skill processes each in sequence and returns a parallel array of `{candidate_id, subject_line, opening_paragraph, signal_used, confidence}` objects.

## Reference files

Load these before first use. The config file is the main point where your team's tone and guard thresholds are set.

- `references/1-personalization-config.md` — tone register, message length cap, fallback template, fabrication guard thresholds, and the protected-class proxy field list. Replace the placeholder rows with your org's actual tone guidelines and any fields your legal or HR team has flagged.
- `references/2-signal-hierarchy.md` — defines which signal types the skill prefers when multiple are available, and the minimum specificity each signal type must meet to qualify as a personalization hook. Adjust if your team sources differently.
- `references/3-sample-outputs.md` — literal examples of skill output for 3 fictional candidates (one with strong GitHub signal, one with LinkedIn-only signal, one with insufficient signal triggering the generic fallback). Use when reviewing outputs for quality and when wiring downstream sequence enrollment.

## Method

The skill runs these steps in order.

### 1. Protected-class proxy check

Before any personalization, run a field-level check against the protected-class proxy list in `references/1-personalization-config.md`. Default checks: photo URL, inferred-gender fields, fields derived from name that encode ethnicity, school names that are proxies for demographic groups (HBCUs, women's colleges) if the role selection is not affirmatively designed to use them. If the only available signals are on the proxy list, the skill returns the generic fallback without attempting personalization.

Why: even well-intentioned personalization that references a school or a community affiliation can constitute disparate treatment if it correlates with a protected class and is used selectively. The check is a hard gate, not a soft warning. Teams that want to use school affiliation for specific affirmative programs should configure that explicitly in the config file and document the legal basis.

### 2. Signal extraction

Extract usable personalization signals from the candidate record. Rank signals per the hierarchy in `references/2-signal-hierarchy.md`. Default ranking: (1) recruiter notes, (2) GitHub public repo/README content, (3) LinkedIn recent experience bullets, (4) LinkedIn headline/summary, (5) LinkedIn current title/company. Extract the top 1-2 signals that are (a) specific enough to be meaningful and (b) relevant to the target JD.

Why a hierarchy rather than "use everything": long personalization that lists every credential reads as a data dump, not as a message from a person who knows the candidate. One specific, relevant signal lands better than three generic ones. The hierarchy enforces discipline.

Minimum specificity threshold: a signal must be specific enough that the candidate would recognize themselves from it (not just their job title and company, which every recruiter can see). "You're a senior engineer at Acme" is not a signal. "Your public Redis cluster management library has 340 stars" is a signal.

If no signal meets the minimum specificity threshold, the skill immediately returns the generic fallback. It does not lower the bar to include non-specific signals.

### 3. JD relevance filter

For each extracted signal, assess whether it is relevant to the target role's JD. A strong Python background is a signal; it is not a relevant personalization hook for a design lead role. Irrelevant signals are dropped even if they are specific.

Why: signaling that you researched a candidate but then referencing something unrelated to the role they're being considered for reads as copy-paste. Worse, it signals that the recruiter read the profile but did not understand what the role needs.

### 4. Fabrication guard

Before drafting, verify that each signal used can be traced to a specific field in the input data. The skill does not infer signals that are not explicitly present. "You seem to care about distributed systems" based on two vague LinkedIn bullets is an inference, not a signal. If the candidate mentioned "distributed systems" in a project title or a specific role description, that is a signal.

Why explicit verification: the most common personalization failure is a message that sounds specific but is based on an inference that is plausible but wrong. "I noticed you've been leading the data infrastructure rebuild at Acme" — if this is based on one vague bullet and the ATS doesn't have confirmation, the candidate reads it as flattery that missed the mark. Trust breaks immediately.

### 5. Draft generation

Write the subject line and 2-3 sentence opening paragraph. Rules:

- Subject line: specific to the candidate's signal, not to the role title. "Re: your Redis management library" outperforms "Senior Engineer opportunity at [Company]" in open rate.
- Opening paragraph: reference the signal in sentence 1, connect it to why it's relevant to the role in sentence 2, and state the ask (a brief conversation) in sentence 3. Three sentences. No sell copy in the first touchpoint.
- Tone: match the register in `references/1-personalization-config.md`. Default: direct, professional, no exclamation marks, no "Hope this finds you well."

### 6. Confidence scoring

Emit a confidence score (high / medium / low) based on signal quality:

- **high** — at least one specific, JD-relevant, recruiter-note-or-GitHub-level signal available.
- **medium** — LinkedIn-level signal available; specific enough to pass the threshold but less verifiable.
- **low** — only fallback used. No qualifying signal.

Recruiters reviewing medium-confidence drafts should verify the personalization claim before sending. Low-confidence drafts are the generic fallback and require recruiter editing before send.

## Output format

Literal output the skill emits for a single candidate:

```markdown
# Personalization — Alex Rivera (alex.rivera@example.com)

**Signal used:** GitHub — pinned repo "pgvector-cache" (1,200 stars), Rust implementation
**Confidence:** high
**JD match:** Infrastructure Engineer (vector search, Rust required)

## Subject line

pgvector-cache + what we're building at [Company]

## Opening paragraph

Your pgvector-cache library — specifically the write-through caching layer you shipped in November — solves exactly the read-latency problem we're hitting at [Company] as we scale our embedding store past 100M vectors. We're hiring for the infrastructure engineer role that owns this layer, and I'd like to share what the next 12 months look like before you see another generic LinkedIn message. Worth 25 minutes?

---

_Signal source: GitHub public repo | Confidence: high | Fallback used: no_
```

For batch input, the skill emits one block per candidate separated by `\n---\n`, plus a summary table (`name | confidence | signal_type | fallback_used`).

Generic fallback output (low confidence):

```markdown
# Personalization — Jordan Lee (jordan.lee@example.com)

**Signal used:** none (fallback)
**Confidence:** low
**Reason:** No specific JD-relevant public signal found. LinkedIn profile is private or headline-only.

## Subject line

[Recruiter: edit before send — no signal available]

## Opening paragraph

I came across your background while sourcing for our [Infrastructure Engineer] role and thought your experience at [Current Company] was worth a direct note. I'd like to share what we're working on — it's a short conversation, and I'll keep it specific to what I think would interest you.

---

_Signal source: fallback | Confidence: low | Recruiter action required before send_
```

## Watch-outs

- **Fabricated personalization details.** The most common failure: a message references something the candidate never did. "I noticed you've been leading the migration to microservices at Acme" — if this was inferred from a title change, not stated explicitly, it is wrong often enough to break trust regularly. **Guard:** the skill only uses signals explicitly present in input fields and marks the signal source in the output. Recruiters review the `Signal source` line before sending. Any signal marked as inferred (not directly quoted from a field) requires human verification.
- **Protected-class proxy exposure.** A personalization hook that mentions an HBCU, a women-in-tech community, or a nationality-coded program can constitute disparate treatment if not universally applied. **Guard:** the skill checks the protected-class proxy list from `references/1-personalization-config.md` before generating any personalization. If a signal is on the list, it is not used. The list is configurable; your legal or HR team should review it annually.
- **Generic fallback blindness.** Recruiters under quota pressure send the generic fallback at low confidence without editing it. The fallback contains placeholder text ("[Recruiter: edit before send]") that occasionally ships verbatim. **Guard:** the skill marks low-confidence output with `Recruiter action required before send` in a visible header. Build a review step into the sequence enrollment workflow that blocks enrollment for low-confidence drafts without a human edit.
- **Signal staleness.** A GitHub repo that was active 3 years ago is not a current signal. A LinkedIn role that ended 18 months ago is not a current-context signal. **Guard:** the skill applies a recency filter — signals older than 24 months are excluded unless the candidate's most recent activity references them. The filter threshold is configurable in `references/1-personalization-config.md`.

# Personalization config — TEMPLATE

> Replace this file's contents with your team's actual tone guidelines,
> guard thresholds, and protected-class proxy field list.
> The candidate-personalization skill reads this file before every run.

## How the skill reads this file

- **Tone register** — defines the voice guidelines applied when drafting messages. Replace the defaults with your employer brand guidelines.
- **Message length cap** — the skill truncates opening paragraphs to this many characters. Adjust based on the channels your team uses.
- **Fallback template** — the generic message the skill emits when no qualifying signal exists. Edit so it reflects your team's standard opening.
- **Fabrication guard thresholds** — the minimum specificity a signal must meet before use. The defaults are conservative; lower them at your own risk.
- **Protected-class proxy field list** — fields the skill refuses to use as personalization hooks. Review annually with your legal or HR team.
- **Signal recency window** — signals older than this threshold are excluded.

## Tone register

```
register: professional-direct
exclamation_marks: forbidden
opener_banned_phrases:
  - "Hope this finds you well"
  - "I came across your profile"  [too generic — replace with specific signal]
  - "We're a fast-growing company"
  - "Exciting opportunity"
closing_ask: "Worth 25 minutes?" or "Happy to share more if the timing is right."
```

Replace the above with your org's tone guidelines. If your employer brand is more conversational, adjust the register accordingly — but keep `exclamation_marks: forbidden` unless your brand explicitly uses them.

## Message length cap

```
subject_line_max_chars: 60
opening_paragraph_max_chars: 500
```

## Fallback template

Used when no qualifying signal is found. Edit to match your standard outreach voice.

```
subject: [Recruiter: edit before send — add candidate-specific signal]
opening: I came across your background while sourcing for our {role_title} role and thought your experience at {current_company} was worth a direct note. I'd like to share what we're working on — it's a short conversation, and I'll keep it specific to what I think would interest you.
```

## Fabrication guard thresholds

```
minimum_signal_specificity: candidate-identifiable
  # Signal must be specific enough that the candidate recognizes themselves from it
  # (not just their job title and company).
  # Examples of QUALIFYING signals:
  #   - A named public project or repo
  #   - A specific talk or publication title
  #   - A named company initiative mentioned in their public profile
  # Examples of NON-QUALIFYING signals:
  #   - "senior engineer at Acme" (visible to all recruiters)
  #   - "background in distributed systems" (inferred from role titles)
  #   - "worked at FAANG companies" (aggregated, not specific)

inference_allowed: false
  # The skill does not infer signals. Only use fields explicitly present
  # in the input data. "You seem to care about X" based on inferred themes
  # is not a qualifying signal.

recency_window_months: 24
  # Signals from activity older than 24 months are excluded unless
  # the candidate's recent activity explicitly references them.
```

## Protected-class proxy field list

The skill refuses to use these fields as personalization hooks. Review and extend this list annually with your legal or HR team.

```
blocked_fields:
  - photo_url
  - inferred_gender
  - name_derived_ethnicity_signals
  - nationality_inferred
  - religious_affiliation_signals
  - disability_signals
  - age_signals
  - marital_status_signals
  - pregnancy_signals

blocked_school_signals:
  # Schools that function as demographic proxies when used selectively.
  # This list does NOT mean these schools are impermissible in all contexts —
  # it means the skill will not use them as personalization hooks without
  # explicit legal/HR sign-off for an affirmative program.
  - historically_black_colleges_and_universities  [HBCU classification]
  - single_gender_institutions
  - religiously_affiliated_institutions_when_used_as_faith_proxy
```

**Important:** this list blocks selective use of these signals. If your organization has a documented affirmative recruitment program that intentionally uses school affiliation (e.g., an HBCU partnership), configure that in a separate affirmative-program section with the legal basis documented, and remove the relevant item from `blocked_school_signals`. Do not remove items without legal review.

## Last edited

{YYYY-MM-DD} — by {TA/HR/Legal reviewer name}

# Signal hierarchy — TEMPLATE

> Defines which signal types the personalization skill prefers when multiple
> signals are available for a candidate, and the minimum specificity each
> type must meet to qualify as a personalization hook.
> Adjust the ranking if your team sources differently or prioritizes different
> signal types for different role families.

## How the skill reads this file

- The skill evaluates available signals in the order listed and uses the first 1-2 that (a) meet the minimum specificity for that tier and (b) are relevant to the target JD.
- Lower-tier signals are only used when higher-tier signals are absent or do not meet the relevance filter.
- If no signal in any tier qualifies, the skill returns the generic fallback.

## Signal hierarchy

| Tier | Signal type | Source | Minimum specificity | Notes |
|---|---|---|---|---|
| 1 | Recruiter notes | Sourcer input | Any recruiter-observed context: referral, event interaction, previous conversation. | Highest priority — recruiter context is always more specific than public data. |
| 2 | GitHub pinned repo | GitHub public profile | Named project with ≥1 commit in the last 24 months AND a README that describes scope. | Stars/forks alone are not sufficient — the work must be described. |
| 3 | GitHub recent commit language | GitHub public profile | Specific language or framework used in commits in the last 12 months. | Only qualify if the language/framework is explicitly required in the JD. |
| 4 | LinkedIn publication or talk | LinkedIn profile | Named article, talk title, or podcast episode. Must have a title, not just "published an article." | Verify the title is real before using — hallucination risk on inferred publication names. |
| 5 | LinkedIn specific project | LinkedIn profile | Named project or product at a named company, not just a role title. | "Led the Checkout v2 migration at Stripe" qualifies; "worked on payments" does not. |
| 6 | LinkedIn recent role description | LinkedIn profile | Specific, named responsibility or metric from a current/most recent role bullet. | "Led 12-person team to 99.9% uptime" qualifies; "led teams" does not. |
| 7 | LinkedIn headline or summary | LinkedIn profile | Specific technical claim or framing in the headline/summary. | Only qualifies if the claim is specific enough that it distinguishes the candidate from their role category. |

## Role-family adjustments

Adjust which tiers qualify based on role type:

| Role family | Notes |
|---|---|
| Engineering / Technical | Tier 2-3 (GitHub) carries the highest signal quality. Prefer over LinkedIn. |
| Design / Creative | LinkedIn portfolio link or Behance/Dribbble URL (if present) ranks above GitHub. Add as Tier 1.5. |
| Sales / RevOps | Recruiter notes (Tier 1) and LinkedIn named deal or quota signals (Tier 5-6) are most relevant. GitHub rarely applies. |
| People / HR | LinkedIn publications and conference talks (Tier 4) are common and high-quality for this function. |
| Legal | Publications or named regulatory experience (Tier 4-5) are highest quality. GitHub almost never applies. |

## Relevance filter (applied after hierarchy)

Even high-tier signals are dropped if they are not relevant to the target JD. After extracting the top 1-2 signals from the hierarchy, the skill asks: "Would this candidate recognize that this signal was selected because of this specific role, or would it read as generic research?" If the answer is "generic research," drop it and move to the next tier.

## Last edited

{YYYY-MM-DD} — by {TA team member name}

# Sample outputs — for review calibration and sequence wiring

> Three literal examples of what the skill emits for fictional candidates.
> Use these when calibrating recruiter review quality, when building acceptance
> criteria for the sequence enrollment step, and when wiring downstream parsers.

## Output 1 — high confidence (GitHub signal)

```markdown
# Personalization — Alex Rivera (alex.rivera@example.com)

**Signal used:** GitHub — pinned repo "pgvector-cache" (1,200 stars), Rust implementation, last commit 2025-11-08
**Confidence:** high
**JD match:** Infrastructure Engineer (vector search, Rust required)

## Subject line

pgvector-cache + what we're building at [Company]

## Opening paragraph

Your pgvector-cache library — specifically the write-through caching layer you shipped in November — solves exactly the read-latency problem we're hitting at [Company] as we scale our embedding store past 100M vectors. We're hiring for the infrastructure engineer role that owns this layer, and I'd like to share what the next 12 months look like before you see another generic recruiter message. Worth 25 minutes?

---

_Signal source: GitHub public repo (pgvector-cache) | Confidence: high | Fallback used: no_
```

## Output 2 — medium confidence (LinkedIn-only signal)

```markdown
# Personalization — Priya Nair (priya.nair@example.com)

**Signal used:** LinkedIn — role bullet at DataCo: "Rebuilt the real-time feature pipeline handling 2M events/sec, reducing P99 latency from 800ms to 140ms"
**Confidence:** medium
**JD match:** Staff Data Engineer (streaming pipelines, Kafka, latency reduction)
**Recruiter note:** Verify this bullet is current — LinkedIn role end date: present, but role title changed 8 months ago.

## Subject line

The DataCo pipeline work + our streaming infrastructure role

## Opening paragraph

The 2M events/sec latency reduction you described in your DataCo role is the exact problem class we're working on — our Kafka-based pipeline is hitting comparable bottlenecks at 3M events/sec and we're rebuilding the consumer layer. I'm hiring for a staff engineer role that owns this work, and I'd rather send you the architecture diagram than a job description. Worth a 20-minute call?

---

_Signal source: LinkedIn role bullet (DataCo) | Confidence: medium | Recruiter review required: verify bullet is current_
```

## Output 3 — low confidence (generic fallback)

```markdown
# Personalization — Jordan Lee (jordan.lee@example.com)

**Signal used:** none (fallback)
**Confidence:** low
**Reason:** LinkedIn profile is private (headline and current company only visible). No GitHub handle provided. No recruiter notes.

## Subject line

[Recruiter: edit before send — no signal available]

## Opening paragraph

I came across your background while sourcing for our Infrastructure Engineer role and thought your experience at CloudBase was worth a direct note. I'd like to share what we're working on — it's a short conversation, and I'll keep it specific to what I think would interest you.

---

_Signal source: fallback | Confidence: low | Recruiter action required before send_
```

## Field contract for parsers

For downstream sequence enrollment, these are the stable output fields:

- `candidate_id` — pass-through of the input `candidate.email` or an ID field you supply
- `subject_line` — string, ≤ 60 characters
- `opening_paragraph` — string, ≤ 500 characters
- `signal_used` — string describing the signal (or "fallback")
- `signal_source` — enum: `github` / `linkedin_bullet` / `linkedin_headline` / `recruiter_notes` / `fallback`
- `confidence` — enum: `high` / `medium` / `low`
- `fallback_used` — boolean
- `recruiter_review_required` — boolean (true for medium and low confidence)
- `review_note` — string or null (present when `recruiter_review_required: true`)

## Batch summary output

For a batch of N candidates, the skill prepends a summary table before the per-candidate blocks:

```markdown
# Batch summary (24 candidates)

| Name | Confidence | Signal type | Fallback | Review required |
|---|---|---|---|---|
| Alex Rivera | high | github | no | no |
| Priya Nair | medium | linkedin_bullet | no | yes |
| Jordan Lee | low | fallback | yes | yes |
| ... | ... | ... | ... | ... |

---
```