Un Claude Skill que toma una descripción de puesto, el nivel del rol, las competencias imprescindibles y el pool de entrevistadores elegibles con las fortalezas calibradas de cada uno, y produce un diseño completo de loop — progresión por etapas, rúbrica por etapa con descripciones de anclaje, preguntas conductuales por dimensión y una tabla de asignación de entrevistadores con la justificación de cada elección. Luego se detiene en una compuerta de revisión del hiring manager antes de que se configure nada en el ATS. Reemplaza el “ya veremos el loop cuando haya un candidato en screen” con una pasada de diseño de 30 minutos que produce disciplina operativa.
Cuándo usarlo
Tienes un JD aprobado, un nivel confirmado y una lista de competencias imprescindibles que diferencian hire de no-hire en este rol.
Tienes una biblioteca de rúbricas de structured interviewing con descripciones de anclaje por nivel de puntuación por banda de nivel. La plantilla de competencias en apps/web/public/artifacts/interview-loop-builder-skill/references/1-competency-library.md muestra la forma; si no puedes completarla, todavía no tienes una rúbrica de la que este skill pueda tirar.
Tienes un pool de entrevistadores con fortalezas calibradas registradas por competencia por banda de nivel — ver references/2-interviewer-strengths.md en el bundle para la matriz.
Un hiring manager revisará el loop antes de que se configure en Ashby o Greenhouse. El skill escribe archivos y se detiene; no hace push al ATS.
Cuándo NO usarlo
Auto-scheduling. Este skill diseña el loop. No agenda entrevistas, no empareja calendarios ni envía links de booking de cara al candidato. Eso es Goodtime, Ashby Scheduling o Greenhouse Scheduling. Acoplar diseño y agendamiento en un solo skill acopla dos modos de falla que deben fallar de forma independiente.
Reemplazar el diseño de la rúbrica con el hiring manager. El skill emite descripciones de anclaje por nivel de puntuación tirando de la biblioteca de competencias, pero la biblioteca en sí — qué pinta tiene un 5 para systems-design en IC5 — la posee el hiring manager y el head of function. Si la biblioteca está vacía o es solo plantilla, el skill se niega y muestra un TODO en lugar de inventar anclajes de rúbrica para una función sobre la que no tiene señal calibrada.
Loops genéricos plantillados sin calibración específica al rol. Si los inputs no nombran el nivel, las competencias imprescindibles o el pool de entrevistadores elegibles, el skill se niega. Un loop de cuatro etapas con etiquetas genéricas “behavioral”, “technical”, “system design”, “leadership” se lee como estructurado pero no lo es. Cada candidato recibe las mismas preguntas independientemente de las prioridades del rol, lo que anula el sentido de la estructura.
Roles por debajo de un umbral definido de complejidad. Un rol de contractor de dos semanas no necesita un loop de cuatro etapas. El skill avisa y sugiere un screen de una sola etapa si el rol es contract, por hora o con tenencia esperada inferior a 6 meses.
Reemplazar la formación en behavioral interviewing. Las preguntas que emite el skill siguen la forma situación/comportamiento/resultado, pero los entrevistadores aún necesitan calibración entrenada para puntuar de forma consistente. El skill es el andamio; la formación es el prerrequisito.
Setup
Coloca el bundle. Pon apps/web/public/artifacts/interview-loop-builder-skill/SKILL.md en tu directorio de skills de Claude Code (o en Skills personalizados de claude.ai). El skill expone una función invocable: design_loop.
Completa la biblioteca de competencias. Copia references/1-competency-library.md a tu repo de equipo. Reemplaza cada placeholder con tus competencias reales, definiciones, bandas de nivel cubiertas y descripciones de anclaje por nivel de puntuación. El skill se niega a correr si la biblioteca es solo plantilla.
Completa la matriz de fortalezas de entrevistadores. Copia references/2-interviewer-strengths.md. Lista cada entrevistador elegible, su equipo y las bandas de nivel en las que está calibrado para puntuar cada competencia. La columna “Last interview” es el disparador para re-calibrar a los 6 meses de inactividad.
Configura los inputs por rol. Para un rol dado, pasa la ruta del JD, el nivel, un array de 3-6 IDs de competencias y una ruta a la matriz de fortalezas de entrevistadores ya completada. El skill emite loop.md y andamios de scorecard por etapa bajo scorecards/.
Dry-run sobre un loop cerrado. Córrelo sobre un rol que diseñaste manualmente el último trimestre. Compara el mapeo de etapas y las asignaciones de entrevistadores del skill con el diseño manual. Si divergen, lo que normalmente hay que afinar es la biblioteca de competencias o la matriz de entrevistadores, no el prompt del skill.
Qué hace realmente el skill
Seis pasos, en orden. El orden importa: la validación determinista y el mapeo ocurren antes de que el LLM genere los anclajes de rúbrica y las preguntas, y la pasada de candidate experience al final relee el loop ensamblado para detectar sobrecarga que es invisible mientras se asigna cada etapa de forma aislada.
Validar inputs. Cada ID de competencia existe en la biblioteca; el pool de entrevistadores tiene al menos una persona calibrada por competencia imprescindible al nivel del rol; el nivel cae dentro de las bandas cubiertas por la biblioteca. Detener con TODOs explícitos si falla cualquier check. Diseñar un loop de Director con una biblioteca solo de IC produce rúbricas infladas — este es el paso que lo previene.
Mapear competencias a etapas. El recruiter screen evalúa fit y básicos (nunca on-rubric). El HM screen toma las 1-2 competencias más diferenciadoras. El loop on-site reparte el resto una-por-entrevista cuando es posible. La regla de una-competencia-por-entrevista es opinionada — meter dos competencias en una entrevista de 60 minutos produce señal más superficial en ambas, y hace la rúbrica más difícil de aplicar en el momento.
Generar la rúbrica por etapa. Para cada etapa post-screen, tira las descripciones de anclaje para la banda de nivel del candidato desde la biblioteca de competencias. Genera 3-5 preguntas conductuales por dimensión siguiendo la forma situación/comportamiento/resultado, más una follow-up de profundización sugerida por pregunta. Las preguntas hipotéticas tipo “qué harías si” se excluyen por defecto — recompensan a los que adivinan articuladamente por encima de la experiencia evidenciada.
Asignar entrevistadores con justificación. Para cada etapa post-screen, propone 1-3 entrevistadores del pool. Empareja por fit de calibración (requisito duro), carga (ningún entrevistador en más de una etapa del mismo loop) y diversidad de perspectiva (al menos un entrevistador fuera del equipo de contratación cuando el pool lo permita). Cada asignación va con una cadena de justificación explícita.
Pasada de candidate experience. Releer el loop ensamblado. Tiempo total activo de entrevista por encima de 5 horas para IC o 7 para leadership → flag y sugerir un take-home. Más de 6 entrevistadores distintos → flag de fatiga del loop. Dos etapas explorando la misma competencia → flag de señal redundante. Etapas cross-timezone sin acomodación → mostrar un TODO.
Compuerta de revisión del hiring manager. Escribir loop.md y scorecards/<NN>-<stage-id>.md. Detenerse. El skill no define ninguna acción de “publicar al ATS”. El HM abre el archivo, edita y configura el loop en Ashby o Greenhouse él mismo.
El formato literal de salida y el layout del andamio de scorecard viven en references/3-loop-output-format.md en el bundle. El formato es fijo porque los consumidores aguas abajo — el entrevistador leyendo el scorecard, el facilitador del debrief consolidando puntuaciones — necesitan estructura predecible.
Realidad de costos
Por diseño de loop, en Claude Sonnet 4.5:
Tokens del LLM — típicamente 30-60k tokens de input (JD más biblioteca de competencias más matriz de entrevistadores más instrucciones del skill) y 10-20k tokens de output (loop más 3-5 andamios de scorecard con anclajes y preguntas). En Sonnet 4.5 eso es aproximadamente $0.20-0.40 por diseño de loop. Una función que contrata 8 roles por trimestre gasta menos de $5 en costo de modelo en este skill.
Tiempo de recruiter y hiring manager — la victoria vive aquí. Un diseño de loop manual desde cero con tirones de rúbrica calibrados son 90-120 minutos de tiempo de HM más recruiter en la call de diseño, otros 30-60 minutos documentando preguntas y asignaciones. El skill comprime eso a una pasada de revisión de 30 minutos sobre el loop generado. Por rol, eso son aproximadamente 90 minutos ahorrados de tiempo de IC senior o manager.
Tiempo de setup — 30 minutos por rol una vez que la biblioteca de competencias y la matriz de entrevistadores están completadas. La biblioteca y la matriz son el prerrequisito — net-new, eso lleva una sesión de calibración por banda de competencia, que es una inversión en structured interviewing, no setup de este skill.
Beneficio compuesto — los loops estructurados producen mejor quality of hire que los loops ad-hoc en cada estudio publicado de los últimos veinte años. La victoria del skill es hacer que “estructurado” sea el default en lugar de la excepción, eliminando el overhead de diseño por rol.
Métrica de éxito
Trackea tres números por rol por trimestre, en el ATS:
Lead time de diseño del loop — horas desde “rol aprobado” a “loop configurado en ATS”. Debería bajar materialmente después de meter el skill en el flujo. Si no, el cuello de botella es la revisión del HM, no el diseño — saca el loop más temprano en la secuencia de role-kickoff.
Acuerdo entre evaluadores en la rúbrica — por dimensión de competencia, qué tan seguido las puntuaciones independientes de los entrevistadores caen dentro de un punto. Debería pegar 80% o más en competencias calibradas. Por debajo de eso, lo que hay que afinar son las descripciones de anclaje en la biblioteca de competencias, no el skill.
Quality of hire a 12 meses — la métrica de arco largo que el loop está diseñado para mover. Compara cohortes contratadas a través de loops diseñados con el skill vs loops ad-hoc en la misma familia de roles. Si la cohorte diseñada con el skill no rinde mejor, re-examina el mapeo competencia-a-etapa antes de abandonar la estructura.
vs alternativas
vs las plantillas de structured interviewing de Ashby — Ashby posee el loop configurado, el rendering de scorecard y el debrief en un solo producto. Elige las plantillas de Ashby si quieres una UX gestionada y tu equipo va a vivir en el ATS. Elige este skill si quieres los anclajes de rúbrica, la matriz de fortalezas de entrevistadores y el mapeo competencia-a-etapa en tu propio repo, versionados, con el paso de diseño intercambiable a medida que la biblioteca de competencias evoluciona. La salida del skill es el input para la configuración del loop en Ashby, no un reemplazo.
vs loops genéricos plantillados — todo ATS trae plantillas default de cuatro etapas (“phone screen, HM screen, technical, on-site panel”). Pasan por estructuradas a primera vista pero no lo son. La misma plantilla se aplica a un Backend IC4 y a un CS Manager M2, con las mismas preguntas genéricas, sin importar qué competencias realmente diferencian hire de no-hire en cada rol. El skill se gana sus 30 minutos de setup en el segundo rol porque el diseño está calibrado por rol en lugar de ser one-size-fits-all.
vs diseño DIY del loop por el hiring manager — un HM senior puede diseñar un buen loop desde cero en 90-120 minutos. Tienden a no hacerlo, porque bajo presión de plazos reutilizan el último loop que corrieron, sin importar el fit. La victoria del skill no es “diseña mejor que un HM experimentado en su pico”; es “diseña tan bien como un HM experimentado de forma consistente, en todos los roles y todas las semanas”. La consistencia es el beneficio compuesto.
vs ningún loop estructurado en absoluto — los meta-análisis publicados sobre structured interviewing sitúan a las entrevistas estructuradas en aproximadamente el doble de validez predictiva que las no estructuradas para el desempeño en el puesto. Si tu status quo es no estructurado, el skill no es la pregunta — adoptar estructura sí lo es. El skill es cómo hacer la estructura lo suficientemente barata como para realmente shipearla en cada rol.
A vigilar
Sobrecarga del entrevistador por la misma persona asignada en todas partes.Guard: el paso de asignación en el skill aplica “ningún entrevistador en más de una etapa del mismo loop” como regla dura. La tabla de asignación muestra un entrevistador de respaldo por etapa para que el recruiter tenga un fallback cuando el primario no esté disponible, en lugar de re-usar al primario en dos etapas.
Señal redundante entre etapas.Guard: la pasada de candidate experience relee el loop ensamblado y marca cualquier competencia explorada en más de una etapa. La tabla de mapeo competencia-a-etapa al inicio de la salida del loop hace visible la redundancia para el hiring manager en el momento de la revisión.
Candidate experience descuidada.Guard: la pasada de candidate experience es un paso separado y nombrado en el skill, no una frase al pie del loop. Aplica caps de tiempo total (5 horas IC, 7 horas leadership), caps de entrevistadores distintos (6), sugerencias de take-home para competencias que inflan el loop y TODOs de acomodación de zona horaria. Sin esa pasada, “una conversación de 30 minutos más” se acumula de forma invisible.
Drift de calibración dentro de un mismo loop.Guard: el bloque de rúbrica emitido por etapa incluye descripciones de anclaje por nivel de puntuación tiradas de la biblioteca de competencias, no un “puntúa de 1 a 5” en texto libre. Los anclajes son lo que sostiene la calibración cuando el mismo candidato es puntuado por cuatro entrevistadores diferentes en el mismo loop. Rúbrica vaga → puntuaciones vagas → debrief que re-litiga cada dimensión por anécdota.
El hiring manager rubber-stampea el diseño.Guard: el skill se detiene en la compuerta de revisión y escribe a archivos. No hay acción de “publicar al ATS”. El HM tiene que abrir el archivo y editarlo antes de configurar el loop — esa fricción es intencional. Si los HMs empiezan a firmar sin leer, el contenido del loop drifta lejos de las prioridades del rol y el skill deja de ganarse el tiempo ahorrado.
Calibración de entrevistador stale.Guard: la matriz de entrevistadores tiene una columna “Last interview”. Las celdas con más de 6 meses disparan re-calibración antes de que el entrevistador sea asignado de nuevo. Cuando la interview intelligence revela preguntas que no están produciendo señal útil, actualiza los anclajes de la biblioteca de competencias y el skill emite los nuevos anclajes en la siguiente corrida.
Stack
El bundle del skill vive en apps/web/public/artifacts/interview-loop-builder-skill/ y contiene:
SKILL.md — la definición del skill con frontmatter, reglas de cuándo invocar, inputs, método y watch-outs apareados con guards
references/1-competency-library.md — la taxonomía de competencias con descripciones de anclaje por nivel de puntuación por banda de nivel; rellenar por función antes de correr
references/2-interviewer-strengths.md — la matriz del pool de entrevistadores elegibles con cobertura calibrada por competencia; rellenar por equipo antes de correr
references/3-loop-output-format.md — el formato Markdown literal que el skill emite, incluyendo el layout del andamio de scorecard
Herramientas que el workflow asume que ya usas: Claude (el modelo), Ashby o Greenhouse (el ATS donde el HM configura el loop diseñado), BrightHire o Metaview (interview intelligence cuya señal alimenta el ajuste de anclajes de la biblioteca de competencias). Empareja directamente con el JD writer aguas arriba y el interview debrief summary aguas abajo.
---
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}
