Un Claude Skill qui extrait l’activité de recrutement du lundi matin depuis l’ATS — Ashby, Greenhouse, ou Lever — compare avec l’instantané du lundi précédent, exécute une passe déterministe de détection d’anomalies dans l’entonnoir, superpose le ROI des canaux de sourcing lorsque des données budgétaires sont fournies, et produit un digest d’une page pour le Head of Talent. Le digest nomme les trois anomalies d’entonnoir les plus prioritaires, les rôles principaux détaillés par santé par étape, et une seule demande recommandée pour l’équipe de direction cette semaine. Remplace l’email de statut de recrutement du vendredi après-midi que personne n’apprécie à rédiger ou à lire, tout en évitant délibérément le mode d’échec du classement individuel dans lequel les digests ops glissent quand personne ne s’en prémunit.
Quand utiliser ce skill
Votre organisation de recrutement tient une cadence de direction hebdomadaire — digest du lundi, récapitulatif du vendredi, ou tout équivalent à créneau fixe. Le skill est conçu pour le cas récurrent ; les instantanés exec ponctuels ne justifient pas la configuration.
Vous pouvez produire un nouvel instantané ATS chaque semaine. Les exports CSV depuis Ashby, Greenhouse ou Lever conviennent ; le skill compare des lignes structurées, il n’a pas besoin d’intégration API.
Vous avez au moins 6 semaines d’instantanés précédents accumulés. Le seuil d’anomalie d’entonnoir utilise une moyenne glissante sur 6 semaines par rôle + étape ; en dessous de 6 semaines, le skill supprime les signaux d’anomalie plutôt que de s’activer sur de petits échantillons.
Un recruteur, un responsable recruiting-ops ou le Head of Talent révise chaque digest avant qu’il n’aille où que ce soit. Le skill écrit digest.md sur disque et s’arrête.
Votre liste de priorité de rôles et vos SLA d’étape sont documentés (ou vous êtes prêt à les documenter une fois). Le references/2-role-priority-list-template.md du bundle montre la forme ; si vous ne pouvez pas le remplir, le skill utilise l’ordre alphabétique par défaut, ce qui est faux chaque semaine.
Quand NE PAS utiliser ce skill
Publication automatique sans révision d’un recruteur. Le skill écrit un fichier Markdown. Il n’y a aucune action de publication Slack ou d’envoi d’email définie nulle part dans le bundle, et en ajouter une est une expansion de périmètre délibérée. Les contenus sensibles — recherches exec privilégiées, recherches de remplacement d’employé en poste, cas de performance en cours — nécessitent une lecture humaine avant d’aller dans un canal de direction. Sauter cette étape produit un drame organisationnel dans les quatre semaines.
Rapports destinés aux clients. Les métriques de pipeline, les décomptes de candidats et les diagnostics de rôles bloqués sont internes. Les packs pour le conseil qui nécessitent des chiffres de recrutement doivent être rédigés séparément et assainis ; ne transmettez pas le digest dans tout ce qui quitte le Slack de l’équipe people.
Revues de performance individuelle. Le skill agrège par rôle, étape d’entonnoir et canal de sourcing. Il supprime délibérément les noms individuels de recruteurs et de sourcers du contexte du LLM (voir la passe de filtrage de biais dans apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md, étape 5). Confondre la santé du pipeline avec la performance individuelle est la façon dont un digest ops se transforme en outil d’évaluation de performance en coulisses, que la plupart des comités d’entreprise et plusieurs lois du travail d’États américains traitent comme une évaluation automatisée des travailleurs.
Rôles avec moins de 6 semaines d’historique de pipeline. La détection d’anomalies nécessite une baseline de moyenne glissante ; sur un rôle tout nouveau, le digest rapporte l’état sans signaux. Utilisez le détail par rôle pour ceux-ci mais ignorez le créneau d’anomalie vide.
Remplacement du rôle de coordinateur recruteur. Le coordinateur recruteur gère la planification, la communication avec les candidats, la logistique des panels et les parties relevant du jugement humain du digest. Le skill prend l’étape de synthèse, pas l’étape de coordination.
Configuration
Déposez le bundle. Copiez apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md ainsi que le répertoire references/ dans votre répertoire de skills Claude Code ou votre configuration de Skills personnalisés claude.ai. Le skill est nommé weekly-recruiting-digest.
Planifiez l’export d’instantanés. Configurez votre ATS pour déposer un export hebdomadaire dans un chemin connu — chaque dimanche soir pour un digest du lundi convient à la plupart des équipes. Les colonnes de schéma que le skill attend sont listées dans SKILL.md sous « Inputs » ; les colonnes manquantes arrêtent l’exécution avec une erreur de schéma plutôt que de se dégrader silencieusement.
Remplissez la liste de priorité de rôles. Copiez references/2-role-priority-list-template.md dans votre propre dépôt et remplacez les exemples de lignes par vos vrais postes ouverts. Définissez priority, target_time_to_fill_days, stage_slas_days et confidentiality par rôle. Le responsable recruiting-ops édite cela chaque semaine ; le skill capture son SHA-256 dans les métadonnées d’exécution afin que les différences hebdomadaires soient visibles dans les rétrospectives.
Optionnellement, ajoutez des données de canal de sourcing. Si vous voulez la section ROI des sources, déposez le CSV de canaux selon le schéma dans references/3-source-channel-roi-definitions.md. S’il est absent, la section est omise, pas fabriquée. Le même fichier de définitions fixe le calcul du cost_per_qualified_applicant et du qualified_rate afin que les comparaisons semaine-sur-semaine restent honnêtes à mesure que les rapports de dépenses se stabilisent entre les semaines.
Calibrez le format du digest. Éditez references/1-digest-format.md pour correspondre aux préférences d’audience du Head of Talent — vocabulaire de statut (RAG vs Sur la bonne voie / À risque / Bloqué), profondeur d’explication des anomalies et convention de formulation de la demande recommandée. L’ordre des sections structurelles et les en-têtes de colonnes ne changent pas ; uniquement la prose dans le modèle.
Faites un essai à blanc sur deux instantanés précédents. Choisissez un lundi d’il y a deux semaines plus le lundi d’avant, exécutez le skill et comparez son digest à celui que votre équipe a réellement diffusé cette semaine-là. Les chiffres devraient être reproductibles ; l’interprétation narrative peut ne pas correspondre — ajustez les notes de préférences d’audience si elle s’éloigne.
Ce que le skill fait réellement
Six étapes, dans l’ordre. Les étapes 1 à 3 sont des comparaisons déterministes et des vérifications de seuil ; seule l’étape 6 utilise le LLM pour la synthèse narrative. L’ordre est délibéré — laisser un modèle improviser sur l’état brut du pipeline produit un digest qui se lit bien et qui est faux sur quels chiffres ont bougé.
Valider les instantanés et charger la liste de priorité. Confirmer que le schéma correspond entre les instantanés courant et précédent. S’arrêter sur une colonne renommée plutôt que remapper silencieusement — le remapping silencieux est la raison pour laquelle les taux de conversion par étape bougent de 30 % en une semaine sans raison réelle.
Comparaison de santé de pipeline par rôle. Pour chaque poste ouvert, calculer la variation nette du pipeline par étape, la conversion de cette semaine vs la moyenne glissante, le temps dans l’étape signalé par rapport au SLA de rôle, les jours ouverts vs le délai cible de remplissage. Ce sont des calculs arithmétiques, pas du LLM. Le choix de détailler par rôle plutôt qu’en agrégeant à l’échelle de l’organisation est intentionnel : un « taux de conversion de l’entonnoir engineering de 22 % » cache le fait que deux rôles backend senior sont à 8 % tandis que trois rôles junior sont à 35 %, ce qui est la forme exploitable.
Détection d’anomalies d’entonnoir. Signaler une étape comme anormale quand la conversion est à plus de 2 écarts types de la moyenne glissante sur 6 semaines, quand plus de 30 % des candidats à une étape dépassent le SLA, ou quand la profondeur du haut de l’entonnoir sur un rôle critique chute de plus de 40 % semaine-sur-semaine. Limiter à 3 anomalies par digest ; plus transforme le digest en liste de surveillance que personne ne lit. Le seuil de 2 écarts types plutôt qu’un pourcentage fixe est ce qui empêche le skill de se déclencher sur le bruit normal des petits échantillons sur les rôles à faible volume. Voir les métriques d’entonnoir de recrutement pour les définitions de conversion sous-jacentes.
ROI des canaux de sourcing (uniquement si des données ont été fournies). Calculer le coût-par-candidat-qualifié et le taux-qualifié par canal en utilisant les définitions fixes de references/3-source-channel-roi-definitions.md. Signaler tout canal dont le ratio a bougé de plus de 25 % pour que le responsable recruiting-ops vérifie l’attribution avant l’envoi. L’intérêt des définitions fixes est la reproductibilité — les chiffres last-touch bougent quand les valeurs source ATS sont renommées, et le digest ne doit pas présenter un changement de configuration comme un vrai signal budgétaire.
Passe de filtrage de biais. Retirer les noms individuels de recruteurs, sourcers et hiring managers du contexte du LLM avant l’étape 6. Les agrégations par recruiter_id n’existent que comme vérifications de charge vs capacité (ce recruteur sur ce rôle tient 14 postes, la cible est 8), pas comme comparaisons inter-recruteurs. Retirer les noms du contexte est ce qui maintient de manière fiable le classement individuel hors de la sortie ; les instructions de prompt « ne pas classer les individus » ne sont pas suffisamment fiables seules.
Rédiger le digest. Étape LLM. Prendre les sorties déterministes plus les préférences d’audience et rédiger selon le format dans references/1-digest-format.md. La narrative peut interpréter une baisse de conversion (« le créneau panel était indisponible pendant deux semaines ») uniquement si l’interprétation est dans les notes d’entrée ; sinon la ligne se lit « cause probable non dans les données pipeline — recruteur à confirmer ». Terminer par une seule « Demande recommandée » nommant audience, action et rôle(s) — ou le littéral « Aucune demande de direction cette semaine — le pipeline est sur la bonne voie » si les données ne le justifient pas. Ne jamais inventer une demande pour remplir le créneau.
Le schéma complet pour les entrées ATS, le format de sortie littéral et la justification du filtrage de biais se trouvent tous dans apps/web/public/artifacts/weekly-recruiting-digest-skill/SKILL.md.
Réalité des coûts
Par digest hebdomadaire, sur Claude Sonnet 4.5 :
Tokens LLM — typiquement 25 à 45k tokens d’entrée (deux instantanés résumés par les étapes déterministes + liste de priorité de rôles + CSV source + instructions du skill) et 2 à 4k tokens de sortie (le digest lui-même plus l’annexe). Sur Sonnet 4.5, cela donne environ $0,10 à 0,20 par digest. Une année complète de digests hebdomadaires représente $5 à 10 en coût de modèle. La dépense de modèle est un arrondi par rapport au temps économisé.
Temps recruiting-ops — le gain est ici, pas dans le coût de modèle. Rédiger à la main un digest hebdomadaire structuré depuis zéro — extraire l’ATS, calculer la conversion par rôle, scanner les violations de SLA, formater le tableau, rédiger la demande recommandée — représente 90 à 120 minutes pour un manager recruiting-ops qui connaît bien les données, davantage pour quelqu’un de plus récent. Réviser et éditer le brouillon du skill prend 15 à 25 minutes. C’est environ 60 à 90 minutes récupérées par semaine, soit une journée entière d’ops-headcount par trimestre.
Temps Head of Talent — le second gain. Un digest cohérent et structuré dans le même format chaque lundi se lit en 4 à 6 minutes ; un email de récapitulatif hebdomadaire en format libre prend 12 à 18 minutes (ou, plus souvent, est ignoré). La ligne de demande recommandée est celle sur laquelle le Head of Talent agit ; le reste est une référence pour la semaine.
Temps de configuration — 30 minutes pour déposer le bundle et remplir la liste de priorité de rôles si la liste de priorité existe déjà sous une forme quelconque (une page Notion, une feuille de calcul). Plus proche de 2 heures si la liste de priorité est entièrement nouvelle et que l’équipe doit s’aligner sur quels rôles sont critiques vs élevés. L’alignement est la partie la plus difficile ; le skill est la partie la plus facile.
Stockage des instantanés — trivial. Un export CSV hebdomadaire depuis Ashby ou Greenhouse est de l’ordre de 1 à 5 Mo. Une année d’instantanés fait moins de 250 Mo ; conservez-les dans un bucket S3 privé ou un dossier privé de dépôt.
Indicateur de succès
Suivez trois chiffres par trimestre, dans le tableau de bord ops de votre équipe :
Taux de lecture du digest. Quelle part des destinataires nommés ouvre le digest dans les 24 heures suivant l’envoi. Suivez dans votre outil email ou en ajoutant un pixel de suivi. En dessous de 70 %, le digest est trop long, trop générique ou arrive au mauvais moment — corrigez le format avant d’ajouter des sections.
Taux de réalisation des demandes recommandées. Quelle part des demandes recommandées hebdomadaires est mise en œuvre par l’équipe de direction dans la même semaine. En dessous de 50 %, les demandes sont vagues (réécrivez la convention de demande recommandée dans references/1-digest-format.md) ou trop petites pour être remontées (laissez le skill écrire « aucune demande cette semaine » plus souvent).
Temps de l’anomalie signalée à la remédiation. Quand une anomalie d’entonnoir apparaît dans le digest, combien de jours jusqu’à ce que la conversion ou le SLA sous-jacent se rétablisse. La métrique de débit que le digest est censé faire bouger. Observez cette tendance sur 6 à 8 semaines plutôt que semaine après semaine.
Comparaison avec les alternatives
vs Ashby Analytics dashboards — La gestion des rapports Ashby est excellente pour le responsable recruiting-ops qui veut filtrer et pivoter en direct. Le manque est la couche de synthèse : le Head of Talent ne veut pas un tableau de bord, il veut une page qui dit « ces trois choses se sont passées, voici la seule demande ». Choisissez Ashby Analytics si votre audience est l’équipe de recrutement elle-même ; choisissez ce skill si votre audience est la direction et que vous avez besoin que la synthèse soit rédigée pour eux chaque semaine. Les deux sont complémentaires, pas en compétition.
vs Datapeople — Datapeople est fort sur le scoring de biais des descriptions de poste et l’analyse de l’entonnoir entrant. Problème différent. Utilisez Datapeople en amont de l’entonnoir (améliorer les offres d’emploi, faire remonter les disparités entrantes) ; utilisez ce skill en aval (synthétiser ce qui s’est passé sur les postes ouverts). Acheter Datapeople ne supprime pas le besoin du digest hebdomadaire.
vs un digest rédigé manuellement par le coordinateur-recruteur. L’option coordinateur-recruteur fonctionne quand une personne possède la rédaction du digest pendant moins de 8 semaines avant de passer à autre chose. Elle échoue quand le format dérive semaine après semaine (sections différentes chaque lundi) ou quand l’auteur est en vacances. Le skill impose la cohérence de format par structure et supprime le mode d’échec « l’auteur-de-cette-semaine-était-fatigué ». Associez le skill au coordinateur recruteur qui fait la planification sous-jacente et l’application des SLA — ils restent l’opérateur ; le skill est le synthétiseur.
vs un script SQL + Python fait maison contre l’export ATS. Mêmes chiffres, coût de configuration inférieur uniquement si vous avez déjà un pipeline d’entrepôt depuis l’ATS. La plupart des équipes n’en ont pas. Le skill livre la passe de filtrage de biais, les définitions d’attribution de source fixes et la convention de demande recommandée ; les reconstruire en interne représente 2 à 3 semaines de travail supplémentaire sans un gain clair.
Points de vigilance
Classement de recruteurs ou sourcers individuels — protégé par la passe de filtrage de biais à l’étape 5, qui retire les noms individuels du contexte du LLM. Les agrégations par recruiter_id n’existent que comme vérifications de charge vs capacité. Le format de sortie n’a pas de section de classement de recruteurs et en ajouter une est une expansion de périmètre délibérée qui devrait être un skill séparé avec une posture de consentement séparée (voir aussi le recrutement pour la diversité pour expliquer pourquoi les classements individuels produisent plus de drama organisationnel que d’insight).
Dérive d’attribution des sources — protégé par les définitions fixes dans references/3-source-channel-roi-definitions.md et la comparaison à la moyenne glissante sur 4 semaines plutôt que semaine-sur-semaine. Tout canal dont le coût-par-candidat-qualifié bouge de plus de 25 % est signalé au responsable recruiting-ops pour vérification avant que le digest ne parte. La checklist de vérification pose les trois questions qui permettent de détecter les reconfigurations du sélecteur de source ATS et les rapports de factures en retard avant qu’ils soient présentés comme de vraies évolutions.
Faux positifs d’anomalies — protégé par la suppression en dessous de 6 semaines d’historique et le seuil de 2 écarts types plutôt qu’un pourcentage fixe. Le plafond strict de 3 anomalies par digest est appliqué même quand davantage passeraient techniquement le seuil, sur la base que trois est la limite supérieure que l’équipe de direction peut traiter par semaine. Au-delà de trois, le digest cesse d’être traité du tout.
Données ATS obsolètes — protégé par la vérification à l’étape 1 que l’instantané courant est daté dans les dernières 24 heures. Un digest exécuté sur des données vieilles de trois jours se contredit avec tout cadre qui a vérifié l’ATS hier et érode la confiance plus vite que d’ignorer complètement le digest.
Exposition de rôles privilégiés ou sensibles — protégé par le flag confidentiality: restricted dans references/2-role-priority-list-template.md. Les rôles restreints sont résumés uniquement par équipe et étape — pas de titre de rôle, pas de décompte de candidats quand la profondeur du pipeline est faible, pas de nom de hiring manager. Le Head of Talent décide par exécution si un rôle restreint figure dans la version pour la direction élargie.
Dérive d’envoi automatique — protégé par l’absence de toute action d’envoi dans le bundle du skill. Le skill écrit digest.md sur disque et se termine. Le responsable recruiting-ops colle dans le canal de son choix après une dernière lecture. Câbler une action d’envoi automatique sur le skill est la demande de fonctionnalité la plus courante et la façon la plus fiable de diffuser du contenu sensible devant le mauvais public.
Stack
Le bundle du skill se trouve dans apps/web/public/artifacts/weekly-recruiting-digest-skill/ et contient :
SKILL.md — la définition du skill (quand-invoquer, entrées, méthode en six étapes, format de sortie, points de vigilance)
references/1-digest-format.md — format structurel fixe plus préférences d’audience éditables
references/2-role-priority-list-template.md — liste de priorité par rôle à remplir avec SLA d’étape et flags de confidentialité
references/3-source-channel-roi-definitions.md — calcul fixe du coût-par-candidat-qualifié et du taux-qualifié plus la checklist de vérification de dérive d’attribution
Outils que le workflow suppose que vous utilisez déjà : Claude (le modèle), et Ashby, Greenhouse ou Lever (l’ATS). Associez avec le coordinateur recruteur qui détient la planification et l’application des SLA, et avec le membre d’équipe qui détient le job d’export hebdomadaire. Voir délai de remplissage vs délai d’embauche pour les définitions des métriques que le détail par rôle suppose.
---
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.
