> ## Documentation Index
> Fetch the complete documentation index at: https://support.metaview.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# Sourcing Copilot
> Run Sourcing and Application Review from Claude, Slack, or Teams — search kickoff, a daily shortlist loop, and confirmed handoffs to your ATS and sequences.
The sourcing agent works best when someone calibrates it well and keeps the review loop tight. This skill turns a JD into a sharp kickoff brief, delivers a daily shortlist where replying “1 and 4, not 3” in Slack becomes recorded feedback on those candidates' profiles, and hands your selections to your ATS and sequences — with a confirmation gate on everything irreversible.
**Requires:** [Sourcing](/recruiting-platform/ai-sourcing). Inbound triage additionally requires [Application Review](/recruiting-platform/application-review). The Slack/Teams loop requires that connector.
## The one thing to know about the agent
The sourcing agent is **asynchronous** — minutes, sometimes 10–15, per response. The skill is built around this:
* It never messages the agent to ask what the data already answers. Search criteria, calibration state, and feedback history come from a direct read; candidates and metrics likewise. All instant.
* It messages the agent only to make it *do* something: start a search, refine criteria, search again after your feedback.
* While waiting, it says what it's waiting for and roughly how long — rather than sitting in a silent loop.
## Five workflows
The skill checks for an existing search on the role first — refining beats duplicating, because split feedback calibrates neither.
It then asks for the JD, or the recorded intake call, or spends two minutes interviewing you: mission, location and visa, three to five testable must-haves, seniority band, target companies, hard exclusions.
It composes a **search brief, not a JD dump**. Long pasted JDs calibrate worse and can hit message limits.
When the proposed Ideal Candidate Profile comes back, the skill presents it to you and locks it in **before** large batches arrive. Ten minutes here saves hours of reviewing miscalibrated packs.
The flagship. The candidates that best match your criteria arrive in Slack or Teams each morning; your replies become recorded feedback.
**Setup asks exactly three things:** which search, where and what time, and how many per day (default 10).
Each candidate appears as a numbered block — what matches your criteria, what to check, and a profile link. One footer line explains the reply format: `1, 4 yes · 3 no, too junior · rest maybe`.
**Two guards make this survivable:**
* **No repeats.** Anyone already given feedback, or shown in a previous digest without a reply, is excluded. Yesterday's unanswered names go in a short “still waiting on” footer instead of being re-listed as new.
* **Pool-empty guard.** If fewer than the requested number remain, it sends what exists and says the pool is running dry — rather than padding or silently sending three of ten.
Your reply is recorded as Yes / Maybe / No with your stated reason on every No and Maybe. That lands on the candidate's profile in Metaview, visible to the team.
Two destinations, both gated:
* **To your ATS** — the skill confirms the job, the stage, and the named candidates before posting. Posting is irreversible from Metaview, and the agent's reasoning posts as a profile note.
* **To outreach** — it checks the sequence is enabled, shows you its steps, lists exactly who would enter which sequence, and waits for an explicit yes. This emails real people.
Ask for a deep dive before outreach — a prior rejection in the ATS is worth knowing about.
Sourcing analytics grouped by user, search, week, or mode.
The three reads that matter:
* **Acceptance-rate trend per search** — is calibration improving?
* **Candidates without feedback** — the silent killer; reviews piling up unactioned
* **Searches per user** — adoption
Non-admins see their own data.
For [Application Review](/recruiting-platform/application-review).
The skill always reads the review's current state first: active ICP, band distribution, pending drafts, and whether a rerank is in flight (candidate lists are unavailable during one).
It then lists the undecided candidates in the highest-matching bands, each with the reasoning attached.
Bands are coarse by design. There is no hidden numeric ranking underneath, and the skill will not invent one.
Changing the ICP is **live** — a full replace that reranks everyone immediately. The skill shows you before and after and waits for explicit approval.
## Safeguards built into this skill
* **Confirmation before anything irreversible or externally visible:** posting to your ATS, adding people to a live sequence, or replacing an Application Review ICP.
* **Never bulk-submits feedback you haven't seen.** It can propose verdicts for a large unreviewed pool once you've hand-reviewed a seed of 10–15 — but always shows them for approval first.
* **Ambiguity gets a question, not a guess.** A reply like “the first one's interesting” prompts a one-line clarification rather than an assumed verdict.
* **The agent doesn't refine itself.** Refinement is an explicit step you trigger, with a summary of the pattern in your feedback.
* **Credit-aware.** Candidates cost credits on most plans; the skill checks remaining credits before requesting large batches and warns when low.
## Install this skill
Copy the following into a `SKILL.md` file and add it to your AI client. See [installation steps](/ai-skills/overview#install-a-skill).
```markdown SKILL.md expandable theme={null}
---
name: metaview-sourcing-copilot
description: >
Run Metaview's sourcing agent and Application Review like a power user — from Claude,
Slack, or Teams. Trigger on "kick off a search for this role", "here's the JD, start
sourcing", "send me 10 candidates a day in Slack", "3 and 7 are great, 4 is too junior"
(feedback on a shortlist), "review the new candidates", "push the ones I said yes to into the ATS",
"add them to the outreach sequence", "how is sourcing performing", "triage the new
applicants", or "which inbound applications are worth reviewing". Covers search kickoff
and calibration, the daily shortlist-to-Slack/Teams loop where replies become recorded
candidate feedback, ATS and sequence handoffs, sourcing analytics, and inbound
Application Review triage.
---
# Metaview Sourcing Copilot
The sourcing agent is strongest when someone calibrates it well and keeps the loop tight. This skill is that someone: it turns a JD into a sharp kickoff brief, delivers a daily shortlist where saying "1 and 4, not 3" in Slack becomes recorded feedback on the candidates' profiles, and hands the candidates you selected to your ATS and sequences — with confirmation gates on everything irreversible.
## Why this is powerful
Sourcing tools die when reviewing candidates becomes a chore you do in another tab. This inverts it: candidates come to where you already work (Slack/Teams), feedback costs one short reply, and every reply improves calibration because it lands on the candidate's profile as structured feedback — not as a comment lost in a thread. The loop that usually decays after week one runs itself.
## The one thing to know about the agent
The sourcing agent is **asynchronous** — minutes, sometimes 10-15, per response. So:
- **Never message the agent to ask what the data already answers.** ICP, calibration state, feedback history → `get_search_details`. Candidates found → `list_sourcing_candidates`. Metrics → `get_sourcing_analytics`. All instant.
- Message the agent (`send_sourcing_message`) only to make it DO something: start a search, refine requirements, search again after feedback.
- After sending, poll `get_sourcing_messages` — `busy` means working; `idle`/`waiting` means done or awaiting input. Say what you're waiting for and how long it typically takes; never sit in a silent loop.
## Operating rules
- Tool names may carry a connector prefix; match on the trailing name. Refer to searches by title and candidates by name — no internal UUIDs in output.
- Candidates cost credits on most plans — check remaining credits (returned by `list_sourcing_candidates`) before requesting big batches; warn when low.
- **Confirm before irreversible or externally-visible actions:** posting to the ATS (irreversible from Metaview), adding candidates to a live sequence (emails real people), replacing an Application Review ICP (instant rerank).
## Workflow 1 — Kick off a search
1. `get_user_context` once per session. `list_sourcing_searches` first — if this role already has a search, refine it, don't duplicate.
2. **Ask for the JD** (paste is fine) or the intake call ("Role Intake" conversation type via `search_conversations`); failing both, interview the user for 2 minutes: mission, location/visa, 3-5 testable must-haves, seniority band, target companies, hard exclusions.
3. Compose the kickoff message as a **search brief, not a JD dump** (long pasted JDs calibrate worse and can hit message limits): mission in one line · location/remote + visa · must-haves · strong signals to rank by (not exclude on) · seniority band · target/feeder companies · exclusions · "a profile that meets these criteria looks like… / a near-miss on these criteria looks like…".
4. `send_sourcing_message` (no `search_id`, `mode="source"`). When polling shows the proposed ICP, present it to the user, apply corrections, and lock it **before** big batches arrive — ten minutes here saves hours of miscalibrated packs.
## Workflow 2 — The daily shortlist loop (the flagship)
The candidates that best match your criteria arrive in Slack or Teams every morning; replies become recorded feedback; the search calibrates better each week. Set it up once:
**Setup — ask exactly these:**
1. Which search(es)? (`list_sourcing_searches` to offer the active ones)
2. Where? Slack channel or Teams chat (requires that connector — if absent, run the same loop here in chat) — and what time.
3. How many per day? Default **10**.
**Composing each digest:**
1. Pull candidates with `list_sourcing_candidates(feedback_status="unreviewed", detail_level="summary")`.
2. **No-repeats guarantee:** exclude anyone with feedback already recorded AND anyone shown in a previous digest without a response (keep yesterday's unanswered names in a short "still waiting on" footer line instead of re-listing them as new). Duplicates are the #1 reason these digests get muted.
3. **Pool-empty guard:** if fewer than the requested number remain, send what exists, say the pool is running dry, and message the agent for a fresh pack ("Search again using my recorded feedback") — don't pad with lower-matching profiles or silently send 3 of 10.
4. Format, one numbered block per candidate — scannable in a feed:
> **3. Ana Kovač** — Senior O2C Analyst @ Scandit · Warsaw
> Matches: 5y SaaS order-to-cash · Salesforce+NetSuite hands-on · led co-term automation
> Check: no explicit AI-tools mention
> [LinkedIn](url)
5. One footer line: "Reply with numbers — e.g. `1, 4 yes · 3 no, too junior · rest maybe`. Reasons on the no's sharpen the criteria."
**Processing replies (the part that makes it real):**
1. Parse the reply — numbers map to today's digest; a reply names *this* digest's numbering, so keep the mapping (post it in-thread if needed). Interpret natural phrasing: "love 2 and 5", "3 is too agency-side", "rest are maybes".
2. Record via `give_sourcing_feedback` in bulk: YES/MAYBE/NO with the user's stated reason as `text` on every NO and MAYBE. This lands on the candidate's profile in Metaview — visible to the whole team, feeding calibration.
3. Confirm back in one line: "Recorded: 2 yes, 1 no (too junior), 7 maybe. 14 unreviewed remain."
4. Ambiguous reply ("the first one's interesting")? Ask a one-line clarification rather than guessing a verdict.
5. **The agent does not refine itself.** After ~10-15 recorded verdicts (or weekly), `send_sourcing_message`: "Search again using my feedback" + a one-line pattern summary ("all NOs were agency-side; in-house only").
**Scaled calibration (power move):** once the user has hand-reviewed a seed of ~10-15, offer to review the remaining unreviewed candidates against the ICP + their seed reasoning and propose provisional criteria-match notes for each — shown for your approval before anything is recorded. Never bulk-submit feedback the user hasn't seen.
## Workflow 3 — Hand off your selections
- **To the ATS:** `list_ats_jobs(query=...)` → optionally `list_ats_stages` → confirm job, stage, and the named candidates → `post_sourcing_candidates_to_ats` (≤50/call, async ~2 min, irreversible from Metaview; the agent's reasoning posts as a profile note). Relay `posting_disabled_reason` if set.
- **To outreach:** `list_sequences` → check `is_enabled`, steps, reply stats → list exactly who enters which sequence → explicit yes → add.
- Deep-dive on request: `fetch_candidates` (profile + ATS history — a prior rejection is worth knowing before outreach).
## Workflow 4 — Sourcing performance
`get_sourcing_analytics`: metrics `searches`, `candidates`, `feedback`, `accepted`/`rejected`/`maybe`, `acceptance_rate`, `candidates_without_feedback`, `scheduled_searches`, `seat_utilization` (admin); group by user/search/week/mode. The reads that matter: acceptance-rate trend per search (calibration improving?), `candidates_without_feedback` (the silent killer — reviews piling up unactioned), searches per user (adoption). Non-admins see their own data. Short narrative + numbers; artifact dashboard on request.
## Workflow 5 — Inbound triage (Application Review)
1. `list_application_reviews(search_term="")` → **always** `get_application_review_details` first: active ICP, fit-band distribution (great/good/okay/no_evidence/poor), pending drafts, rerank in flight (if so, candidate lists are unavailable — wait).
2. Undecided candidates in the highest-matching bands: `list_application_review_candidates(fit_filter="great"` then `"good", decision_filter="undecided")` — each with the agent's reasoning. The band is a coarse grouping by design; there is no hidden numeric ranking, so don't invent one.
3. Deep-dive: `fetch_candidates` with candidate ID + `application_review_id`.
4. **Moving the bar:** if the distribution looks wrong (nothing "great", everything "okay"), propose a sharper ICP. `update_application_review_icp` is **live** — full replace + instant rerank of everyone. Show before/after, get explicit approval, pass `base_version` from the details call, poll until the rerank completes. Reversible afterwards via version restore.
5. **Fold into the daily digest:** the morning message can carry two sections — sourced candidates (Workflow 2) and new great/good-band applicants, same numbered-reply feedback pattern, with AR outputs relayed as criteria-match summaries for the user to review and decide on.
## Edge cases
- **Search returns poorly-matching candidates repeatedly:** `get_search_details` — low acceptance + inconsistent NO-reasons means the ICP is the problem. Fix the ICP in one consolidated message, not drip-fed complaints.
- **Agent is `waiting` on a question:** surface it verbatim; relay the user's answer — never answer for them.
- **`phase: error`:** report it, retry the last message once, then treat as a support issue.
- **Two searches for the same role:** propose archiving one; split feedback across ICPs calibrates neither.
## Example invocations
- "Here's the JD for our Warsaw O2C analyst — kick off a search and show me the ICP first."
- "Every morning at 9, send the top 10 from the Backend search to #eng-sourcing. I'll reply with numbers."
- "2 and 6 yes, 4 no — feels too agency-side. Rest maybe."
- "Push everyone I said yes to this week into Greenhouse and the outreach sequence."
- "Which new applicants for Engagement Manager should I look at today?"
```
## Related
How to use Sourcing responsibly, including what the agent does and doesn't do.
Set up the search as part of a full role launch from the intake call.