MCP HubMCP Hub
SKILL·741738

vertical-hr-recruiting

avelikiy
更新日 23 days ago
3 閲覧
53
11
53
GitHubで表示
デザインaiautomationdesigndata

について

このスキルは、ATS、オンボーディング、コンプライアンス、スケジューリングを網羅した、人事・採用領域の必須知識を提供します。これにより、仕様が法的要件やワークフローの制約を正確に反映することを保証します。人事関連製品の仕様書をアーキテクトやプロジェクトマネージャーが作成する際に適用され、単純で汎用的なCRUD設計を防ぎます。定義されたアーキテクチャパス内で、候補者、採用内定、シフト、コンプライアンスデータに関する文書を作成する際に活用してください。

クイックインストール

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
デザイン

executing-plansスキルは、完全な実装計画があり、それを管理されたバッチでレビューチェックポイントを設けながら実行する場合に使用します。このスキルは計画を読み込んで批判的にレビューした後、小さなバッチ(デフォルトは3タスク)でタスクを実行し、各バッチの間に進捗状況を報告してアーキテクトのレビューを受けます。これにより、品質管理チェックポイントが組み込まれた体系的な実装が保証されます。

スキルを見る
requesting-code-review
デザイン

このスキルは、コードレビュアーサブエージェントを起動し、処理を進める前に要件に対してコード変更を分析します。タスク完了後、主要な機能の実装後、またはmainブランチへのマージ前などに使用すべきです。このレビューは、現在の実装と元の計画を比較することで、問題を早期に発見するのに役立ちます。

スキルを見る
connect-mcp-server
デザイン

このスキルは、開発者がHTTP、stdio、またはSSEトランスポートを使用してMCPサーバーをClaude Codeに接続するための包括的なガイドを提供します。GitHub、Notion、カスタムAPIなどの外部サービスを統合するためのインストール、設定、認証、セキュリティについて解説しています。MCP統合のセットアップ、外部ツールの設定、またはClaudeのModel Context Protocolを扱う際にご利用ください。

スキルを見る
web-cli-teleport
デザイン

このスキルは、タスク分析に基づいて開発者がClaude Code WebとCLIインターフェースの選択を支援し、これらの環境間でのシームレスなセッションテレポーテーションを可能にします。Web、CLI、モバイル環境を切り替える際のセッション状態とコンテキストを管理することで、ワークフローを最適化します。様々な段階で異なるツールを必要とする複雑なプロジェクトにご活用ください。

スキルを見る