---
name: metaview-interview-intelligence
description: >
Answer questions across hundreds of interviews at once using Metaview AI fields, and turn
the results into charts, dashboards, and saved reports. Trigger on any cross-interview
question — "why are candidates declining offers", "what are candidates saying about our
brand", "average salary expectations for engineers this quarter", "which competitors keep
coming up", "build me a dashboard of candidate motivations", "how consistent are our
screens" — or when the user wants to extract a specific data point ("visa status",
"reason for leaving", "AI tool usage") from many conversations. Includes the full
design-calibrate-iterate loop so the numbers can be trusted before anyone presents them.
---
# Metaview Interview Intelligence
Your interviews already contain the answers — comp expectations, decline reasons, competitor mentions, candidate concerns, market signal. This skill extracts them at scale: it designs an AI field (a question answered independently against every conversation), calibrates it on real transcripts until it's trustworthy, then aggregates into an answer, a chart, or a live dashboard.
**Who it's for:** TA leads, recruiting ops, and anyone reporting to leadership.
**Metaview products needed:** AI Notetaker + Reports/AI fields (paid plan).
## Why this is powerful
Your interviews are a market dataset that's genuinely *yours* — hundreds of hours of candidates saying why they're leaving, the compensation they've told us they expect, who else they're talking to, what worries them about you. Surveys sample it; exit interviews get it too late; this reads all of it. And because every number ships with its calibration audit and its n, it holds up to scrutiny.
## Operating rules
- Tool names may carry a connector prefix; match on the trailing name. Never surface internal field/report UUIDs — use names and URLs.
- **Never bulk-read transcripts to answer a scale question.** 1-5 conversations → read transcripts; 5-20 → read `default:summary`; 20+ → AI fields, always. A 1-hour transcript is ~10-15K tokens.
- **Never present uncalibrated numbers as findings.** A new AI field gets audited on real conversations before its aggregates are shown (Step 5). Until then, label everything "draft".
- Cohort outputs anonymise candidates by default (patterns, not names). Name people only if the user explicitly asks and has a legitimate reason (e.g. their own pipeline follow-ups).
- Don't invent findings to fill space. "The data is thin here" is a valid result — with the count that proves it.
- Confirm with the user before creating or updating an AI field (name, question, type) — fields are shared workspace objects and updating one clears its existing values everywhere.
## Workflow
### Step 1 — Sharpen the question
Call `get_user_context` first (workspace, paid plan, data access — scope caveats belong in the output).
Turn the ask into: **population** (which conversations: stage, department, role, time window) × **data point(s)** (what exactly to extract per conversation) × **cut** (grouped by what: time, interviewer, department, source). If the request is broad ("analyse our interviews"), propose 2-3 specific questions and let the user pick.
### Step 2 — Scope the population and run the volume check
- Discover filterable fields with `list_fields(search_term=...)` — **always pass a search_term**; the unfiltered list can be enormous. ATS-synced fields (department, job, stage) appear alongside `default:` fields.
- Resolve filter values with `list_field_values` (e.g. department names, interviewer IDs). Date filters must be dicts: `{"scope": "relative", "value": -2592000}` (seconds) or `{"scope": "absolute", "value": "YYYY-MM-DD"}`.
- Count the population with `group_conversations` (single group or grouped) — don't fetch rows just to count.
- Volume check before building anything: **under ~10 conversations** — tell the user it'll be thin; offer to widen the window or just read them directly (skip AI fields entirely). **10-50** — sweet spot. **Hundreds+** — great for trends; consider whether one department/quarter answers the question faster. Useful filters: exclude very short calls (`default:call_duration` greater_than ~10 minutes) to drop no-shows and ghost sessions.
### Step 3 — Reuse before creating
`list_fields(search_term="<topic>")` to check whether a field for this data point already exists (Metaview ships some; workspaces accumulate more). Reuse or improve in place rather than duplicating. Only then design new fields.
### Step 4 — Design the AI field(s)
One field = one question, answered against one transcript in isolation (no resume, no other calls, no other fields). Valid `value_type`: `single_line_text`, `long_text`, `list`, `number`, `currency`, `date`, `boolean`, `json`. Split compound asks into 2-3 focused fields rather than one catch-all.
Battle-tested prompt rules — bake all that apply into the prompt body:
1. **Closed value sets** for categoricals: "Return exactly one of: X, Y, Z, Not Discussed" — always include a fallback label, and tie-breakers ("when in doubt, the more conservative label; when in doubt vs Not Discussed, Not Discussed").
2. **High bar for booleans**: define what counts as TRUE *and* what does not, with a worked example each way. "When in doubt, FALSE."
3. **Strict domains for lists**: explicit INCLUDE categories with examples, explicit EXCLUDE list naming the common leaks, "if borderline, do not include", "do not invent specifics the candidate didn't name", empty list as fallback.
4. **Candidate vs interviewer separation**: state whose statements the field measures and to ignore the other side. (Interviewer-behaviour analysis is its own skill — metaview-interviewer-coaching.)
5. **No inference from job titles or company names** — only what was actually said.
6. **Numbers stay simple**: count one well-defined thing; "Return only the number." Beware: `0` is ambiguous (genuinely zero vs not discussed) — for "how much/many if mentioned" questions prefer a text field with an explicit "Not discussed" fallback, or pair the number with a boolean "was this discussed".
7. **Plain-text output**: no markdown, no preamble; hard length caps for narrative fields ("1-3 sentences, max 60 words").
8. Ignore Metaview/notetaker consent preambles; return the fallback when no candidate is present (internal calls).
Present the field plan (name, type, one-line question) and get a go-ahead. Create with `create_ai_field`. The tool auto-improves prompts; pass `skip_improvement=true` only when you've deliberately hand-tightened constraints it might loosen.
### Step 5 — Calibrate before you trust
1. Pull a sample: `search_conversations` over the population with `fields=[<the new AI field ids>]`, limit ~10-15, stratified across the population's variety (stages, interviewers, roles). Requesting the field triggers processing — results can take ~30-60s; re-query if values are missing.
2. Audit: for ~8-12 of them, read the transcript (or summary for long ones) and judge each field value Correct / Borderline / Wrong. Empty/fallback values are CORRECT when the topic genuinely didn't come up.
3. If there are systematic misses (same failure shape on 2+ rows): fix the prompt via `create_ai_field(field_id=...)` — this clears all values and reprocesses on next query — and re-audit. Common fixes: add EXCLUDE examples, raise the substantive-engagement bar ("a one-word 'yes' doesn't count"), add the missing fallback, separate candidate/interviewer signal.
4. Ship at roughly ~90% clean with no unfixed systematic error. Report the calibration honestly in the output ("audited on 12 conversations, 11 clean; edge case: X").
### Step 6 — Aggregate and answer
**Completeness gate first:** AI-field values compute asynchronously, and there's a processing cap per request (~hundreds of fresh evaluations). Before aggregating, verify the population is actually processed — sample rows for empty values, and on large populations page through in batches to warm them. Aggregating a half-processed column silently reports "Not discussed" for conversations that were never analysed; if >~20% of values are pending, wait and re-query rather than present skewed numbers. For populations in the many-hundreds, generate the columns from the report in the Metaview app first, then aggregate here.
- Distributions/breakdowns/counts: `group_conversations` with `group_by` (the AI field or a cut like interviewer/department) + optional `metrics`.
- Trends over time: `get_chart_data` with `chart_inputs=[{metric_id, function, interval}]`. Metric IDs come from `list_fields` (`aggregation:...`) — field IDs go in filters/group_by, metric IDs in metrics/chart_inputs; don't mix. Talk-time / question-count / minutes-late metrics require `metric_arguments: {"scope": "internal"|"external"}`.
- Per-row detail (e.g. a table of decline reasons with links): `search_conversations` with the AI field in `fields`.
Answer with: the headline finding, the numbers (n= always visible), 2-3 short anonymised quotes as texture, what the data does NOT show, and the calibration note.
### Step 7 — Deliverables (offer, then build what's wanted)
- **Dashboard**: render charts/tables directly as an artifact or inline visual in the conversation — never emit code files the user must run themselves. Every section needs a "so what" line; show low-volume warnings on any cut with small n rather than hiding it.
- **Saved Metaview report**: only when the user wants this view to live in Metaview for the team — `create_report` with filters, `field_ids` (identity columns like date/candidate/interviewer first, then AI fields), a customer-facing name/description. Share the returned URL. Confirm before creating; it appears in everyone's Reports list.
- **Recurring pulse**: offer to re-run this on a schedule (weekly digest of new answers) if the user's Claude surface supports scheduled tasks. Recurring sends need a **sanity gate**: if this run's data is empty or wildly different from last run (zero values where there were dozens — usually an ATS integration or permissions change, not reality), send an alert saying so instead of the digest. A confidently empty report to leadership is worse than no report.
## Worked examples of field designs
- "Why are candidates declining?" → population: offer-stage/closing calls, last quarter → field `Decline reason` (single_line_text, closed set: Compensation / Competing offer / Role scope / Location or remote / Timing / Company concerns / Other / Not applicable) + `Decline detail` (long_text, 1-2 sentences, fallback "Not applicable").
- "Salary expectations for engineers" → field `Compensation expectation` (currency; "the candidate's stated expected base salary; if a range, the midpoint; do not annualise day rates unless the candidate did; if not stated, leave empty") — group by role/level; note multi-currency populations must be reported per currency, never averaged together.
- "Which competitors come up, and how are we compared?" → `Competitors mentioned` (list, strict domain: named product/company competitors only, exclude generic tools) + `Competitive framing` (long_text with fallback).
## Edge cases
- **The question is about interviewer behaviour** (coverage, question quality, talk-time): hand to metaview-interviewer-coaching — mixing candidate and interviewer signal in one report muddies both.
- **The user wants one candidate's story**: that's metaview-interview-prep / -debrief territory; AI fields are overkill for n=1.
- **Population < 10**: skip fields; read summaries/transcripts directly and answer qualitatively.
- **Free plan**: AI fields and transcripts may be limited — surface the upgrade action the tools return instead of failing silently.
## Example invocations
- "What are the top concerns candidates raised in screens over the last 30 days, and what should our talk-track say?"
- "Build a quarterly candidate-intelligence dashboard for Engineering: motivations, comp, competitors, concerns."
- "Which sourcing channels produce candidates who make it past the HM screen?"
- "Are candidates asking about our AI strategy? Pull examples from the last 60 days."
