expand

Expand

Mines the LinkedIn network of an existing pipeline candidate to surface similar profiles, then enriches and assesses every newly discovered candidate. This is the user-facing wrapper around the internal expand agent — useful when the user has a specific seed in mind ("expand from Yael Cohen") rather than running a full session.

Data directory: ~/.talent-scout/

Input: A candidate name (or LinkedIn slug) from the user.

Output: A summary of newly discovered candidates with tiers and the most promising leads ranked. The user decides whether to deep-dive any of them.

Why this exists separately from orchestrator: When the user names a seed explicitly, they want focused network mining around that one candidate — not a multi-phase session plan. This skill resolves the name, dispatches the expand agent on that single seed, and runs the standard enrich + assess pipeline on whatever it returns.

Why two-step enrich then assess: Same rationale as scout. Enrichment is mechanical OSINT gathering (cheap to parallelize). Assessment requires scoring judgment on complete data. Separating them means assess always works with full OSINT context.

Dependencies

• expand agent — network mining from a seed candidate (returns new_candidate_ids for caller to enrich + assess). Sonnet model.
• enrich agent — OSINT enrichment in scout mode.
• assess agent — single-candidate scoring + thesis. Sonnet model.
• Scout MCP server — read_meta with name "candidates_index.json" — for name → id resolution.
• Scout MCP server — rank_candidates — to order the new candidates by quality.

---

Phase 1: RESOLVE SEED

Step 1: Parse the user's input

Extract the seed candidate's name (or slug) from the user's message. Common forms:

• "expand from Yael Cohen"
• "find similar to Eli Cohen"
• "people like Noam Nissan"
• "who's in Ron Shemesh's network"
• "mine Maya Levi's connections"

If the user gave a LinkedIn slug directly (e.g. ron-shemesh-0b068792), skip to Step 3.

Step 2: Resolve name → candidate id

Call read_meta with name "candidates_index.json". Search the index for a candidate whose name matches the parsed input (case-insensitive, allow partial matches on first or last name).

• Zero matches: Stop and tell the user no candidate by that name exists in the pipeline yet. Suggest scouting first (/scout) or asking the orchestrator to onboard them as a seed. Do not silently fall through to a cold LinkedIn search — that's not what expand does.
• Exactly one match: Use that candidate's id. Confirm to the user: "Expanding from {name} ({id})..."
• Multiple matches: List the candidates with their tier, current company, and id, and ask the user which one they meant. Wait for the answer before continuing.

Step 3: Validate the seed has expansion-ready data

The expand agent needs a linkedin_urn on the seed. The agent itself validates this and will refuse if it's missing — you don't need to pre-check, but if you already know the candidate has no URN (e.g. the index entry shows linkedin_urn: null), tell the user the seed needs a profile fetch first and stop.

---

Phase 2: DISPATCH EXPAND AGENT

Step 4: Dispatch the expand subagent

Agent(subagent_type: "talent-scout:expand", model: "sonnet", prompt: "Expand from candidates: {id}")

Sonnet is required per project convention (and the agent's frontmatter pins it). Wait for the agent to return.

The expand agent will:

• Call get_similar_profiles on the seed's URN ("People also viewed").
• Optionally branch into company-alumni discovery if the thesis calls out the seed's affiliations.
• Triage discovered profiles via triage_profiles.
• Extract and save_candidate every VISIT, applying server-side dedup.
• Return a summary including new_candidate_ids — the slugs of candidates newly added to the pipeline.

If the agent returns zero new candidates, report that to the user and stop. Network already mined, or every discovered profile was a duplicate or auto-SKIP.

---

Phase 3: ENRICH + ASSESS (parallel)

The expand agent intentionally does not score. It hands back the new candidate ids so this skill can run the standard pipeline on them.

Step 5: Dispatch enrich agents in parallel

For each id in new_candidate_ids, dispatch an enrich agent in scout mode. Dispatch them all in a single batch — they're independent.

Agent(subagent_type: "talent-scout:enrich", prompt: "Enrich candidate '{id}' in scout mode")

Wait for every enrich agent to return before proceeding. If any fails (returns {ok: false, code, message}), surface the per-candidate failure and continue with the rest.

Step 6: Dispatch assess agents in parallel

After enrichment completes for the batch, dispatch assess agents. Dispatch them all in a single batch — they're independent.

Agent(subagent_type: "talent-scout:assess", model: "sonnet", prompt: "Assess candidate ID '{id}'")

Sonnet is required per project convention. Wait for every assess agent to return. Collect {id, name, tier, archetype, score_summary} from each. Surface any per-candidate failures and continue.

---

Phase 4: RANK + PRESENT

Step 7: Rank the new candidates

Call rank_candidates to produce shortlist-aware ordering across the newly assessed batch.

Step 8: Present results to the user

Report:

• How many new candidates were discovered (and how many were duplicates / auto-skipped, if useful context).
• Tier breakdown of the new batch ("2 T1, 3 T2, 4 T3").
• The most promising leads, with one-line reasoning grounded in the thesis (which readiness or credibility signal they hit, which exemplar they resemble).
• Optionally, the top candidates that would be good deep-dive targets — but do not auto-dispatch deep-dive. The user decides.

If the batch is small (one or two candidates), present each individually with their score summary. If larger, group by tier and call out standouts.

---

Closing condition

This skill expands from a single named seed and runs enrich + assess on whatever the expand agent surfaces. It does not chain into deep-dive, outreach, or further expansion — those are separate user decisions. If the user wants to keep going (deep-dive a result, expand from one of the new candidates), they invoke the next skill explicitly.

If the seed cannot be resolved (Phase 1), or the expand agent returns zero new candidates (end of Phase 2), stop and report cleanly. Do not fall back to a cold LinkedIn search — expand is specifically for network mining around a known seed.