Um Claude Skill que puxa a atividade de contratação da manhã de segunda-feira do ATS — Ashby, Greenhouse ou Lever — faz o diff contra o snapshot da última segunda, roda um passo determinístico de detecção de anomalias no funil, adiciona ROI de canal de sourcing quando dados de orçamento são fornecidos, e produz um digest de uma página para o Head of Talent. O digest nomeia as três anomalias de funil de maior prioridade, os principais roles detalhados por saúde por stage, e um único pedido recomendado para o time de liderança naquela semana. Substitui o e-mail de status de recruiting de sexta à tarde que ninguém gosta de escrever ou ler, evitando deliberadamente o failure mode de leaderboard de reps em que os digests de ops escorregam quando ninguém guarda contra isso.
Quando usar
Sua organização de recruiting roda uma cadência semanal de liderança — digest de segunda, recap de sexta, ou qualquer slot fixo equivalente. O skill é construído para o caso recorrente; snapshots executivos pontuais não valem o setup.
Você consegue produzir um snapshot fresco do ATS toda semana. Exports CSV do Ashby, Greenhouse ou Lever são suficientes; o skill faz o diff de linhas estruturadas, não precisa de integração via API.
Você tem pelo menos 6 semanas de snapshots anteriores acumulados. O threshold de anomalia de funil usa uma média dos últimos 6 semanas por role + stage; abaixo de 6 semanas o skill suprime flags de anomalia em vez de disparar em amostras pequenas.
Um recruiter, owner de recruiting-ops, ou o Head of Talent revisa cada digest antes de ir a qualquer lugar. O skill escreve digest.md em disco e para.
Sua lista de prioridade de roles e SLAs de stage estão documentados (ou você está disposto a documentá-los uma vez). O references/2-role-priority-list-template.md do bundle mostra o formato; se você não conseguir preenchê-lo, o skill usa ordem alfabética por padrão, o que está errado toda semana.
Quando NÃO usar
Auto-publicação sem revisão do recruiter. O skill escreve um arquivo Markdown. Não há ação de post no Slack ou envio de e-mail definida em nenhum lugar do bundle, e adicionar uma é uma expansão deliberada de escopo. Conteúdo sensível — buscas executivas privilegiadas, buscas de substituição de funcionário atual, casos de performance em andamento — precisa de uma leitura humana antes de ir para um canal de liderança. Pular isso produz drama organizacional em menos de quatro semanas.
Relatórios voltados para clientes. Métricas de pipeline, contagens de candidatos e diagnósticos de roles paradas são internos. Pacotes de board que precisam de números de recruiting devem ser um pull separado e higienizado; não encaminhe o digest para nada que saia do Slack do time de pessoas.
Revisões de performance individual de reps. O skill agrega por role, stage de funil e canal de sourcing. Ele deliberadamente remove nomes individuais de recruiter e sourcer do contexto do LLM (veja o passo de bias-screening em apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md, step 5). Confundir saúde de pipeline com performance individual é como um digest de ops se transforma em uma ferramenta de avaliação de performance nos bastidores, o que a maioria dos conselhos de trabalhadores e várias leis trabalhistas estaduais dos EUA tratam como avaliação automatizada de trabalhadores.
Roles com menos de 6 semanas de histórico de pipeline. A detecção de anomalias precisa de uma linha de base de média trailing; em um role novo, o digest reporta estado sem flags. Use o drill-down por role para esses, mas ignore o slot de anomalia vazio.
Substituir o papel de recruiter-coordinator. O recruiting coordinator cuida de agendamento, comunicação com candidatos, logística de painel e as partes de julgamento humano do digest. O skill cuida do passo de síntese, não do passo de coordenação.
Setup
Faça o drop do bundle. Copie apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md mais o diretório references/ para o seu diretório de skills do Claude Code ou setup de Skills personalizados do claude.ai. O skill se chama weekly-recruiting-digest.
Agende o export de snapshot. Configure o seu ATS para soltar um export semanal em um caminho conhecido — toda noite de domingo para um digest de segunda funciona para a maioria dos times. As colunas de schema que o skill espera estão listadas em SKILL.md em “Inputs”; colunas ausentes param a execução com um erro de schema em vez de degradar silenciosamente.
Preencha a lista de prioridade de roles. Copie references/2-role-priority-list-template.md para o seu próprio repo e substitua as linhas de exemplo pelos seus roles abertos reais. Defina priority, target_time_to_fill_days, stage_slas_days e confidentiality por role. O owner de recruiting-ops edita isso semanalmente; o skill captura seu SHA-256 nos metadados de execução para que diffs semanais sejam visíveis em retros.
Opcionalmente adicione dados de canal de sourcing. Se você quiser a seção de ROI de sourcing, adicione o CSV de canal conforme o schema em references/3-source-channel-roi-definitions.md. Se ausente, a seção é omitida, não fabricada. O mesmo arquivo de definições fixa a matemática para cost_per_qualified_applicant e qualified_rate para que comparações semana a semana permaneçam honestas conforme o relatório de gastos se atualiza ao longo das semanas.
Calibre o formato do digest. Edite references/1-digest-format.md para corresponder às preferências de audiência do seu Head of Talent — vocabulário de status (RAG vs No prazo / Em risco / Bloqueado), profundidade de explicação de anomalia e a convenção de texto do pedido recomendado. A ordem das seções estruturais e os cabeçalhos de coluna não mudam; apenas a prosa dentro do template.
Faça um dry-run em dois snapshots anteriores. Escolha uma segunda-feira de duas semanas atrás mais a segunda-feira antes dela, execute o skill e compare seu digest com o que o seu time realmente circulou naquela semana. Os números devem ser reproduzíveis; a interpretação narrativa pode não corresponder — ajuste as notas de preferência de audiência se houver drift.
O que o skill realmente faz
Seis passos, em ordem. Os passos 1-3 são diffs determinísticos e verificações de threshold; apenas o passo 6 usa o LLM para síntese narrativa. A ordem é deliberada — deixar um modelo improvisar sobre o estado bruto do pipeline produz um digest que lê bem e está errado sobre quais números se moveram.
Valide snapshots e carregue a lista de prioridade. Confirme que o schema corresponde entre os snapshots atual e anterior. Pare em uma coluna renomeada em vez de remapear silenciosamente — remap silencioso é como números de conversão de stage se movem 30% em uma semana sem nenhuma razão real.
Diff de saúde de pipeline por role. Para cada role aberto, compute a mudança líquida de pipeline por stage, conversão desta semana vs média trailing, tempo no stage sinalizado contra o SLA do role, dias abertos vs target time-to-fill. Esses são aritméticos, não LLM. A escolha de detalhar por role em vez de agregar org-wide é intencional: “conversão do funil de engenharia é 22%” esconde o fato de que dois roles sênior de backend estão em 8% enquanto três roles júnior estão em 35%, que é o formato acionável.
Detecção de anomalias de funil. Sinalize um stage como anômalo quando a conversão estiver mais de 2 desvios padrão da média trailing de 6 semanas, quando mais de 30% dos candidatos no stage excedem o SLA, ou quando a profundidade top-of-funnel em um role crítico cai mais de 40% semana a semana. Limite em 3 anomalias por digest; mais transforma o digest em uma watch-list que ninguém lê. O threshold de 2 dp em vez de uma porcentagem fixa é o que impede o skill de disparar em ruído normal de amostra pequena em roles de baixo volume. Veja métricas de funil de recruiting para as definições de conversão subjacentes.
ROI de canal de sourcing (somente se dados foram fornecidos). Compute cost-per-qualified-applicant e qualified-rate por canal usando as definições fixas em references/3-source-channel-roi-definitions.md. Sinalize qualquer canal cujo ratio se moveu mais de 25% para o owner de recruiting-ops verificar a atribuição antes do envio. O ponto das definições fixas é a reprodutibilidade — números last-touch se movem quando valores de source do ATS são renomeados, e o digest não deve apresentar uma mudança de configuração como um sinal real de orçamento.
Passo de bias-screening. Remova nomes individuais de recruiter, sourcer e hiring manager do contexto do LLM antes do passo 6. Agregações por recruiter_id existem apenas como verificações de carga vs capacidade (o recruiter deste role tem 14 reqs, o target é 8), não como comparações entre recruiters. Remover nomes do contexto é o que de forma confiável mantém o ranking individual de reps fora do output; instruções de prompt para “não rankear indivíduos” não são confiáveis o suficiente sozinhas.
Faça o rascunho do digest. Passo de LLM. Pegue os outputs determinísticos mais as preferências de audiência e faça o rascunho conforme o formato em references/1-digest-format.md. A narrativa pode interpretar uma queda de conversão (“o slot de painel estava indisponível por duas semanas”) somente se a interpretação estiver nas notas de input; caso contrário a linha lê “causa provável não está nos dados de pipeline — recruiter deve confirmar”. Termine com um único “Pedido recomendado” nomeando audiência, ação e role(s) — ou o literal “Nenhum pedido de liderança esta semana — pipeline está no prazo” se os dados não justificarem um. Nunca invente um pedido para preencher o slot.
O schema completo para inputs do ATS, o formato de output literal e a justificativa do bias-screening ficam todos em apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md.
Realidade de custos
Por digest semanal, no Claude Sonnet 4.5:
Tokens de LLM — tipicamente 25-45k tokens de input (dois snapshots resumidos pelos passos determinísticos + lista de prioridade de role + CSV de sourcing + instruções do skill) e 2-4k tokens de output (o próprio digest mais o apêndice). No Sonnet 4.5 isso fica em torno de $0,10-0,20 por digest. Um ano inteiro de digests semanais é $5-10 em custo de modelo. O gasto com modelo é erro de arredondamento contra o tempo economizado.
Tempo de recruiting-ops — o ganho está aqui, não no custo do modelo. Escrever manualmente um digest semanal estruturado do zero — puxar o ATS, computar conversão por role, escanear por violações de SLA, formatar a tabela, redigir o pedido recomendado — é 90-120 minutos para um gerente de recruiting-ops que conhece bem os dados, mais para alguém mais novo. Revisar e editar o rascunho do skill é 15-25 minutos. Isso representa aproximadamente 60-90 minutos de volta por semana, ou um dia inteiro de ops por trimestre.
Tempo do Head of Talent — o segundo ganho. Um digest consistente e estruturado no mesmo formato toda segunda-feira é lido em 4-6 minutos; um e-mail semanal de recap de formato livre leva 12-18 minutos (ou, mais comumente, é pulado). A linha de pedido recomendado é a parte em que o Head of Talent age; o resto é referência para a semana.
Tempo de setup — 30 minutos para fazer o drop do bundle e preencher a lista de prioridade de roles se a lista já existe em alguma forma (uma página no Notion, uma planilha). Mais perto de 2 horas se a lista de prioridade é nova e o time precisa se alinhar sobre quais roles são critical vs high. O alinhamento é a parte mais difícil; o skill é a parte mais fácil.
Armazenamento de snapshots — trivial. Um export CSV semanal do Ashby ou Greenhouse fica na ordem de 1-5 MB. Um ano de snapshots fica abaixo de 250 MB; guarde em um bucket S3 privado ou em uma pasta privada do repo.
Métrica de sucesso
Acompanhe três números por trimestre, no seu dashboard de ops do time:
Taxa de leitura do digest. Que porcentagem dos destinatários nomeados abre o digest em até 24 horas do envio. Acompanhe na sua ferramenta de e-mail ou adicionando um beacon de um pixel. Abaixo de 70% significa que o digest é muito longo, muito genérico ou chega na hora errada — conserte o formato antes de adicionar seções.
Taxa de execução dos pedidos recomendados. Que porcentagem dos pedidos recomendados semanais são executados pelo time de liderança dentro da mesma semana. Abaixo de 50% significa que os pedidos são vagos (reescreva a convenção de pedido recomendado em references/1-digest-format.md) ou pequenos demais para aparecer (deixe o skill escrever “nenhum pedido esta semana” com mais frequência).
Tempo da flag de anomalia até a remediação. Quando uma anomalia de funil aparece no digest, quantos dias até que a conversão ou o SLA subjacente se recupere. A métrica de throughput que o digest deve mover. Observe essa tendência ao longo de 6-8 semanas em vez de semana a semana.
Versus as alternativas
vs dashboards Analytics do Ashby — o reporting do Ashby é excelente para o owner de recruiting-ops que quer filtrar e pivotar ao vivo. O gap é a camada de síntese: o Head of Talent não quer um dashboard, quer uma página que diga “essas três coisas aconteceram, aqui está o único pedido.” Escolha o Ashby Analytics se sua audiência é o próprio time de recruiting; escolha este skill se sua audiência é a liderança executiva e você precisa da síntese escrita para eles toda semana. Os dois são complementares, não concorrentes.
vs Datapeople — o Datapeople é forte em pontuação de bias em job descriptions e analytics de funil inbound. Problema diferente. Use o Datapeople upstream do funil (melhorando posts de vagas, expondo disparidades inbound); use este skill downstream (sintetizando o que já aconteceu nos roles abertos). Comprar o Datapeople não elimina a necessidade do digest semanal.
vs um digest escrito manualmente pelo recruiter-coordinator. A opção de recruiter-coordinator funciona quando uma pessoa é owner da autoria do digest por menos de 8 semanas antes de rodar para a próxima coisa. Falha quando o formato deriva semana a semana (seções diferentes toda segunda) ou quando o autor está de férias. O skill impõe consistência de formato por estrutura e remove o failure mode de “o autor desta semana estava cansado”. Combine o skill com o recruiting coordinator fazendo o agendamento e enforcement de SLA subjacentes — eles continuam sendo o operador; o skill é o sintetizador.
vs um script SQL + Python artesanal contra o export do ATS. Mesmos números, custo de setup menor somente se você já tem um pipeline de warehouse do ATS. A maioria dos times não tem. O skill entrega o passo de bias-screening, as definições fixas de atribuição de sourcing e a convenção de pedido recomendado; reconstruir isso internamente é mais 2-3 semanas de trabalho sem um payoff claro.
Pontos de atenção
Ranking de recruiters ou sourcers individuais — guardado pelo passo de bias-screening no step 5, que remove nomes individuais do contexto do LLM. Agregações por recruiter_id existem apenas como verificações de carga vs capacidade. O formato de output não tem seção de leaderboard de recruiter e adicionar uma é uma expansão deliberada de escopo que deve ser um skill separado com postura de consentimento separada (veja também diversity recruiting para entender por que rankings por indivíduo produzem mais drama org-wide do que insight).
Drift de atribuição de sourcing — guardado pelas definições fixas em references/3-source-channel-roi-definitions.md e pela comparação de média trailing de 4 semanas em vez de semana a semana. Qualquer canal cujo cost-per-qualified-applicant se mover mais de 25% é sinalizado para o owner de recruiting-ops verificar antes do envio do digest. O checklist de verificação faz as três perguntas que capturam reconfigurations de source-picker do ATS e relatórios de invoice atrasados antes de serem apresentados como mudanças reais.
Flags de anomalia falso-positivos — guardados pela supressão de histórico abaixo de 6 semanas e pelo threshold de 2 desvios padrão em vez de uma porcentagem fixa. O limite rígido de 3 anomalias por digest é imposto mesmo quando mais passariam tecnicamente, com base no fato de que três é o limite superior que o time de liderança consegue agir por semana. Além de três o digest para de ser executado completamente.
Dados do ATS defasados — guardado pela verificação do step 1 de que o snapshot atual está datado dentro das últimas 24 horas. Um digest rodado em dados de três dias se contradiz contra qualquer executivo que verificou o ATS ontem e erode a confiança mais rápido do que pular o digest completamente.
Exposição de roles privilegiados ou sensíveis — guardada pela flag confidentiality: restricted em references/2-role-priority-list-template.md. Roles restritos são resumidos apenas por time e stage — sem título do role, sem contagem de candidatos quando a profundidade do pipeline é baixa, sem nome do hiring manager. O Head of Talent decide por execução se algum role restrito vai na versão mais ampla de liderança.
Drift de auto-envio — guardado pela ausência de qualquer ação de envio no bundle do skill. O skill escreve digest.md em disco e sai. O owner de recruiting-ops cola no canal de escolha após uma leitura final. Conectar uma ação de auto-envio ao skill é o pedido de feature mais comum e a forma mais confiável de parar conteúdo sensível na frente da audiência errada.
Stack
O bundle do skill fica em apps/web/public/artifacts/weekly-recruiting-digest-skill/ e contém:
SKILL.md — a definição do skill (quando invocar, inputs, método de seis passos, formato de output, pontos de atenção)
references/1-digest-format.md — formato estrutural fixo mais preferências de audiência editáveis
references/2-role-priority-list-template.md — lista de prioridade por role preenchível com SLAs de stage e flags de confidencialidade
references/3-source-channel-roi-definitions.md — matemática fixa para cost-per-qualified-applicant e qualified-rate mais o checklist de verificação de drift de atribuição
Ferramentas que o workflow assume que você já usa: Claude (o modelo), e Ashby, Greenhouse ou Lever (o ATS). Combine com o recruiting coordinator que é owner do agendamento e enforcement de SLA, e com o membro do time que é owner do job de export semanal. Veja time-to-fill vs time-to-hire para as definições de métricas que o drill-down por role assume.
---
name: weekly-recruiting-digest
description: Pull the weekend's ATS pipeline state from Ashby / Greenhouse / Lever, diff it against last Monday's snapshot, and produce a one-page Monday-morning digest for the Head of Talent. Surfaces wins, funnel anomalies, source-channel ROI, and the single highest-value ask of the leadership team that week. Always stops at a recruiter-review gate before any send.
---
# Weekly recruiting digest
## When to invoke
Use this skill on Monday morning (or whenever the recruiting leader's weekly cadence runs) when the Head of Talent needs a one-page digest that synthesises last week's hiring activity and surfaces the one or two things the leadership team should actually do this week. Take a fresh ATS pipeline export, the prior week's snapshot, the priority list of open roles, and (optionally) sourcing-channel performance as input. Produce a Markdown digest plus a per-role drill-down appendix.
Do NOT invoke this skill for:
- **Auto-publishing without recruiter review.** The skill writes `digest.md` to disk and stops. There is no "send" or "post to Slack" action defined anywhere in the skill. The Head of Talent or the recruiting-ops owner reads the draft, edits any audience-sensitive content (privileged exec searches, replacement searches, in-flight PIP cases), and sends. AI-drafted-and-sent without review produces organisational drama within four weeks.
- **Customer-facing reports.** This is an internal leadership digest. Recruiting funnel metrics, candidate names, and stalled-role diagnoses are not for external partners, board decks without recruiter sign-off, or anything that leaves the people-team Slack. If a board pack needs recruiting numbers, run a separate, sanitised pull — do not forward this digest.
- **Individual rep-performance reviews.** The skill aggregates by role, funnel stage, and source-channel. It deliberately does not produce a per-recruiter ranking or a per-sourcer leaderboard. Conflating pipeline health with individual performance is how an ops digest turns into a backchannel performance-review tool, which it is not designed for and which most works councils and US state employment laws treat as automated worker evaluation.
## Inputs
- Required: `ats_snapshot_current` — path to a CSV or JSON export from the ATS dated within the last 24 hours. Must contain at minimum: `requisition_id`, `role_title`, `team`, `stage`, `candidate_id` (hashed or pseudonymous), `stage_entered_at`, `last_activity_at`, `source_channel`, `recruiter_id`, `hiring_manager_id`, `requisition_opened_at`, `target_start_date`.
- Required: `ats_snapshot_prior` — path to the equivalent export from the prior week's run. The skill diffs current against prior to identify what materially changed; without a prior snapshot the digest degrades to a static state-of-pipeline report and the "anomalies" section refuses to render.
- Required: `role_priority_list` — path to the file under `references/` that ranks open roles by business priority. The skill uses this to decide which roles get a per-role drill-down (top N) vs which get rolled up into a "remaining roles" summary line. Without a priority list the skill defaults to alphabetical, which is wrong every week.
- Optional: `source_channel_performance` — path to a CSV with `channel`, `cost_last_week`, `applications`, `qualified`, `hired_ytd` for source-channel ROI. If absent, the source-channel section is omitted rather than fabricated.
- Optional: `n_drilldown` — number of roles to drill down on, default 5, hard max 12. Above 12 the digest stops being one-page and the recruiting leader stops reading it.
## Reference files
Always read these from `references/` before generating the digest. Without them the digest is structurally inconsistent and the source-channel section conflates terms.
- `references/1-digest-format.md` — the literal Markdown layout the skill emits, including section order, heading levels, and the "Recommended ask" wording convention. Replace nothing structural; edit only the in-template prose around the Head of Talent's preferences.
- `references/2-role-priority-list-template.md` — fillable template the recruiting-ops owner edits weekly. Drives which roles get a drill-down and which get summarised.
- `references/3-source-channel-roi-definitions.md` — fixed definitions of `cost_per_qualified_applicant`, `qualified_rate`, and `hire_per_dollar` so week-over-week comparisons stay honest. Source-attribution drift is the most common reason last-touch numbers move when nothing real changed.
## Method
Run these six steps in order. Steps 1-3 are deterministic diffs and threshold checks; only step 4 uses the LLM for narrative synthesis. The order is deliberate — letting the model freelance over a raw pipeline state produces a digest that reads well and is wrong about which numbers actually moved.
### 1. Validate snapshots and load priority list
Open both ATS snapshots. Confirm the schema matches (same columns, same enum values for `stage` and `source_channel`). If a column was renamed between exports — common when an ATS admin reconfigures stages — halt and surface the diff to the user. Do not silently remap columns; that is how stage-conversion numbers move 30% in a week for no real reason.
Load `role_priority_list`. Validate that every role marked `priority: critical` exists in `ats_snapshot_current`. If a critical role has been closed or paused since the priority list was last edited, surface that for the recruiting-ops owner to update.
### 2. Per-role pipeline-health diff
For every open role in the current snapshot, compute against the prior snapshot:
- Net change in candidates per stage (entered − exited).
- Stage-conversion rate (this week's exits-to-next-stage divided by this week's entries-to-stage).
- Time-in-current-stage for every candidate, flagged if it exceeds the role's stage SLA (loaded from `role_priority_list`).
- Days-open versus the role's target time-to-fill.
These are arithmetic, not LLM. The deterministic step exists so the numbers in the digest are reproducible — re-running the skill on the same two snapshots produces identical numerics. The choice to drill down per role rather than aggregate org-wide is intentional: an aggregate "engineering funnel conversion is 22%" hides the fact that two senior backend roles are at 8% and three junior roles are at 35%, which is the actionable shape.
### 3. Funnel-anomaly detection
For each role in the top-N drill-down list, flag a stage as anomalous if any of the following hold:
- Stage-conversion rate this week is more than 2 standard deviations off the trailing 6-week mean for that role + stage. Below 6 weeks of history, suppress the flag and write "insufficient history" — do not flag on small samples, that is the false-positive mode.
- More than 30% of candidates in a stage exceed the stage SLA.
- Net pipeline depth at the top of funnel dropped by more than 40% week-over-week and the role is `priority: critical`.
Cap the anomaly list at 3 per digest. If more than 3 trigger, rank by priority weight from the role-priority list and drop the rest into the appendix. Three anomalies is the upper bound for what the leadership team can act on in a week; more turns the digest into a watch-list that nobody reads.
### 4. Source-channel ROI (optional)
Only run if `source_channel_performance` was provided. Compute, using the definitions in `references/3-source-channel-roi-definitions.md`:
- `cost_per_qualified_applicant` per channel, this week vs the trailing 4-week mean.
- `qualified_rate` per channel, this week vs trailing 4-week mean.
- Channels where `cost_per_qualified_applicant` moved more than 25% week-over-week, flagged for the recruiting-ops owner to verify attribution before the digest goes out.
Why ROI per channel rather than just spend: the spend number alone does not tell the Head of Talent whether to renew the LinkedIn slot or shift budget to the niche board. ROI per qualified applicant does, and that is the buying decision the digest exists to inform.
### 5. Bias-screening pass
Before drafting the narrative, scan the inputs for any text the LLM might use that names an individual recruiter, sourcer, or hiring manager in a way that ranks or evaluates them. Strip those names from the context window passed into step 6. The skill aggregates candidate volumes by `recruiter_id` only when computing per-role load (e.g. "this role's recruiter holds 14 reqs, target is 8"), and even then the output uses load thresholds against capacity, not inter-recruiter comparison.
The reason this is a separate explicit pass rather than a prompt instruction: prompt instructions to "do not rank individuals" are unreliable, especially when the input data implicitly ranks them (e.g. fill rates per recruiter). Removing the names from the context is what reliably keeps individual-rep-ranking out of the output.
### 6. Draft the digest
LLM step. Take the deterministic outputs from steps 2-4 and the audience preferences from `references/1-digest-format.md` and draft the digest. The narrative may interpret the numbers ("conversion dropped because the panel interview slot was unavailable for two weeks") only if that interpretation is in the input notes; otherwise write "likely cause not in pipeline data — recruiter to confirm".
End with a single "Recommended ask" — one sentence naming the one thing the Head of Talent should ask the leadership team to do this week. If the data does not warrant an ask, write "No leadership ask this week — pipeline is on track." Never invent an ask to fill the slot.
## Output format
```markdown
# Recruiting digest — Week of <YYYY-MM-DD>
Generated: <ISO timestamp> · Snapshot: <prior date> → <current date> · Roles drilled: <N>
## Pipeline health by role
| Role | Stage | Open since | Target TTF | Pipeline (curr) | Pipeline (prior) | Conversion (this wk) | Status |
|---|---|---|---|---|---|---|---|
| Senior Backend Engineer | Onsite | 47d | 35d | 4 | 6 | 50% (avg 65%) | At risk |
| Director of Sales | Hiring manager review | 22d | 45d | 2 | 2 | n/a | On track |
| ... | ... | ... | ... | ... | ... | ... | ... |
## Top funnel anomalies (3)
1. **Senior Backend Engineer · Onsite → Offer.** Conversion this week
30% vs trailing 6-week mean 62% (2.4 sd off). Likely cause not in
pipeline data — recruiter to confirm before next digest.
2. **Account Executive (NYC) · Recruiter screen → Hiring manager.**
55% of candidates in stage exceed the 5-day SLA. Net pipeline
stable; bottleneck is review throughput.
3. **Senior PM · Top of funnel.** Pipeline depth dropped 48%
week-over-week on a critical role. Source-channel mix shifted
away from inbound; see source section.
## Source-channel performance (last week)
| Channel | Cost | Qualified | Cost / qualified | vs 4-wk mean |
|---|---|---|---|---|
| LinkedIn Jobs | $4,200 | 18 | $233 | +18% |
| Niche board (Hacker News Who's Hiring) | $0 | 7 | $0 | flat |
| Agency (firm A) | $12,000 | 3 | $4,000 | +180% (verify attribution) |
| Referrals | $1,500 | 11 | $136 | -22% |
## Recommended ask
Ask the engineering leadership team to free a 90-minute panel slot for
Senior Backend Engineer onsites this week. The conversion drop is
schedule-driven, not candidate-quality-driven.
## Appendix — remaining open roles
| Role | Status | Notes |
|---|---|---|
| ... | ... | ... |
```
## Watch-outs
- **Ranking individual recruiters or sourcers.** *Guard:* step 5 strips individual names from the context window before the LLM drafts. Per-`recruiter_id` aggregations exist only as load-vs-capacity checks, not as inter-recruiter comparisons. The output format has no "recruiter leaderboard" section and adding one is a deliberate scope expansion that should be a separate skill with separate consent posture.
- **Source-attribution drift.** *Guard:* the channel ROI step uses fixed definitions from `references/3-source-channel-roi-definitions.md` and flags any channel whose cost-per-qualified moved more than 25% for the recruiting-ops owner to verify attribution before the digest goes out. Last-touch attribution moves easily when an ATS admin reconfigures source values; the digest must not present a configuration change as a real budget signal.
- **False-positive anomaly flags.** *Guard:* step 3 suppresses anomaly flags when the role has fewer than 6 weeks of history for the trailing-mean calculation. The cap of 3 anomalies per digest is enforced even when more would technically pass the threshold, to avoid the watch-list-nobody-reads failure mode. The 2-standard- deviation threshold rather than a flat percentage is what stops the skill from flagging normal small-sample noise on low-volume roles.
- **Stale ATS data.** *Guard:* step 1 halts if the current snapshot is older than 24 hours. A digest run on three-day-old data contradicts itself against any executive who checked the ATS yesterday.
- **Privileged or sensitive role exposure.** *Guard:* the role priority list has a `confidentiality: restricted` flag per role. Roles with that flag are summarised by team and stage only — no role title, no candidate names, no hiring-manager name. The Head of Talent decides per run whether to include any of those roles in the version that goes to the broader leadership team.
- **Auto-send drift.** *Guard:* the skill defines no `send`, `post_to_slack`, or `email` action. It writes `digest.md` to disk and exits. The recruiting-ops owner pastes into the channel of choice after a final read.
# Digest format — TEMPLATE
> Replace the in-template prose around the Head of Talent's
> preferences. Do NOT change the section order, heading levels, or
> table column headers — downstream readers (hiring managers, exec
> assistants, the board pack author) skim by structure, not text.
## Section order (fixed)
1. Header (week, snapshot dates, roles drilled count)
2. Pipeline health by role (top-N table)
3. Top funnel anomalies (max 3, ranked)
4. Source-channel performance (omit if data not provided)
5. Recommended ask (single sentence, or explicit "no ask this week")
6. Appendix — remaining open roles (rolled up)
## Audience preference notes
The skill reads this section to tune narrative tone. Edit per Head of Talent. Examples:
- **Numerics-first vs narrative-first.** The default is numerics-first (table, then one-sentence interpretation). If your Head of Talent prefers narrative-first, flip the order inside each role row's drill-down — the section structure stays.
- **Status labels.** Default vocabulary is `On track / At risk / Blocked / Paused`. If your team uses RAG (Red / Amber / Green) or `Healthy / Watch / Escalate`, edit the vocabulary list below and the skill picks it up.
- **Anomaly explanation depth.** Default is one sentence per anomaly. If your Head of Talent wants the full numerical comparison inline rather than just the deviation, set `anomaly_detail: full` in the skill's run config.
## Status vocabulary
Replace with your team's labels. The skill maps to these:
- `On track` — pipeline depth at or above target, conversion within trailing-mean band, no SLA breaches.
- `At risk` — one of: pipeline depth 20-40% below target, conversion 1-2 sd off mean, 20-50% of stage exceeds SLA.
- `Blocked` — pipeline depth >40% below target, conversion >2 sd off mean, or >50% of stage exceeds SLA. Anomaly should also be in the top-3 anomalies section.
- `Paused` — requisition explicitly paused by hiring manager. Do not flag conversion drops on paused roles.
## "Recommended ask" wording convention
Single sentence. Names the audience (engineering leadership, the exec team, the CFO, etc.), the action (free a slot, approve a counter, unblock a panel), and the role(s) it applies to. Past tense and adjectives are forbidden. Examples:
- Good: "Ask the engineering leadership team to free a 90-minute panel slot for Senior Backend Engineer onsites this week."
- Good: "Ask the CFO to approve the counter on the Director of Product candidate by Wednesday — competing offer expires Friday."
- Bad: "We should think about how to improve our panel scheduling." (No audience, no action, vague.)
- Bad: "Engineering hiring is generally going well." (Not an ask.)
If the data does not warrant an ask, the literal text is:
> No leadership ask this week — pipeline is on track.
Never invent an ask to fill the slot. The credibility of the digest depends on the recommended-ask line being true when it appears.
## Confidentiality handling
Roles flagged `confidentiality: restricted` in the priority list are summarised in the appendix as one row per restricted role:
- Team only (no role title)
- Stage only (no candidate count if pipeline depth ≤ 3)
- No hiring-manager name
- No anomaly drill-down (the anomaly is rolled into "stage SLA breach on a restricted role" if it would otherwise have surfaced)
## Last edited
<YYYY-MM-DD> — bump on every change to status vocabulary, audience preferences, or section order.
# Role priority list — TEMPLATE
> Replace this template with your team's actual role priority list
> before each weekly run. The skill reads this file to decide which
> roles get a per-role drill-down vs which get rolled up into the
> appendix. Without it the skill defaults to alphabetical, which is
> wrong every week.
## How the skill uses this file
- **Top-N drill-down selection.** The skill drills down on the top N roles ranked by `priority` (critical first, then high, then medium). N defaults to 5; configurable up to 12 in the skill run config.
- **Stage SLA loading.** The per-stage SLAs in the role rows are what step 2 of the skill checks against when computing "time-in-stage exceeded SLA".
- **Confidentiality flagging.** Roles with `confidentiality: restricted` are summarised, not drilled, regardless of priority.
- **Critical-role validation.** Step 1 of the skill validates that every `priority: critical` role still exists in the current ATS snapshot, and surfaces any that have been closed or paused since this file was last edited.
## Per-role rows
Edit weekly. Drop closed roles. Add new opens. The skill captures this file's SHA-256 in its run output so weekly diffs are visible in retro.
```yaml
roles:
- requisition_id: REQ-2026-118
role_title: Senior Backend Engineer
team: Platform
priority: critical # critical | high | medium | low
target_time_to_fill_days: 35
target_start_date: 2026-06-15
confidentiality: standard # standard | restricted
stage_slas_days:
recruiter_screen: 3
hiring_manager_review: 5
technical_screen: 7
onsite: 10
offer: 5
notes: "Senior IC backfill; previous incumbent leaves 2026-05-20."
- requisition_id: REQ-2026-141
role_title: Director of Sales
team: Revenue
priority: critical
target_time_to_fill_days: 60
target_start_date: 2026-08-01
confidentiality: restricted # exec search; appendix-only summary
stage_slas_days:
recruiter_screen: 5
hiring_manager_review: 7
panel_round_1: 14
panel_round_2: 14
offer: 10
notes: "Replacement search. Limit visibility to Head of Talent + CEO."
- requisition_id: REQ-2026-203
role_title: Account Executive (NYC)
team: Revenue
priority: high
target_time_to_fill_days: 45
target_start_date: 2026-07-01
confidentiality: standard
stage_slas_days:
recruiter_screen: 3
hiring_manager_review: 5
hiring_manager_call: 5
panel: 10
offer: 5
notes: "Two NYC HQ openings on same panel; share scorecard."
- requisition_id: REQ-2026-219
role_title: Senior Product Manager
team: Product
priority: high
target_time_to_fill_days: 50
target_start_date: 2026-07-15
confidentiality: standard
stage_slas_days:
recruiter_screen: 3
hiring_manager_review: 5
portfolio_review: 7
panel: 10
offer: 5
notes: "B2B SaaS PM background required."
- requisition_id: REQ-2026-244
role_title: Customer Success Manager
team: Customer Success
priority: medium
target_time_to_fill_days: 40
target_start_date: 2026-08-15
confidentiality: standard
stage_slas_days:
recruiter_screen: 3
hiring_manager_review: 5
panel: 7
offer: 5
notes: "Backfill, not net new."
```
## Priority-level definitions
To keep priority assignment defensible week-to-week:
- **critical** — revenue-blocking, leadership-blocking, or regulatory-deadline-driven. Every critical role drills down even if the priority list overflows N.
- **high** — important to the quarter's plan but not blocking. Drills down only if the top-N slots are not all consumed by critical roles.
- **medium** — normal-priority backfills and growth roles. Appendix by default.
- **low** — exploratory or speculative reqs (talent pipelining, pre-funding hiring). Appendix only; never drilled.
## Last edited
<YYYY-MM-DD> — bump weekly. The skill warns if this file is older than 7 days, on the assumption that a stale priority list produces a digest pointed at the wrong roles.
# Source-channel ROI definitions — FIXED
> Do not change the math in this file without updating the skill
> simultaneously. Source-attribution drift — where last-week's
> numbers move because someone reconfigured the ATS source picker,
> not because spend or quality actually moved — is the most common
> reason recruiting leaders lose trust in source-channel reporting.
> The point of fixed definitions is reproducibility week-over-week.
## Inputs the skill expects
The optional `source_channel_performance` CSV must have these columns. Missing columns disable the source section rather than fabricate values.
| Column | Type | Definition |
|---|---|---|
| `channel` | string | Source channel name. Must match the `source_channel` enum in the ATS snapshots exactly. |
| `cost_last_week` | number (USD) | Cents-precise cost attributed to this channel for the prior 7-day window. Excludes recruiter salary. |
| `applications` | int | Count of applications received via this channel in the prior 7-day window. |
| `qualified` | int | Count of those applications that passed the recruiter screen (entered `hiring_manager_review` or later). |
| `hired_ytd` | int | Count of hires year-to-date attributable to this channel. Used for the trailing comparison only, not for week-over-week. |
## Definitions (fixed)
### `cost_per_qualified_applicant`
```
cost_per_qualified_applicant = cost_last_week / qualified
```
Use only when `qualified >= 3`. Below that threshold the ratio is noise; the skill writes "n/a (insufficient volume)" and suppresses the comparison line.
### `qualified_rate`
```
qualified_rate = qualified / applications
```
Use only when `applications >= 10`. Below that threshold same as above — write "n/a (insufficient volume)".
### `hire_per_dollar`
```
hire_per_dollar = hired_ytd / sum(cost_last_week, last_52_weeks)
```
This is the trailing-year rollup, computed only when the YTD cost history is available. Used for "is this channel worth renewing?" buy decisions, not for weekly movement.
## Trailing comparison window
All week-over-week percentages compare against the trailing 4-week mean of the same metric, NOT the single prior week. Single-week comparison is dominated by holiday weeks, payroll-funded boost weeks, and one-off events. The 4-week mean smooths those without losing a real shift.
```
delta_vs_mean_pct = (this_week_value − trailing_4wk_mean) / trailing_4wk_mean × 100
```
A channel is flagged for attribution verification when:
```
abs(delta_vs_mean_pct(cost_per_qualified_applicant)) > 25
```
The 25% threshold is what catches real budget shifts and ATS reconfiguration noise, without flagging normal week-to-week jitter. Below 25% the digest reports the number without a flag.
## Source-attribution drift — what the verification step checks
When a channel is flagged, the recruiting-ops owner is asked to confirm before the digest goes out:
1. **Did anyone reconfigure the ATS source picker this week?** If a value was renamed (e.g. "LinkedIn" became "LinkedIn Jobs" while "LinkedIn Recruiter" stayed the same), the apparent shift is a data artefact, not a real change.
2. **Did spend reporting catch up from a prior week?** Some agency invoices land in the wrong week and inflate one week's cost while deflating the next. The skill cannot detect this; the recruiting-ops owner must.
3. **Was there a one-off boost?** Conference sponsorship, paid InMail credit-burn, referral bonus campaign. One-off boosts should be annotated in the digest's notes line, not presented as a sustained shift.
## Channels the skill assumes exist
Edit per stack. The skill validates that the `channel` values in the CSV match this list and warns on any unknown channel.
```yaml
known_channels:
- linkedin_jobs
- linkedin_recruiter
- referrals
- inbound_career_page
- niche_board_hn_who_is_hiring
- niche_board_other
- agency_firm_a
- agency_firm_b
- sourcing_juicebox
- sourcing_hireez
- event_sponsorship
- other
```
## Last edited
<YYYY-MM-DD> — bump on every change to math, thresholds, or the known-channels list. The skill refuses to run if this file is older than 90 days, on the assumption that source-channel definitions need a quarterly review.
