vertical-hr-recruiting
À propos
Cette compétence fournit des connaissances essentielles du domaine des RH et du recrutement — couvrant les ATS, l'intégration, la conformité et la planification — pour garantir que les spécifications reflètent avec précision les contraintes légales et de flux de travail. Elle est utilisée lorsque les architectes ou chefs de projet rédigent des spécifications pour des produits liés aux RH, afin d'éviter des conceptions CRUD génériques et naïves. Utilisez-la lorsque vous travaillez sur des documents impliquant des candidats, des offres, des plannings ou des données de conformité dans les chemins d'architecture définis.
Installation rapide
Claude Code
Recommandénpx 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-recruitingCopiez et collez cette commande dans Claude Code pour installer cette compétence
Documentation
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).
Dépôt 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.
Compétences associées
Utilisez la compétence executing-plans lorsque vous disposez d'un plan de mise en œuvre complet à exécuter par lots contrôlés avec des points de contrôle de revue. Elle charge et examine le plan de manière critique, puis exécute les tâches par petits lots (3 tâches par défaut) tout en rapportant la progression entre chaque lot pour une revue par l'architecte. Cela garantit une mise en œuvre systématique avec des points de contrôle de qualité intégrés.
Cette compétence délègue un sous-agent réviseur de code pour analyser les modifications apportées au code par rapport aux exigences avant de poursuivre. Elle doit être utilisée après avoir terminé des tâches, implémenté des fonctionnalités majeures, ou avant une fusion vers la branche principale. La revue aide à détecter précocement les problèmes en comparant l'implémentation actuelle avec le plan initial.
Cette compétence fournit un guide complet permettant aux développeurs de connecter des serveurs MCP à Claude Code via les transports HTTP, stdio ou SSE. Elle couvre l'installation, la configuration, l'authentification et la sécurité pour intégrer des services externes tels que GitHub, Notion et des API personnalisées. Utilisez-la lors de la configuration d'intégrations MCP, de la configuration d'outils externes ou du travail avec le Protocole de Contexte de Modèle de Claude.
Cette compétence aide les développeurs à choisir entre les interfaces Web et CLI de Claude Code en fonction de l'analyse des tâches, puis permet une téléportation transparente des sessions entre ces environnements. Elle optimise le flux de travail en gérant l'état et le contexte de la session lors du passage entre le web, la CLI ou le mobile. Utilisez-la pour des projets complexes nécessitant différents outils à diverses étapes.
