SKILL·741738

vertical-hr-recruiting

avelikiy
更新于 23 days ago
3 次查看
53
11
53
在 GitHub 上查看
设计aiautomationdesigndata

关于

This skill provides essential HR and recruiting domain knowledge—covering ATS, onboarding, compliance, and scheduling—to ensure specifications accurately reflect legal and workflow constraints. It is applied when architects or PMs write specs for HR-related products to prevent naive, generic CRUD designs. Use it when working on documents involving candidates, offers, shifts, or compliance data within the defined architecture paths.

快速安装

Claude Code

推荐
主要方式
npx skills add avelikiy/great_cto -a claude-code
插件命令备选方式
/plugin add https://github.com/avelikiy/great_cto
Git 克隆备选方式
git clone https://github.com/avelikiy/great_cto.git ~/.claude/skills/vertical-hr-recruiting

在 Claude Code 中复制并粘贴此命令以安装该技能

技能文档

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 stagesapplied → screen → interview → offer → hired (plus rejected / 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→hired enum 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

EntityMust includeWhy
Requisitionapproval state, headcount, stage confighiring is per-req; stages vary
Candidatestage history, scorecards, EEO (segregated store)audit trail + bias defense; EEO must not leak into decision view
Offer → Onboardingcarries candidate data forward (no re-entry)this IS the wedge; the handoff is the gap
OnboardingTaskdeadline field (I-9 3-day timing)compliance is time-bound, not soft
Shiftcoverage rules, overtime flag, swap/approval statea schedule must be valid, not just full

5. Per-product notes

productarchetypewedgethe one domain thing
atscrudcrowded market — needs a sharp angle, not "another tracker"configurable-per-req pipeline stages + structured scorecards; don't ship a generic Kanban
onboardingcrudthe offer→onboard data-carry gap incumbents admit is unsolvedcarry candidate data forward with zero re-entry; I-9 tasks with 3-day deadlines
workforce-schedulingbookingshift scheduling for hourly teamscoverage rules + overtime + swap/coverage approval, not a bare calendar
engagementcrmengagement surveys for SMBeNPS 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).

GitHub 仓库

avelikiy/great_cto
路径: skills/vertical-hr-recruiting
0
agentic-codingclaude-code-pluginclaude-code-skillsclaude-code-subagentscode-reviewcto
FAQ

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.

相关推荐技能

executing-plans
设计

该Skill用于当开发者提供完整实施计划时,以受控批次方式执行代码实现。它会先审阅计划并提出疑问,然后分批次执行任务(默认每批3个任务),并在批次间暂停等待审查。关键特性包括分批次执行、内置检查点和架构师审查机制,确保复杂系统实现的可控性。

查看技能
requesting-code-review
设计

该Skill可在完成任务、实现主要功能或合并代码前自动调度代码审查子代理,确保实现符合需求和计划。它支持通过指定git SHA范围进行精准的代码变更审查,帮助开发者在关键节点及时发现潜在问题。核心原则是"早审查、勤审查",适用于开发流程的各个关键阶段。

查看技能
connect-mcp-server
设计

这个Skill指导开发者如何将MCP服务器连接到Claude Code,支持HTTP、stdio和SSE三种传输协议。它涵盖了从安装配置到认证安全的完整流程,适用于集成GitHub、Notion、数据库等外部服务。当开发者需要添加集成、配置外部工具或提及MCP相关功能时,这个Skill能提供实用的操作指南。

查看技能
web-cli-teleport
设计

该Skill帮助开发者根据任务特性选择Claude Code的Web或CLI界面,并指导如何在两种环境间无缝迁移会话。它能分析任务复杂度、迭代需求等要素,推荐最优工作界面和工作流。关键特性包括会话状态管理、环境切换指导和上下文优化建议。

查看技能