AI prompts for HR professionals and recruiters

Write a job description.

ROLE: [JOB TITLE]
TEAM AND WHO THEY REPORT TO: [CONTEXT]
THE THREE THINGS THEY WILL ACTUALLY DO MOST DAYS: [LIST]
WHAT SUCCESS LOOKS LIKE AT 6 MONTHS: [OUTCOME]
HARD REQUIREMENTS: [NON-NEGOTIABLE SKILLS/CERTIFICATIONS]
NICE TO HAVE: [LIST]
WORK SETUP: [REMOTE/HYBRID/ONSITE, LOCATION, HOURS]
SALARY RANGE: [RANGE, or 'not disclosed']

Structure:
- Opening: two sentences on the actual problem this person solves. No company boilerplate.
- 'What you will do': 5-6 bullets, each starting with a verb, describing real work not responsibilities in the abstract
- 'What success looks like': the 6-month outcome, concretely
- 'You will probably be a fit if': 4-5 bullets describing experience, not years
- 'This is probably not for you if': 3 honest bullets - genuine downsides of the role
- Logistics: setup, location, salary, process steps and rough timeline

Rules:
- No 'rockstar', 'ninja', 'wear many hats', 'fast-paced environment', 'work hard play hard', 'like a family'
- Never state a years-of-experience number. Describe the experience instead.
- The 'not for you if' section must contain a real drawback, not a humblebrag.

Design a structured interview scorecard.

ROLE: [JOB TITLE]
THE FOUR COMPETENCIES THAT PREDICT SUCCESS: [LIST, or write 'suggest them' and infer from the role]
INTERVIEW LENGTH: [MINUTES]
INTERVIEWER'S LEVEL: [experienced hiring manager / first-time interviewer]

For each competency produce:
- A one-line definition of what good looks like in THIS role
- One primary behavioural question (past behaviour, not hypothetical)
- Two follow-up probes to use if the answer is vague
- A 1-4 rating scale where each level is described behaviourally. Level 1 and level 4 must be clearly distinguishable from a transcript.
- One 'red flag' answer pattern to watch for

Then produce:
- A time budget totalling the interview length, including 5 minutes for candidate questions
- An anti-bias note: for this specific role, name two things interviewers commonly mistake for competence

Rules:
- No hypothetical questions ('what would you do if'). Past behaviour only.
- Rating levels must describe observable behaviour, never 'strong' or 'weak'.
- Do not include culture-fit questions. Replace with a values-alignment question tied to a specific documented value if provided.

Assess this CV against the job description. Be calibrated, not generous.

JOB DESCRIPTION:
"""
[PASTE JD]
"""

CV:
"""
[PASTE CV]
"""

Produce:

1. HARD REQUIREMENTS - a table: Requirement | Evidence in CV (quote it) | Met / Partially / Not evidenced. 'Not evidenced' is different from 'not met' - say which.

2. WHAT THEY HAVE ACTUALLY DONE - strip the CV's framing and describe the underlying work in plain terms. Where a bullet describes a team achievement, say so.

3. GAPS AND RISKS - including unexplained date gaps, very short tenures, and claims with no supporting detail.

4. THE THREE QUESTIONS to ask at screening that would most reduce uncertainty about this specific candidate.

5. RECOMMENDATION - Advance / Advance with reservations / Decline, one sentence of reasoning.

Rules:
- Do not infer skills from job titles.
- Do not reward CV polish. A well-written CV for a weak match is still a weak match.
- Ignore name, age, gender, nationality, photograph, university prestige and address entirely. If the CV contains them, do not reference them.

Write candidate messages for a hiring decision.

ROLE: [JOB TITLE]
STAGE REACHED: [application / first interview / final interview]
DECISION: [offer / rejection / on hold]
FOR OFFERS: salary and key terms [DETAILS], start date [DATE], response deadline [DATE], next steps [STEPS]
FOR REJECTIONS: whether I can share feedback [yes/no], and the main reason [REASON]
COMPANY TONE: [DESCRIBE]

Write:
1. The message for this decision
2. If rejection after interview: 2-3 lines of specific, useful feedback that are fair and cannot be read as discriminatory (focus on job-related evidence from the interview)
3. A short phone script if I call first
4. A template version with [PLACEHOLDERS] for reuse

Rules: no false promises ("we'll keep you on file" unless we really will), no vague reasons, and never reference age, gender, family, religion, nationality, health or any protected characteristic.

Draft a performance review.

EMPLOYEE ROLE: [ROLE]
REVIEW PERIOD: [DATES]
THEIR GOALS FOR THE PERIOD: [PASTE]
MY RAW NOTES AND EXAMPLES: [PASTE EVERYTHING, MESSY IS FINE]
OVERALL DIRECTION I WANT TO CONVEY: [exceeding / on track / needs improvement]

Produce:

1. SUMMARY - three sentences. States the overall direction plainly in the first sentence.

2. GOAL REVIEW - a table: Goal | Outcome | Evidence | Met/Partially/Not met. Evidence must come from my notes. Where I have given no evidence for a goal, write [NO EVIDENCE PROVIDED] rather than inventing any.

3. STRENGTHS - maximum three. Each needs a specific example from my notes and a sentence on the impact it had.

4. DEVELOPMENT AREAS - maximum two. For each: the observable behaviour (not a personality trait), the impact, and one concrete thing to do differently. Never write 'needs to be more confident' - describe what they did or did not do.

5. NEXT PERIOD - two or three goals, each with a measurable outcome.

Rules:
- Every claim needs evidence from my notes or a [NO EVIDENCE PROVIDED] flag
- No personality assessment. Behaviour only.
- Do not soften the overall direction. If it is 'needs improvement', sentence one must say so.
- Do not use the sandwich structure.

Help me prepare for a difficult conversation with someone who reports to me.

THE ISSUE: [WHAT IS HAPPENING]
SPECIFIC INCIDENTS: [DATES AND WHAT HAPPENED - as factual as you can]
IMPACT: [ON THE TEAM, THE WORK, OR THEM]
WHAT I HAVE ALREADY TRIED: [PREVIOUS CONVERSATIONS OR SUPPORT]
OUTCOME I WANT: [WHAT CHANGES]
MY RELATIONSHIP WITH THEM: [CONTEXT]

Produce:

1. OPENING - exactly what to say in the first 30 seconds. Name the topic directly. No warm-up.
2. THE FACTS - my incidents restated as observable behaviour with impact, stripped of interpretation. Flag anything I have written as a judgement rather than an observation.
3. WHAT I MIGHT BE MISSING - three plausible explanations for this behaviour that I have not considered, including ones where the cause is me or the system.
4. QUESTIONS TO ASK - four, designed to let them explain rather than defend. Open, not leading.
5. WHAT GOOD LOOKS LIKE - the specific change, stated so both of us would know it when we see it.
6. IF IT GOES BADLY - responses for: they get upset, they disagree with the facts, they blame someone else, they say nothing.
7. WHAT I SHOULD NOT SAY - phrases to avoid in this specific conversation.

Do not write a script for the whole conversation. Prepare me, do not perform it for me.

Write a 30-60-90 day plan.

ROLE: [JOB TITLE]
SENIORITY: [LEVEL]
TEAM SITUATION: [e.g. replacing someone, new role, team in crisis, stable team]
THE PROBLEM THEY WERE HIRED TO SOLVE: [ONE SENTENCE]
KEY STAKEHOLDERS: [ROLES THEY MUST BUILD RELATIONSHIPS WITH]

For each of the three phases produce:
- The theme of the phase in four words
- LEARN: what they should understand by the end of it
- DO: concrete deliverables, with 'done when' criteria
- MEET: who, and the one question to ask each person
- MANAGER CHECKPOINT: the three questions the manager should ask at the end of the phase, and what a worrying answer sounds like

Calibration rules:
- Days 1-30: understanding and small reversible contributions only. No major changes.
- Days 31-60: first owned deliverable. One thing they own end to end.
- Days 61-90: a proposal or change that reflects their own judgement about the role.
- If the team situation is 'in crisis', compress this and say what you are trading off.

End with: the three earliest signals this hire is not working out, and by when you would see each.

Analyse this exit interview.

ROLE AND TENURE: [ROLE, HOW LONG THEY STAYED]
STATED REASON FOR LEAVING: [WHAT THEY SAID]
EXIT INTERVIEW NOTES:
"""
[PASTE]
"""
PREVIOUS EXITS FROM THIS TEAM (if any): [BRIEF NOTES, or 'none']

Produce:

1. STATED VS LIKELY - what they said, and what the notes suggest. Be explicit that the second is inference and mark confidence as high/medium/low. People rarely give the real reason in an exit interview.

2. FIXABLE VS NOT - separate causes into: within this manager's control, within the company's control, and outside anyone's control (life events, better offer elsewhere, career change).

3. SIGNALS WE MISSED - what in the notes suggests this was visible before they resigned, and when.

4. PATTERN CHECK - against previous exits if provided. Say plainly if there is no pattern; do not manufacture one from a single data point.

5. ACTIONS - only for things in the fixable columns. Maximum three. Each with the role who owns it.

Do not recommend an engagement survey.

Build a structured onboarding checklist.

ROLE: [JOB TITLE]
REPORTS TO: [MANAGER ROLE]
KEY RESPONSIBILITIES: [PASTE FROM JOB DESCRIPTION]
SYSTEMS THEY WILL USE: [LIST TOOLS/SOFTWARE]
EXISTING DOCUMENTATION: [LIST SOP NAMES, OR 'none']

Produce a checklist across four phases: Before day one, Week one, Weeks 2-4, Days 31-90.

For each phase give a table: Task | Owner (new hire / manager / IT / other) | Done when (an observable, checkable condition) | Depends on.

Rules:
- 'Done when' must be observable. 'Understands the CRM' is wrong; 'Has independently logged one new lead in the CRM' is right.
- Every system in the list needs an access-request task in 'Before day one', owned by someone other than the new hire.
- Include at least two tasks where the new hire produces something reviewable, not just consumes information.
- Flag with [DOC GAP] any task that needs documentation you said does not exist.

Help me write an AI use policy.

THE ORGANISATION: [SIZE, SECTOR, WHAT IT DOES]
WHO IT APPLIES TO: [everyone / specific teams]
WHAT PEOPLE ARE ALREADY DOING: [CURRENT USE, INCLUDING UNOFFICIAL]
WHAT WE ARE WORRIED ABOUT: [YOUR CONCERNS]
WHAT TOOLS ARE APPROVED: [IF ANY]
REGULATORY CONTEXT: [ANY SECTOR REQUIREMENTS]

Produce:

1. THE REALISTIC STARTING POINT - people are already using these tools, including where there is no policy. A policy that prohibits everything drives use underground, where there is no oversight at all and no way to know what data has gone where. Design for the actual situation.

2. THE STRUCTURE - a usable policy covers:
   - What tools are approved, and how to request one
   - What data may and may not be entered, which is the most important section
   - Where output may be used and where it may not
   - What must be disclosed and to whom
   - Who is accountable for output
   - What to do when unsure

3. THE DATA SECTION - the highest-risk area and the one to write most carefully. What may never be entered: credentials, customer personal data unless the tool is approved for it, confidential information covered by contracts, and anything regulated in my sector. Be specific rather than general, because a general rule is interpreted variously.

4. THE APPROVED TOOLS - why the distinction matters: consumer and enterprise tiers differ on data retention, training use and processing location. Say what to check before approving a tool and what the approval should record.

5. THE OUTPUT ACCOUNTABILITY PRINCIPLE - the central rule. The person who uses AI-assisted output is accountable for it as if they had produced it themselves. This is clearer than trying to enumerate every acceptable use and it is the rule that actually works.

6. THE VERIFICATION REQUIREMENT - what must be checked before output is used: facts, figures, citations, code, and anything a person will rely on. Say what level of checking different kinds of work require.

7. THE HIGH-CAUTION LIST - where AI-assisted output must not be the basis of a decision without qualified review: decisions about individuals, anything with legal or regulatory weight, safety-related material, and anything going to a customer as authoritative.

8. THE DISCLOSURE RULES - when to say AI was involved: to customers, in submitted work, in creative or editorial contexts, and internally. Different contexts have different expectations and the policy should say which.

9. WHAT NOT TO INCLUDE - rules that cannot be enforced, technology-specific detail that dates immediately, and a prohibition on tools people will use anyway.

10. THE PRACTICAL SUPPORT - a policy alone changes little. What helps: an approved tool that is actually good enough, examples of acceptable and unacceptable use, and a named person to ask.

11. THE REVIEW - this area changes quickly. Set a review interval and name an owner.

12. THE ONE-PAGE VERSION - what people will actually read.

Requirements vary by sector and jurisdiction. Anything with regulatory implications needs legal and compliance input.

Write a policy.

WHAT IT COVERS: [THE SUBJECT]
WHY IT IS NEEDED: [THE PROBLEM IT SOLVES]
WHO IT APPLIES TO: [SCOPE]
THE ACTUAL RULE: [WHAT PEOPLE MUST OR MUST NOT DO]
EXCEPTIONS: [IF ANY, AND WHO APPROVES THEM]
CONSEQUENCES: [WHAT HAPPENS IF NOT FOLLOWED]
WHO OWNS IT: [ROLE]

Structure:
1. PURPOSE - one sentence. Why this exists.
2. SCOPE - who and what it applies to, and explicitly who it does not.
3. DEFINITIONS - only terms whose meaning is genuinely disputable in this context. Do not define ordinary words.
4. THE POLICY - the rules themselves, numbered, each one thing. Use 'must', 'must not', and 'may' precisely, and say at the top what each means.
5. PROCEDURE - how to comply, step by step, for each common situation.
6. EXCEPTIONS - when the rule does not apply, and the named role who approves a deviation.
7. EDGE CASES - a table of 6-10 specific situations people will ask about: Situation | Does the policy apply? | What to do. This is the section that prevents the same question being asked forty times.
8. IF SOMETHING GOES WRONG - who to tell, how fast.
9. OWNERSHIP AND REVIEW - who owns it, when it is reviewed next.

Rules:
- Every rule must be testable. 'Use good judgement' is not a policy.
- Avoid 'should' - it means neither must nor may and produces inconsistent application
- No rule without a procedure for following it
- Write for the person trying to comply, not for the lawyer
- Where I have not given enough to write a section, write [DECISION NEEDED: the question]

Then: THE THREE QUESTIONS people will ask that this does not answer.

Help me prepare for a difficult meeting. Play devil's advocate against my position.

MY POSITION: [WHAT I WANT TO HAPPEN]
WHY I WANT IT: [MY REASONING]
WHO I AM MEETING: [ROLE AND WHAT THEY CARE ABOUT]
THEIR LIKELY POSITION: [WHAT I THINK THEY WANT]
CONSTRAINTS I CANNOT CHANGE: [BUDGET, TIMELINE, POLICY ETC]

Produce:

1. THE STRONGEST CASE AGAINST ME - written as they would argue it, at full strength. Do not soften it.
2. MY THREE WEAKEST POINTS - where my reasoning is thin, and what evidence would fix each
3. LIKELY OBJECTIONS - a table: Objection | Why they will raise it | My response in two sentences | What I should NOT say
4. THE ZONE OF AGREEMENT - what we probably both want, stated in their language not mine
5. MY FALLBACK LADDER - four positions from ideal to walk-away, with the trigger for moving down each rung
6. ONE QUESTION to open with that would make them explain their real constraint

Do not reassure me. If my position is weak, say so in point 2.