Un Claude Skill qui prend une description de poste, le niveau du rôle, les compétences incontournables et le pool d’intervieweurs éligibles avec les points forts calibrés de chaque intervieweur, et produit une conception de loop complète — progression des étapes, rubric par étape avec descriptions d’ancres, questions comportementales par dimension, et tableau d’attribution des intervieweurs avec la justification de chaque choix. Puis s’arrête à un point de contrôle de révision du hiring manager avant que quoi que ce soit ne soit configuré dans l’ATS. Remplace « on verra le loop quand un candidat est en entretien téléphonique » par une passe de conception de 30 minutes qui produit une discipline opérationnelle.
Quand l’utiliser
Vous disposez d’une JD approuvée, d’un niveau confirmé et d’une liste de compétences incontournables qui différencient embauche de non-embauche pour ce poste.
Vous avez une bibliothèque de rubric d’entretiens structurés avec des descriptions d’ancres par niveau de score par tranche de niveau. Le modèle de compétences dans apps/web/public/artifacts/interview-loop-builder-skill/references/1-competency-library.md montre la forme ; si vous ne pouvez pas le remplir, vous n’avez pas encore de rubric que ce skill peut exploiter.
Vous avez un pool d’intervieweurs avec des points forts calibrés enregistrés par compétence par tranche de niveau — voir references/2-interviewer-strengths.md dans le bundle pour la matrice.
Un hiring manager révisera le loop avant qu’il ne soit configuré dans Ashby ou Greenhouse. Le skill écrit des fichiers et s’arrête ; il ne pousse pas vers l’ATS.
Quand NE PAS l’utiliser
Planification automatique. Ce skill conçoit le loop. Il ne planifie pas les entretiens, ne fait pas correspondre les calendriers et n’envoie pas de liens de réservation côté candidat. C’est Goodtime, Ashby Scheduling ou Greenhouse Scheduling. Coupler conception et planification dans un seul skill couple deux modes d’échec qui devraient échouer indépendamment.
Remplacer la conception du rubric avec le hiring manager. Le skill émet des descriptions d’ancres par niveau de score en extrayant depuis la bibliothèque de compétences, mais la bibliothèque elle-même — à quoi ressemble un 5 pour systems-design au niveau IC5 — est la propriété du hiring manager et du responsable de fonction. Si la bibliothèque est vide ou tout-en-modèle, le skill refuse et fait remonter un TODO plutôt qu’inventer des ancres de rubric sur une fonction pour laquelle il n’a pas de signal calibré.
Loops génériques basés sur des modèles sans calibration propre au rôle. Si les inputs ne nomment pas le niveau, les compétences incontournables ou le pool d’intervieweurs éligibles, le skill refuse. Un loop en quatre étapes avec des libellés génériques « comportemental », « technique », « system design », « leadership » paraît structuré mais ne l’est pas. Chaque candidat reçoit les mêmes questions quel que soit les priorités du rôle, ce qui annule le point de la structure.
Postes en dessous d’un seuil de complexité défini. Un rôle de sous-traitant de deux semaines n’a pas besoin d’un loop en quatre étapes. Le skill avertit et suggère un entretien d’une seule étape si le rôle est un contrat, à l’heure ou d’une durée prévue de moins de 6 mois.
Remplacer la formation en entretiens comportementaux. Les questions émises par le skill suivent la forme situation/comportement/résultat, mais les intervieweurs ont encore besoin d’une calibration entraînée pour scorer de manière cohérente. Le skill est l’échafaudage ; la formation est le prérequis.
Configuration
Déposez le bundle. Placez apps/web/public/artifacts/interview-loop-builder-skill/SKILL.md dans votre répertoire de skills Claude Code (ou dans les Skills personnalisés claude.ai). Le skill expose une seule fonction callable : design_loop.
Remplissez la bibliothèque de compétences. Copiez references/1-competency-library.md dans votre repo d’équipe. Remplacez chaque placeholder par vos vraies compétences, définitions, tranches de niveaux couvertes et descriptions d’ancres par niveau de score. Le skill refuse de s’exécuter si la bibliothèque est uniquement un modèle.
Remplissez la matrice de points forts des intervieweurs. Copiez references/2-interviewer-strengths.md. Listez chaque intervieweur éligible, son équipe et les tranches de niveaux sur lesquelles il est calibré pour scorer chaque compétence. La colonne « Dernier entretien » est le déclencheur pour re-calibrer à 6 mois d’inactivité.
Configurez les inputs par poste. Pour un poste donné, transmettez le chemin de la JD, le niveau, un tableau de 3-6 identifiants de compétences et un chemin vers la matrice de points forts des intervieweurs remplie. Le skill émet loop.md et des squelettes de scorecards par étape sous scorecards/.
Test à blanc sur un loop clôturé. Exécutez sur un poste que vous avez conçu manuellement le trimestre dernier. Comparez le mapping des étapes et les attributions d’intervieweurs du skill avec la conception manuelle. S’ils divergent, la bibliothèque de compétences ou la matrice d’intervieweurs est habituellement ce qui nécessite un ajustement, pas le prompt du skill.
Ce que le skill fait réellement
Six étapes, dans l’ordre. L’ordre est important : la validation déterministe et le mapping se produisent avant que le LLM génère des ancres de rubric et des questions, et la passe d’expérience candidat à la fin relit le loop assemblé pour détecter la surcharge qui est invisible lors de l’attribution de chaque étape isolément.
Validation des inputs. Chaque identifiant de compétence existe dans la bibliothèque ; le pool d’intervieweurs compte au moins une personne calibrée par compétence incontournable au niveau du rôle ; le niveau tombe dans les tranches couvertes par la bibliothèque. S’arrête avec des TODOs explicites si une vérification échoue. Concevoir un loop Directeur avec une bibliothèque uniquement IC produit des rubrics gonflés — c’est l’étape qui l’empêche.
Mapping des compétences vers les étapes. L’entretien téléphonique recruteur évalue l’adéquation et les bases (jamais sur-rubric). L’entretien téléphonique HM prend les 1-2 compétences différenciatrices les plus importantes. Le loop on-site répartit le reste à raison d’une par entretien autant que possible. La règle d’une compétence par entretien est un choix tranché — regrouper deux compétences dans un entretien de 60 minutes produit un signal plus superficiel sur les deux, et rend le rubric plus difficile à appliquer sur le moment.
Génération du rubric par étape. Pour chaque étape post-filtrage, extrayez les descriptions d’ancres pour la tranche de niveau du candidat depuis la bibliothèque de compétences. Générez 3-5 questions comportementales par dimension en suivant la forme situation/comportement/résultat, plus une relance suggérée par question. Les questions hypothétiques « que feriez-vous » sont exclues par défaut — elles récompensent la devinette articulée plutôt que l’expérience avérée.
Attribution des intervieweurs avec justification. Pour chaque étape post-filtrage, proposez 1-3 intervieweurs depuis le pool. Faites correspondre par adéquation de calibration (exigence stricte), charge (aucun intervieweur dans plus d’une étape du même loop), et diversité de perspective (au moins un intervieweur extérieur à l’équipe d’embauche quand le pool le permet). Chaque attribution est livrée avec une chaîne de justification explicite.
Passe d’expérience candidat. Relit le loop assemblé. Temps total d’entretien actif au-dessus de 5 heures pour IC ou 7 pour le leadership → signale et suggère un take-home. Plus de 6 intervieweurs distincts → signale la fatigue de loop. Deux étapes sondant la même compétence → signale un signal redondant. Étapes inter-fuseaux horaires sans accommodation → fait remonter un TODO.
Point de contrôle de révision du hiring manager. Écrit loop.md et scorecards/<NN>-<stage-id>.md. S’arrête. Le skill ne définit pas d’action « publier dans l’ATS ». Le HM ouvre le fichier, le modifie et configure le loop dans Ashby ou Greenhouse lui-même.
Le format de sortie littéral et la mise en page du squelette de scorecard se trouvent dans references/3-loop-output-format.md dans le bundle. Le format est fixe car les consommateurs en aval — l’intervieweur lisant la scorecard, le facilitateur de débrief collatant les scores — ont besoin d’une structure prévisible.
Réalité des coûts
Par conception de loop, sur Claude Sonnet 4.5 :
Tokens LLM — typiquement 30-60k tokens d’entrée (JD plus bibliothèque de compétences plus matrice d’intervieweurs plus instructions du skill) et 10-20k tokens de sortie (loop plus 3-5 squelettes de scorecard avec ancres et questions). Sur Sonnet 4.5, c’est environ 0,20-0,40 $ par conception de loop. Une fonction recrutant 8 postes par trimestre dépense moins de 5 $ en coût de modèle sur ce skill.
Temps du recruteur et du hiring manager — le gain est ici. Une conception de loop manuelle à partir de zéro avec des extractions de rubric calibrées représente 90-120 minutes de temps HM plus recruteur lors de la session de conception, plus 30-60 minutes pour documenter les questions et attributions. Le skill comprime ça en une passe de révision de 30 minutes sur le loop généré. Par poste, c’est environ 90 minutes de temps IC ou manager senior économisées.
Temps de configuration — 30 minutes par poste une fois la bibliothèque de compétences et la matrice d’intervieweurs remplies. La bibliothèque et la matrice sont le prérequis — nouvelles, elles nécessitent une session de calibration par tranche de compétences, ce qui est un investissement en entretiens structurés, pas la configuration de ce skill.
Bénéfice composé — les loops structurés produisent une meilleure qualité d’embauche que les loops ad-hoc dans chaque étude publiée remontant à vingt ans. Le gain du skill est de faire de « structuré » le défaut plutôt que l’exception en supprimant la charge de conception par poste.
Métriques de succès
Suivez trois chiffres par poste par trimestre, dans l’ATS :
Délai de conception du loop — heures de « poste approuvé » à « loop configuré dans l’ATS ». Devrait baisser significativement après que le skill est dans la boucle. Si ce n’est pas le cas, le goulot d’étranglement est la révision du HM, pas la conception — faites remonter le loop plus tôt dans la séquence de lancement du poste.
Accord inter-évaluateurs sur le rubric — par dimension de compétence, quelle est la fréquence à laquelle les scores indépendants des intervieweurs tombent dans un point. Devrait atteindre 80 % ou plus sur les compétences calibrées. En dessous, les descriptions d’ancres dans la bibliothèque de compétences sont ce qui doit être ajusté, pas le skill.
Qualité d’embauche à 12 mois — la métrique à long terme que le loop est censé faire bouger. Comparez les cohortes embauchées via des loops conçus par le skill vs des loops ad-hoc sur la même famille de postes. Si la cohorte conçue par le skill ne surperforme pas, réexaminez le mapping compétence-vers-étape plutôt qu’abandonner la structure.
Alternatives
vs les modèles d’entretiens structurés d’Ashby — Ashby possède le loop configuré, le rendu des scorecards et le débrief dans un seul produit. Choisissez les modèles d’Ashby si vous voulez une UX gérée et que votre équipe vivra dans l’ATS. Choisissez ce skill si vous voulez les ancres du rubric, la matrice de points forts des intervieweurs et le mapping compétence-vers-étape dans votre propre repo, versionnés, avec l’étape de conception remplaçable à mesure que la bibliothèque de compétences évolue. L’output du skill est l’input à la configuration du loop d’Ashby, pas un remplacement.
vs les loops basés sur des modèles génériques — chaque ATS livre des modèles par défaut en quatre étapes (« entretien téléphonique, HM screen, technique, on-site panel »). Ils passent pour structurés à première vue mais ne le sont pas. Le même modèle est appliqué à un IC4 Backend et à un Manager CS M2, avec les mêmes questions génériques, quelle que soit la compétence différenciatrice réelle de chaque rôle. Le skill amortit ses 30 minutes de configuration au deuxième poste car la conception est calibrée par poste plutôt qu’universelle.
vs la conception de loop DIY du hiring manager — un HM senior peut concevoir un bon loop à partir de zéro en 90-120 minutes. Il tend à ne pas le faire, car sous pression de délai il réutilise le dernier loop qu’il a géré, quelle que soit l’adéquation. Le gain du skill n’est pas « conçoit mieux qu’un HM expérimenté au sommet de sa forme » ; c’est « conçoit aussi bien qu’un HM expérimenté de manière cohérente, sur tous les postes et toutes les semaines ». La cohérence est le bénéfice composé.
vs pas de loop structuré du tout — les méta-analyses publiées sur les entretiens structurés placent les entretiens structurés à environ deux fois la validité prédictive des entretiens non structurés pour la performance au travail. Si votre statu quo est non structuré, le skill n’est pas la question — adopter la structure l’est. Le skill est la façon de rendre la structure suffisamment bon marché pour être réellement déployée sur chaque poste.
Points de vigilance
Surcharge des intervieweurs par le même intervieweur attribué partout.Protection : l’étape d’attribution dans le skill impose « aucun intervieweur dans plus d’une étape du même loop » comme règle stricte. Le tableau d’attribution fait remonter un intervieweur de secours par étape pour que le recruteur ait un fallback quand le principal est indisponible, plutôt que de réutiliser le principal dans deux étapes.
Signal redondant entre les étapes.Protection : la passe d’expérience candidat relit le loop assemblé et signale toute compétence sondée dans plus d’une étape. Le tableau de mapping compétence-vers-étape en tête de l’output du loop rend la redondance visible pour le hiring manager lors de la révision.
Expérience candidat négligée.Protection : la passe d’expérience candidat est une étape séparée et nommée dans le skill plutôt qu’une phrase au bas du loop. Elle impose des plafonds de temps total (5 heures IC, 7 heures leadership), des plafonds d’intervieweurs distincts (6), des suggestions de take-home pour les compétences qui gonflent le loop, et des TODOs d’accommodation de fuseau horaire. Sans cette passe, « un entretien de 30 minutes de plus » s’accumule invisiblement.
Dérive de calibration dans un seul loop.Protection : le bloc de rubric émis par étape inclut des descriptions d’ancres par niveau de score extraites de la bibliothèque de compétences, pas un texte libre « notez de 1 à 5 ». Les ancres sont ce qui maintient la calibration quand le même candidat est scoré par quatre intervieweurs différents dans le même loop. Rubric vague → scores vagues → débrief qui re-débat chaque dimension par anecdote.
Le hiring manager valide la conception à la légère.Protection : le skill s’arrête au point de contrôle de révision et écrit dans des fichiers. Il n’y a pas d’action « publier dans l’ATS ». Le HM doit ouvrir le fichier et le modifier avant de configurer le loop — cette friction est intentionnelle. Si les HMs commencent à signer sans lire, le contenu du loop dérive loin des priorités du poste et le skill cesse d’amortir son temps économisé.
Calibration obsolète des intervieweurs.Protection : la matrice d’intervieweurs a une colonne « Dernier entretien ». Les cellules de plus de 6 mois déclenchent une re-calibration avant que l’intervieweur ne soit à nouveau attribué. Quand l’intelligence d’entretien révèle des questions qui ne produisent pas de signal utile, mettez à jour les ancres de la bibliothèque de compétences et le skill émet les nouvelles ancres à la prochaine exécution.
Stack
Le bundle de skill se trouve dans apps/web/public/artifacts/interview-loop-builder-skill/ et contient :
SKILL.md — la définition du skill avec le frontmatter, les règles d’invocation, les inputs, la méthode et les points de vigilance associés aux gardes
references/1-competency-library.md — la taxonomie de compétences avec des descriptions d’ancres par niveau de score par tranche de niveau ; à remplir par fonction avant l’exécution
references/2-interviewer-strengths.md — la matrice du pool d’intervieweurs éligibles avec une couverture calibrée par compétence ; à remplir par équipe avant l’exécution
references/3-loop-output-format.md — le format Markdown littéral émis par le skill, y compris la mise en page du squelette de scorecard
Outils utilisés par le workflow : Claude (le modèle), Ashby ou Greenhouse (l’ATS où le HM configure le loop conçu), BrightHire ou Metaview (intelligence d’entretien dont le signal alimente le réglage des ancres de la bibliothèque de compétences). S’associe directement avec le rédacteur de JD en amont et le résumé de débrief d’entretien en aval.
---
name: interview-loop-builder
description: Take a job description, level, must-have competencies, and an interviewer pool with strengths, and produce a complete interview loop design — stage progression, per-stage rubric, behavioral questions per dimension, and interviewer assignments paired with the rubric dimension each one is scoring. Stops at a hiring-manager review gate before the loop is configured in the ATS.
---
# Interview loop builder
## When to invoke
Use this skill when a recruiter or hiring manager has a confirmed opening, an approved JD, and needs the structured interview loop designed before the first candidate moves into the screen stage. Take the JD, the role's level, the must-have competencies, and the eligible interviewer pool with each interviewer's calibrated strengths, and produce a Markdown loop design plus per-stage scorecard scaffolds.
Do NOT invoke this skill for:
- **Auto-scheduling.** This skill designs the loop; it does not schedule. Calendar coordination, interviewer-availability matching, and candidate-facing booking links are Ashby Scheduling, Greenhouse Scheduling, or Goodtime's job. Mixing design and scheduling in one skill couples two failure modes that should fail independently.
- **Replacing the rubric design with the hiring manager.** The skill maps competencies to a rubric *dimension* and writes anchor descriptions per score level, but the actual rubric per role family is owned by the hiring manager and the head of the function. If `references/1-competency-library.md` is empty or all-template, the skill refuses and surfaces a TODO rather than inventing a rubric for a function it has no calibrated signal on.
- **Generic templated loops without role-specific calibration.** If the inputs do not name the level, the must-have competencies, or the interviewer pool, the skill refuses. A four-stage loop with generic "behavioral", "technical", "system design", "leadership" labels passes for structured but is not — every candidate gets the same questions regardless of role priorities, which defeats the point.
- **Roles below a defined complexity threshold.** A two-week contractor role does not need a four-stage loop. The skill warns and suggests a one-stage screen if the role is contract, hourly, or under 6 months expected tenure.
## Inputs
- Required: `job_description` — path to a Markdown file (typically the output of the JD-writer skill, or a manually authored JD).
- Required: `level` — one of `IC1`, `IC2`, `IC3`, `IC4`, `IC5`, `IC6`, `M1`, `M2`, `M3`, `Director`, `VP`. Drives loop length and the competency-to-stage mapping.
- Required: `must_have_competencies` — array of 3-6 competency IDs drawn from `references/1-competency-library.md`. The skill maps each to a stage and refuses if more than 6 are provided (loop length blows out, signal per interview drops).
- Required: `interviewer_pool` — path to `references/2-interviewer-strengths.md` filled in for the role's function, listing each eligible interviewer with their calibrated strengths (which competencies they have been calibrated to score on what level bands).
- Optional: `loop_length_max` — hard cap on number of post-screen stages, default 4. Above 5, the skill warns about candidate-experience cost.
- Optional: `time_zone` — interviewer/candidate timezone hint used in the candidate-experience pass to flag any cross-timezone stages that need an explicit accommodation.
## Reference files
Always read these from `references/` before generating the loop. They contain the user's competency taxonomy, the interviewer pool, and the output format. Without them, the loop is a template, not a design.
- `references/1-competency-library.md` — the team's calibrated competency taxonomy with rubric dimensions and behavioral-anchor descriptions per score level. Replace the template with your real library before running.
- `references/2-interviewer-strengths.md` — the eligible interviewer pool with each interviewer's calibrated strengths. The skill matches competencies to interviewers using this matrix.
- `references/3-loop-output-format.md` — the literal Markdown format the skill emits, including the per-stage rubric block, the interviewer-assignment table with rationale, and the candidate-experience summary.
## Method
Run these six steps in order. Do not parallelize — later steps depend on context from earlier steps, and the candidate-experience pass at the end deliberately re-reads the assembled loop to catch overload that is invisible while assigning each stage in isolation.
### 1. Validate inputs
Open `job_description`, `references/1-competency-library.md`, and `references/2-interviewer-strengths.md`. Confirm:
- Each ID in `must_have_competencies` exists in the competency library. Unknown IDs → stop and surface them.
- The interviewer pool contains at least one interviewer calibrated on each must-have competency at the role's level. If a competency has no calibrated interviewer, surface a TODO ("hire / calibrate an interviewer for {competency} at {level} before designing this loop") and stop.
- The level falls inside the range the competency library has anchor descriptions for. Designing a Director loop with an IC-only library produces inflated rubrics; refuse.
### 2. Map competencies to stages
For each must-have competency, decide the stage where it is best evaluated. The mapping is opinionated:
- **Recruiter screen** evaluates fit, interest, comp alignment, and basic must-have-skill confirmation. Never a competency dimension on the rubric — recruiters do not score the rubric.
- **Hiring-manager screen** evaluates the top 1-2 competencies that most differentiate hire / no-hire on this role. The HM is the highest-signal interviewer; spending HM time on lower-priority competencies wastes calibration.
- **On-site loop** spreads remaining competencies one-per-interview where possible. One competency per interview is the engineering choice — bundling two competencies into one 60-minute interview produces shallower signal on both, and it makes the rubric harder for the interviewer to apply in the moment.
- **Working-session / take-home** (optional, only for IC4+ technical roles) evaluates competencies that need extended time or written artefact (system design, written communication, code review depth).
The output of this step is a `competency → stage` table with the rationale for each placement.
### 3. Design the per-stage rubric
For each post-screen stage, generate the rubric block. Each rubric dimension corresponds to one competency from step 2. For each dimension:
- Pull the anchor descriptions from `references/1-competency-library.md` for the candidate's level band.
- Generate 3-5 behavioral questions that probe the dimension. Each question must reference the situation / behavior / outcome shape; hypothetical "what would you do if…" questions are excluded by default because they reward articulate guessing over evidenced experience.
- Generate one suggested probing follow-up per question for the interviewer to use when the candidate's first answer is shallow.
The choice to include anchors and follow-ups in the output (rather than just the questions) is what separates a usable scorecard from "here are some questions, score it from 1 to 5". Without anchors, calibration drifts within a single loop.
### 4. Assign interviewers with rationale
For each post-screen stage, propose 1-3 interviewer candidates from the eligible pool. Match by:
- Calibration fit — the interviewer is calibrated on this competency at this level band. Hard requirement.
- Load balance — no interviewer is assigned to more than one stage in the same loop. Prevents the "only one person actually evaluates this candidate" failure mode where a single interviewer dominates the debrief.
- Diversity of perspective — where the eligible pool allows, propose at least one interviewer from outside the hiring team to reduce consensus bias in the debrief.
Output: an assignment table with the rationale per assignment ("Jamie calibrated at IC4 on systems-design; Priya outside the hiring team, last interviewed at this level 6 weeks ago").
### 5. Candidate-experience pass
Re-read the assembled loop and check, in order:
- Total interview time across all stages. Above 5 hours active for an IC role or 7 hours for a leadership role, flag and suggest moving one competency to a take-home.
- Number of distinct interviewers the candidate meets. Above 6, flag ("loop fatigue").
- Stages that require the candidate to repeat the same story. If two stages probe the same competency, surface as redundant.
- Cross-timezone stages without an accommodation note. Surface a TODO for the recruiter.
The choice to do this as a separate step rather than during stage design is deliberate: while assigning each stage in isolation it is easy to add "one more 30-minute conversation"; only by re-reading the full assembled loop does the candidate-side cost become legible.
### 6. Hiring-manager review gate
Stop. Write the loop design to `loop.md` per the format in `references/3-loop-output-format.md`. Write each stage's scorecard scaffold to `scorecards/<stage>.md`. Do not push anything to Ashby, Greenhouse, or Lever. Do not mark the role as "loop ready" in the ATS. Surface the path to both files and exit.
The hiring manager's job from here: read the loop, validate the competency-to-stage mapping reflects the actual role priorities, edit the questions, and configure the loop in the ATS. The skill does not re-enter the loop until the hiring manager confirms changes for a v2 design.
## Output format
```markdown
# Interview loop — {Role title} ({level})
Generated: {ISO timestamp} · Competencies: {n} · Stages: {n} · Total active time: {hours}
## Competency → stage mapping
| Competency | Stage | Rationale |
|---|---|---|
| Systems design | On-site Interview B | Highest differentiator at IC5; needs 60min for depth |
| Stakeholder influence | HM screen | Top hire/no-hire signal for this role |
| ... | ... | ... |
## Stage 1: Recruiter screen (30 min)
- Goal: confirm fit, interest, must-have-skill basics, comp alignment
- Key questions: ...
- Disqualifying signals: ...
- Not on rubric (screen, not scored)
## Stage 2: Hiring-manager screen (45 min)
- Goal: depth on {top 1-2 competencies}
- Rubric dimensions: {dim 1}, {dim 2}
- Behavioral questions:
1. {Question} — Probe: {follow-up}
2. ...
- Scorecard scaffold: `scorecards/02-hm-screen.md`
## Stage 3: On-site Interview A — {Competency} (60 min)
- Rubric dimension: {dim}
- Anchor descriptions ({level band}):
- 5 — {anchor}
- 4 — {anchor}
- 3 — {anchor}
- 2 — {anchor}
- 1 — {anchor}
- Behavioral questions:
1. {Question} — Probe: {follow-up}
2. ...
- Scorecard scaffold: `scorecards/03-onsite-a.md`
## Suggested interviewer assignments
| Stage | Primary | Backup | Rationale |
|---|---|---|---|
| HM screen | {HM name} | — | hiring manager |
| Onsite A — Systems design | Jamie L. | Priya R. | Jamie calibrated IC5 systems-design; Priya outside hiring team |
| ... | ... | ... | ... |
## Stage N: Debrief
- Format: independent scoring submitted before discussion
- Decision criteria: {explicit thresholds — e.g. "no rubric dimension < 3, aggregate >= 16"}
## Candidate-experience pass
- Total active interview time: {hours}
- Distinct interviewers: {n}
- Cross-timezone stages: {none | list with accommodation TODO}
- Redundant signal flagged: {none | list}
- Take-home recommendation: {none | move {competency} to take-home}
## Open TODOs for hiring manager
- ...
```
## Watch-outs
- **Interviewer overload from the same person being assigned everywhere.** *Guard:* step 4 enforces "no interviewer in more than one stage of the same loop" as a hard rule. The assignment table surfaces backup interviewers per stage so the recruiter has a fallback when the primary is unavailable, rather than re-using the primary in two stages.
- **Redundant signal across stages.** *Guard:* the candidate-experience pass in step 5 re-reads the loop and flags any competency probed in more than one stage. The competency-to-stage table in the output makes redundancy visible to the hiring manager in review.
- **Candidate experience neglected.** *Guard:* the candidate-experience pass in step 5 is a separate, named step rather than a sentence at the bottom of the loop. It enforces total-time caps, distinct-interviewer caps, take-home suggestions for competencies that bloat the loop, and timezone accommodation TODOs.
- **Calibration drift inside a single loop.** *Guard:* the rubric block emitted in step 3 includes anchor descriptions per score level pulled from the competency library, not free-text "rate 1 to 5". Anchors are the thing that holds calibration when the same candidate is scored by four different interviewers.
- **Hiring manager rubber-stamps the design.** *Guard:* skill stops at the review gate in step 6 and writes to files. There is no "publish to ATS" action defined anywhere in this skill. The HM has to open the file and edit it before configuring the loop.
- **Generic loops where role specificity matters.** *Guard:* step 1 refuses to run if `must_have_competencies` is empty or if the interviewer pool is missing calibrated coverage. The skill never falls back to a "default loop" for the function.
# Competency library — TEMPLATE
> Replace this template's contents with your team's actual competency
> library. The interview-loop-builder skill reads this file on every
> run; without your real library, the loop output is generic and the
> rubric anchors are uncalibrated.
## How to use
Each competency has:
- A short ID (used by `must_have_competencies` in the skill input)
- A one-sentence definition
- The level bands it has anchor descriptions for
- Anchor descriptions per score level (1-5) per level band
The skill maps each competency to a stage and emits the anchors for the candidate's level band into the per-stage rubric.
## Coverage matrix
| Competency ID | Definition | Bands covered |
|---|---|---|
| systems-design | Designs systems that meet current requirements while preserving headroom for known future needs. | IC3, IC4, IC5, IC6 |
| stakeholder-influence | Builds shared understanding and commitment across stakeholders without formal authority. | IC4, IC5, IC6, M1, M2, M3 |
| technical-depth | Reasons from first principles in the candidate's primary technical domain. | IC1, IC2, IC3, IC4, IC5, IC6 |
| ownership | Drives ambiguous problems to resolution, including the parts not in the original scope. | IC2, IC3, IC4, IC5, IC6, M1, M2 |
| communication-written | Writes documents that move decisions forward without a meeting. | IC3, IC4, IC5, IC6, M1, M2, M3 |
| people-leadership | Hires, develops, and retains a high-performing team. | M1, M2, M3, Director, VP |
| strategic-thinking | Identifies the right problem to solve before optimizing the solution. | IC5, IC6, M2, M3, Director, VP |
## Per-competency anchors
### systems-design (IC4 band)
- **5** — Designs the system end-to-end including failure modes, upgrade paths, and observability. Names trade-offs explicitly with reasoning per axis (latency, cost, complexity, blast radius).
- **4** — Designs the happy path and the most likely failure modes. Names trade-offs but reasoning is uneven across axes.
- **3** — Designs the happy path. Identifies failure modes when prompted. Trade-offs implicit, surfaced under follow-up questioning.
- **2** — Designs a workable system but misses obvious failure modes or scaling cliffs. Trade-offs not articulated.
- **1** — Designs a system that does not meet stated requirements, or cannot articulate why a design is structured as proposed.
> Replace the IC4 anchors above with your real anchors. Add anchor
> blocks for IC3, IC5, and IC6 in the same shape.
### stakeholder-influence (M2 band)
- **5** — Names the specific stakeholders, their incentives, the surface area of the disagreement, and the sequence of conversations that produced commitment. Outcome was a documented decision change.
- **4** — Names the stakeholders and incentives, walks through conversations, but the outcome description is fuzzy.
- **3** — Walks through one or two conversations. Stakeholder incentives are inferred under prompting.
- **2** — Describes the disagreement and the resolution but cannot describe the work between them.
- **1** — Describes a meeting outcome with no underlying stakeholder work.
> Replace the M2 anchors above with your real anchors. Add anchor
> blocks for IC4, IC5, IC6, M1, M3 in the same shape.
## Calibration discipline
When you add or change anchors:
- Run a calibration session with at least 3 interviewers scoring the same recorded interview. If their scores diverge by more than 1 point, the anchors are not calibrated yet.
- Date each change. The skill does not version anchors automatically; if you change an anchor mid-loop, the consistency of the loop is on you.
- Retire anchors that the calibration set cannot reproduce. Vague anchors are worse than no anchors — they create the illusion of structure.
## Last edited
{YYYY-MM-DD} — update on every material change.
# Interviewer strengths matrix — TEMPLATE
> Replace this template's contents with your team's actual interviewer
> pool and calibrated strengths. The interview-loop-builder skill
> reads this file on every run; without it, the assignment table is
> guessed rather than matched.
## How to use
Each row is one eligible interviewer. Columns are the competency IDs from `1-competency-library.md`. Each cell is the level band(s) the interviewer is calibrated to score that competency on. Empty cell = not calibrated; the skill will not assign.
The skill reads this matrix in step 4 (interviewer assignment) and matches by:
1. Calibration fit (interviewer is calibrated on the competency at the candidate's level band).
2. Load — at most one stage per loop per interviewer.
3. Diversity — at least one interviewer from outside the hiring team when the eligible pool allows.
## Pool
| Interviewer | Team | systems-design | stakeholder-influence | technical-depth | ownership | communication-written | people-leadership | strategic-thinking | Last interview (date) |
|---|---|---|---|---|---|---|---|---|---|
| Jamie L. | Platform | IC4, IC5 | — | IC3, IC4 | IC4 | — | — | — | 2026-04-19 |
| Priya R. | Data | — | IC4, IC5, M1 | IC4 | IC4, IC5 | IC4, IC5 | — | — | 2026-04-22 |
| Marcus T. | Product | — | IC5, M1, M2 | — | IC5 | M1, M2 | M1, M2 | M2 | 2026-04-12 |
| Aiko S. | Eng leadership | IC5, IC6 | M1, M2, M3 | IC5 | IC5, M1 | M2, M3 | M1, M2, M3 | M2, M3, Director | 2026-04-26 |
> Replace the rows above with your real interviewer pool. The columns
> are the competency IDs you defined in `1-competency-library.md`.
## Calibration discipline
When you add an interviewer or extend an interviewer's coverage:
- They sit shadow on at least 2 interviews at the new level band, then reverse-shadow (they score, the calibrated interviewer audits) on at least 2 more.
- Both calibrated interviewer and new interviewer sign off in the matrix before the cell is added.
- Retire a calibration band if the interviewer has not used it in 6 months. The "Last interview" column is the trigger to re-calibrate.
## Outside-the-hiring-team rule
The skill prefers at least one interviewer outside the hiring team per loop, to reduce consensus bias in debriefs. To make this work:
- Tag each interviewer's `Team` accurately.
- Ensure the eligible pool for each role family includes at least 2 outside-team interviewers per must-have competency at the role's level. If it does not, the skill will assign in-team only and surface a TODO ("expand cross-team calibration for {competency}").
## Last edited
{YYYY-MM-DD} — update on every calibration change.
# Loop output format — TEMPLATE
> The interview-loop-builder skill emits its output in the format
> below. This file documents the format so the team can adjust before
> running the skill at scale; the skill reads this file as the literal
> template, not a guideline.
## File layout
The skill writes:
- `loop.md` — the loop design, in the format below.
- `scorecards/<NN>-<stage-id>.md` — one scorecard scaffold per post-screen stage, with the rubric block prefilled and an empty scoring section.
## loop.md format
```markdown
# Interview loop — {Role title} ({level})
Generated: {ISO timestamp}
Competencies: {n}
Stages: {n}
Total active interview time: {hours}h
Distinct interviewers: {n}
## Inputs summary
- JD: {path}
- Level: {level}
- Must-have competencies: {comma-separated IDs}
- Interviewer pool: {path to filled interviewer-strengths matrix}
- Loop length cap: {n}
- Time zone hint: {tz | not provided}
## Competency → stage mapping
| Competency | Stage | Rationale |
|---|---|---|
## Stage 1: Recruiter screen (30 min)
Goal, key questions, disqualifying signals. Not on rubric.
## Stage 2: Hiring-manager screen (45 min)
Goal, rubric dimensions, behavioral questions with probes, scorecard
scaffold link.
## Stage 3..N: On-site interviews (60 min each)
For each stage:
- Rubric dimension (single competency)
- Anchor descriptions for the candidate's level band (5 lines, one
per score level, pulled from competency library)
- Behavioral questions with probes (3-5)
- Scorecard scaffold link
## Suggested interviewer assignments
| Stage | Primary | Backup | Rationale |
|---|---|---|---|
## Stage N+1: Debrief
Format (independent scoring before discussion), decision criteria
(explicit thresholds), debrief facilitator.
## Candidate-experience pass
- Total active interview time
- Distinct interviewers
- Cross-timezone stages with accommodation TODOs
- Redundant signal flagged
- Take-home recommendation if loop is over the time cap
## Open TODOs for hiring manager
- ...
```
## scorecards/<NN>-<stage-id>.md format
```markdown
# Scorecard — {Stage} ({Competency})
**Candidate:** {name}
**Interviewer:** {name}
**Date:** {YYYY-MM-DD}
**Level:** {level}
## Rubric dimension: {Competency}
Anchor descriptions ({level band}):
- 5 — {anchor}
- 4 — {anchor}
- 3 — {anchor}
- 2 — {anchor}
- 1 — {anchor}
## Behavioral questions
1. {Question}
- Probe: {follow-up}
- Notes:
2. ...
## Scoring
- Score: ___ / 5
- Evidence (cite candidate's words for the score):
- Hire / no-hire on this dimension: ___
- One-line rationale:
## Submit
Independent scoring submitted to debrief before discussion.
```
## What the format enforces
- Every rubric dimension has anchor descriptions inline. No "rate 1 to 5" without anchors.
- Every behavioral question has a probe. Interviewers do not have to invent follow-ups in the moment.
- Every interviewer assignment has a rationale. The hiring manager can audit why a person was assigned without re-running the skill.
- The candidate-experience pass is a section, not a sentence.
- Open TODOs are explicit. The skill never silently leaves a gap.
## Last edited
{YYYY-MM-DD}
