| name | hiring-role-delivery-pack |
| description | Use when turning a client role, JD, kickoff call, hiring-manager intake, or recruitment search into a complete role-delivery pack. Applies to VFA/VettedAI/partner hiring work, including role calibration, internal role briefs, candidate-facing JDs, outreach emails, work-sample auditions, scoring rubrics, shortlist workflows, and live working docs. |
Hiring Role Delivery Pack
Use this skill when the user asks to prepare, improve, or operationalize a hiring search for a client/partner role. The goal is to turn scattered role context into a reusable operating pack, not just a polished JD.
Core Principle
Treat the JD as incomplete until the intake/HM call proves otherwise. The deliverable should capture:
- what the role really is;
- why it exists now;
- what success looks like;
- what candidates must prove;
- how VFA/VettedAI will source, assess, shortlist, and hand off.
Source Pattern To Learn From
Use Whiz Innovations as the benchmark when available:
/Users/USER/claude-workspace/VFA - Claude Cowork Assistant/07_Partners/Whiz Innovations/
That folder separates the search into:
- internal role brief;
- JD-only version;
- concise JD;
- outbound email draft.
The internal role briefs also include 30/60/90 outcomes, KPIs, red flags, work-sample scenarios, scoring rubric, screening questions, engagement flow, and candidate positioning.
Workflow
1. Gather and classify inputs
Read the available role artifacts:
- JD or role description;
- kickoff / hiring-manager notes;
- working docs;
- client emails;
- prior searches or analogous roles;
- known candidate pools or rejected profiles.
Keep source boundaries clear:
- Client-provided material is the client's view.
- Internal VFA/Vetted notes are operational interpretation.
- Prior searches are evidence, not proof that the same pool fits.
2. Run the calibration pass
Identify gaps before creating candidate-facing copy:
- Why this hire, why now?
- Who owns the role day to day?
- Who owns the technical/domain bar?
- Who must say yes before offer?
- What are the top 3 non-negotiables?
- What can flex?
- What backgrounds look right but fail?
- What is the location, comp, currency, and timeline reality?
- What existing candidates or rejected profiles should be considered?
- What interview stages already exist?
If details are unknown, produce a hiring-manager call guide instead of pretending the role is ready.
3. Build the internal role brief first
The internal role brief is the source of truth. Include:
- Role metadata: title, company, location, comp, reports to, timeline, engagement model.
- Company/context summary.
- Why this role exists.
- Current operating reality.
- Core ownership areas.
- 30/60/90-day outcomes.
- KPIs or success measures.
- Required experience and strong pluses.
- Traits that matter.
- What this role is not.
- Candidate red flags.
- Assessment/audition design.
- Scoring rubric.
- Recommended screening questions.
- Sourcing strategy.
- Engagement flow / RACI.
- Candidate positioning.
- Open questions and assumptions.
Write this for internal operators, not candidates. It can include risks, trade-offs, and client-management notes.
4. Split candidate-facing artifacts
Do not make one mega-doc do every job. Create separate artifacts as needed:
-
JD Only
- Complete candidate-facing role description.
- Confirmed scope only.
- No internal risks or client-management notes.
-
Concise JD
- Short version for posts, referrals, and quick sharing.
- Keep role hook, must-haves, comp/location, and application path.
-
Outbound Email Draft
- Written for the actual target pool.
- Lead with why the role is interesting.
- Include comp/location if shareable.
- Explain the VettedAI audition clearly: speed, fairness, proof of work.
-
Working Doc
- Live delivery tracker: action items, contacts, documents, platform links, sourcing status, candidate pipeline, shortlist decisions, feedback, open questions, and next follow-up.
5. Design the audition around proof of work
The audition should test the real job, not generic competence.
Good scenarios mirror early work:
- first-week diagnosis;
- 30/60/90 plan;
- messy operating snapshot;
- realistic customer/team issue;
- work sample tied to the role's core output;
- prioritization under ambiguity;
- stakeholder update or escalation note.
For technical roles, avoid generic coding tests unless code is the real signal. Prefer architecture/debug exercises, incident/postmortem review, system design, IaC review, API integration, or other domain-real tasks.
6. Score evidence, not polish
Rubrics should be 1-5 across role-specific dimensions. Score for:
- specificity;
- practical sequencing;
- judgment under ambiguity;
- communication clarity;
- evidence of ownership;
- commercial or technical realism;
- risk awareness;
- fit with the client's actual operating environment.
High-scoring candidates make reasonable assumptions, state them clearly, and move the work forward.
7. Shortlist with rationale
A shortlist should include:
- candidate summary;
- strongest evidence;
- score rationale;
- risks / watch-outs;
- interview focus;
- comp/location/availability notes;
- recommended next step.
Do not hand over scores without the reasoning. The client needs to know what to probe.
Output Checklist
For a fully operationalized role, produce:
If the role is not yet calibrated, produce the HM call guide first and list the unknowns blocking the pack.
Writing Style
Use plain founder/operator language:
- Say why the role exists in business terms.
- Use concrete outcomes, not generic responsibilities.
- Name what the role is not.
- Keep candidate-facing copy warm but direct.
- Avoid inflated titles unless the day-to-day really matches them.
- Avoid vague phrases like "dynamic environment" unless backed by specifics.
