vertical-hr-recruiting
Acerca de
Esta habilidad proporciona conocimiento esencial del dominio de RR.HH. y reclutamiento—cubriendo ATS, incorporación, cumplimiento normativo y programación—para garantizar que las especificaciones reflejen con precisión las restricciones legales y de flujo de trabajo. Se aplica cuando los arquitectos o PMs redactan especificaciones para productos relacionados con RR.HH., para evitar diseños CRUD genéricos e ingenuos. Úsala al trabajar en documentos que involucren candidatos, ofertas, turnos o datos de cumplimiento dentro de las rutas de arquitectura definidas.
Instalación rápida
Claude Code
Recomendadonpx skills add avelikiy/great_cto -a claude-code/plugin add https://github.com/avelikiy/great_ctogit clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/vertical-hr-recruitingCopia y pega este comando en Claude Code para instalar esta habilidad
Documentación
Vertical: HR & recruiting — don't spec it naive
The incumbents (Workable, BambooHR, Greenhouse, Lever, Zoho Recruit, Manatal) have trained buyers to expect a hiring pipeline that works. A generic CRUD app fails the moment it meets EEO law, I-9 timing, or the offer→onboard handoff. Read this before speccing any of the four products — the domain has hard constraints, not just forms.
1. Domain vocabulary
- ATS — applicant tracking system; the system of record for hiring.
- Requisition (req) — an approved open role. Hiring happens against a req, not in a vacuum. Reqs have an approval workflow (hiring manager → finance/HR).
- Pipeline stages —
applied → screen → interview → offer → hired(plusrejected/withdrawn). Stages are configurable per req — engineering and sales hire differently. - Candidate vs applicant — an applicant applied to a specific req; a candidate is a person in your talent pool who may map to many applications over time. Don't conflate them.
- Sourcing — proactively finding candidates (vs inbound applications).
- Structured interview + scorecard — pre-defined questions + a rubric each interviewer scores. Reduces bias and legal exposure vs freeform notes.
- Offer letter — formal terms; triggers the offer→onboard transition on acceptance.
- EEO data — voluntary race/gender/veteran/disability self-ID, collected for reporting, segregated from hiring decisions (see §2).
- I-9 + E-Verify — employment eligibility verification; strict 3-day timing (§2).
- Onboarding checklist — tasks a new hire/employer must complete before/at start.
- time-to-hire / time-to-fill — core recruiting metrics (hire = offer accepted by a candidate; fill = req closed). Different denominators; report both correctly.
- Hourly vs salaried — drives scheduling, overtime (FLSA), and pay rules.
- Shift swap / coverage — hourly workers trade shifts; coverage rules say a slot can't go unstaffed below a threshold.
- eNPS — employee Net Promoter Score; the headline engagement-survey metric.
2. Non-obvious domain rules
- The offer→onboard handoff is the admitted gap. Incumbents openly concede onboarding is unsolved: data gets re-entered between the ATS and the HR/onboarding system. The whole onboarding product wedge is carry the candidate's data forward — zero re-entry.
- EEO/OFCCP data must be collected but kept OUT of the hiring-decision view. Mixing self-identified race/gender into the screen/interview UI is an anti-discrimination liability. Store it segregated; surface it only in aggregate compliance reports.
- Structured scorecards reduce bias and legal risk. They create a defensible, consistent record. Freeform-only interview notes are a disparate-impact landmine.
- I-9 has strict timing: Section 1 by the employee's first day, Section 2 (employer review of documents) within 3 business days of start. Onboarding tasks tied to I-9 carry a hard deadline, not a soft reminder.
- Workforce scheduling needs coverage rules + labor compliance. A schedule isn't valid just because slots are filled — it must respect minimum coverage, overtime (FLSA), predictive-scheduling / fair-workweek laws (advance-notice in some jurisdictions), and break rules.
- Reqs gate hiring. No offers without an approved req; req approval is a real workflow with a budget/headcount check, not a checkbox.
3. What a naive build gets wrong
- Hardcoded pipeline stages. A fixed
applied→hiredenum breaks the first time a customer wants a take-home or panel stage. Stages must be configurable per req. - EEO data in the candidate decision view. Putting self-ID fields on the candidate card the hiring manager sees is a legal-risk bug, not a UX choice. Segregate it.
- Onboarding that re-enters candidate data. Rebuilding name/email/role/comp from scratch is the gap incumbents have. If onboarding starts from a blank form, you built the incumbent's weakness, not our wedge.
- I-9 modeled as a generic checklist item. Without the 3-business-day deadline and Section 1 / Section 2 split, it's non-compliant.
- Scheduling as a calendar. Drag-and-drop shifts with no coverage minimum, no overtime flag, and no swap-approval flow is a toy, not a workforce tool.
4. Must-model entities
| Entity | Must include | Why |
|---|---|---|
| Requisition | approval state, headcount, stage config | hiring is per-req; stages vary |
| Candidate | stage history, scorecards, EEO (segregated store) | audit trail + bias defense; EEO must not leak into decision view |
| Offer → Onboarding | carries candidate data forward (no re-entry) | this IS the wedge; the handoff is the gap |
| OnboardingTask | deadline field (I-9 3-day timing) | compliance is time-bound, not soft |
| Shift | coverage rules, overtime flag, swap/approval state | a schedule must be valid, not just full |
5. Per-product notes
| product | archetype | wedge | the one domain thing |
|---|---|---|---|
| ats | crud | crowded market — needs a sharp angle, not "another tracker" | configurable-per-req pipeline stages + structured scorecards; don't ship a generic Kanban |
| onboarding | crud | the offer→onboard data-carry gap incumbents admit is unsolved | carry candidate data forward with zero re-entry; I-9 tasks with 3-day deadlines |
| workforce-scheduling | booking | shift scheduling for hourly teams | coverage rules + overtime + swap/coverage approval, not a bare calendar |
| engagement | crm | engagement surveys for SMB | eNPS as the headline metric; anonymity threshold so small teams can't deanonymize responses |
onboarding is the differentiated bet (solve the admitted gap). ats is the crowded one
— architect must name the sharp angle in the ARCH doc or it's dead on arrival.
6. Compliance (light)
Flag these in the ARCH doc; route AI-screening to a reviewer.
- EEO / OFCCP — collect voluntary self-ID; aggregate reporting; never in the decision path.
- I-9 / E-Verify — Section 1 by day one, Section 2 within 3 business days; model the deadline.
- Anti-discrimination — disparate impact in screening. If any product uses AI to
screen/rank candidates, flag it to
hr-ai-reviewer(or the AI-security reviewer) before senior-dev starts — automated screening is a high-risk surface. - Ban-the-box — many jurisdictions forbid asking criminal history before an offer. Don't put it on the application form by default.
- FLSA / overtime — scheduling must compute overtime for hourly workers; respect fair-workweek / predictive-scheduling laws where they apply.
- Data retention — candidate/applicant records have minimum retention (e.g. EEOC ~1 year) and deletion obligations (GDPR/CCPA right-to-erasure). State a retention policy.
Output
When applied, contribute a Domain constraints block to the architecture doc:
## Domain constraints (HR/recruiting)
- pipeline: stages configurable per req (not a fixed enum)
- EEO data: segregated store, excluded from decision view
- offer→onboard: candidate data carried forward, zero re-entry
- I-9: Section 2 deadline = start + 3 business days (modeled)
- scheduling: coverage rule = <min staffed>, overtime flag, swap-approval
- AI screening: <none | flagged to hr-ai-reviewer>
- retention: <policy + jurisdiction>
Cross-references
- [[vertical-onboarding]] — the import-first onboarding funnel; the offer→onboard data-carry here is the import that feeds first-run for the onboarding product.
- [[migration-ready-schema]] — model Candidate/Offer/Onboarding so data carries forward cleanly (the no-re-entry wedge depends on it).
- [[lifecycle-messaging]] — candidate-stage and onboarding-task notifications (offer sent, I-9 due, shift posted, survey open).
Repositorio GitHub
Frequently asked questions
What is the vertical-hr-recruiting skill?
vertical-hr-recruiting is a Claude Skill by avelikiy. Skills package instructions and resources that Claude loads on demand, so Claude can perform vertical-hr-recruiting-related tasks without extra prompting.
How do I install vertical-hr-recruiting?
Use the install commands on this page: add vertical-hr-recruiting to Claude Code as a plugin, or clone its repository into your skills directory, then restart Claude so it picks up the skill.
What category does vertical-hr-recruiting belong to?
vertical-hr-recruiting is in the Design category, tagged ai, automation, design and data.
Is vertical-hr-recruiting free to use?
Yes. vertical-hr-recruiting is listed on AIMCP and free to install. It runs inside Claude, so no separate service account is required to use the skill itself.
Habilidades relacionadas
Utilice la habilidad executing-plans cuando tenga un plan de implementación completo para ejecutar en lotes controlados con puntos de revisión. Esta habilidad carga y revisa críticamente el plan, luego ejecuta tareas en pequeños lotes (por defecto 3 tareas) mientras reporta el progreso entre cada lote para la revisión del arquitecto. Esto asegura una implementación sistemática con puntos de control de calidad integrados.
Esta habilidad despacha un subagente revisor de código para analizar los cambios en el código frente a los requisitos antes de proceder. Debe usarse después de completar tareas, implementar funciones principales o antes de fusionar con la rama principal. La revisión ayuda a detectar problemas de forma temprana al comparar la implementación actual con el plan original.
Esta habilidad proporciona una guía integral para que los desarrolladores conecten servidores MCP a Claude Code mediante transportes HTTP, stdio o SSE. Cubre la instalación, configuración, autenticación y seguridad para integrar servicios externos como GitHub, Notion y APIs personalizadas. Úsala al configurar integraciones MCP, al configurar herramientas externas o al trabajar con el Protocolo de Contexto del Modelo de Claude.
Esta habilidad ayuda a los desarrolladores a elegir entre las interfaces web y CLI de Claude Code mediante el análisis de tareas, y luego permite la teletransportación fluida de sesiones entre estos entornos. Optimiza el flujo de trabajo gestionando el estado y el contexto de la sesión al cambiar entre web, CLI o móvil. Úsala para proyectos complejos que requieren diferentes herramientas en varias etapas.
