How to Automate Your Recruiting Business With Claude: The Full System

Most recruiters who try AI stop after one good outreach message. It worked, they saved it somewhere they'll never find again, and by Thursday they're back to writing client updates and rejection emails from scratch, one at a time, at the end of an already long day. The prompt was never the problem. The problem is that nobody turned "a message that worked once" into something that runs every week without being rebuilt from memory each time.

This guide is that system, built specifically for Claude, not for a generic AI chat window. It covers the ten pieces of writing a solo recruiter or small staffing agency repeats every week, a business context file that makes every output sound like your desk instead of a generic template, a fixed weekly cadence for when each piece runs, a compliance section most AI guides skip entirely, and what to do when Claude gets it wrong. By the end you'll have a working system, not just a list of prompts to lose in a chat history.

Everything here works in Claude.ai (a Project) or Claude Code (a CLAUDE.md file), and the underlying prompts are also in the Recruiting prompt pack as a standalone reference if you just want to copy one at a time.

What you're building

Two pieces, working together.

The first is a business context file: a short document that tells Claude who you are, so it stops writing like a generic recruiting bot and starts writing like your desk. Without this, every message sounds the same regardless of which recruiter sent it. With it, Claude knows your specialty, your tone, and the compliance line it should never cross.

The second is a weekly cadence: the same ten prompts from the prompt pack, placed on fixed days instead of used whenever you happen to remember them. A prompt you use once is a trick. A prompt on a fixed day is a system.

Screening call recaps and interview prep aren't on the calendar. They run the same day the call or the scheduled interview happens, while the details are still specific enough to be useful.

What you need

• A Claude account. Either works: Claude.ai with a Project (simpler to start), or Claude Code with a CLAUDE.md file in a folder (more setup, but it remembers everything across sessions without you re-pasting context, and can eventually read your actual ATS exports directly).
• Ten to fifteen minutes to write your business context file once. This is the only setup step. Everything after this is copy, paste, review, send.
• Nothing else. No ATS integration, no API keys, no code. If you later want Claude to read your ATS exports directly, Claude Code can do that too, but it's not required to get value from this system.

Step 1: Write your business context file

This is the step that separates a system from a party trick. Paste this into a Claude Project's custom instructions, or save it as recruiting-context.md if you're working in Claude Code.

I'm a recruiter/staffing agency owner. Here's my context:

Agency: [your agency name, or "independent" if solo]
Specialty: [industries or roles you focus on, e.g. "mid-market SaaS
  engineering roles" or "healthcare administrative staff"]
Placement type: [contingency, retained, contract/temp staffing, or a mix]
Tone: [pick one and be specific: warm and direct / consultative and
  detailed / fast and no-nonsense]
Things I never say: [e.g. "rockstar", "ninja", "fast-paced environment"
  as a euphemism for understaffed, any phrase that makes a posting sound
  like every other posting]
Compliance: All job postings and candidate communications must avoid
  language that could imply a preference based on age, race, sex,
  national origin, religion, disability, or any other protected
  characteristic. Never use age-coded phrases ("digital native," "recent
  graduate," "young and energetic team") or ability-coded phrases
  ("must be able-bodied") where a specific, job-related requirement
  would do instead. Describe the work and its actual requirements, not
  the kind of person who "fits" a team culturally.

Fill in the brackets with real details, not placeholders. "Consultative and detailed" produces different output than "fast and no-nonsense," and Claude will actually follow whichever one you pick, so it's worth being specific rather than generic. The compliance line isn't optional. More on why in a few sections.

If you're using Claude Code, put this in a CLAUDE.md at the root of a folder you work from. Claude Code reads that file automatically at the start of every session in that folder, so you never re-paste it. If you're using Claude.ai, paste it once into a Project's custom instructions and every conversation inside that Project inherits it.

Step 2: Load the ten prompts

The prompt pack has all ten, each with a copy button. In Claude Code, the cleanest setup is a prompts.md file in the same folder as your CLAUDE.md, so both are always available together. In Claude.ai, add them as Project knowledge, or just keep the pack open in a tab and paste from there.

Either way, you don't need to memorize them. You need to know which one runs on which day, which is the next section.

Setting this up in Claude.ai versus Claude Code

Both work. The difference is where the context lives and how much it does on its own.

Claude.ai (a Project). Create a Project, name it something like "Recruiting Assistant." Paste your business context file from Step 1 into the Project's custom instructions. Add the ten prompts as Project knowledge files, or just keep the prompt pack page open in a browser tab. Every new conversation started inside that Project automatically has your context loaded, no re-pasting. This is the right starting point if you've never used Claude for work before, since there's nothing to install and no files to manage.

Claude Code. Create a folder on your computer, something like recruiting-ai/. Save your business context file as CLAUDE.md in that folder, Claude Code reads this automatically at the start of every session there. Save the ten prompts as prompts.md in the same folder. The real advantage over Claude.ai shows up once you want Claude working with actual files: drop your weekly ATS exports, a running candidate pipeline log, or past intake notes into that same folder, and Claude Code can read and reference them directly instead of you copying details in by hand each time. It's more setup for less daily typing, which is worth it once this system is a genuine weekly habit rather than something you're still testing.

Start with Claude.ai if you're not sure yet. Move to Claude Code once you're running this every week and the copy-paste is the part that's starting to feel repetitive.

Step 3: Run the weekly cadence

Here's each day with a real worked example, not just the prompt in the abstract.

Monday: new roles

Any client intake from the previous week gets written up as a posting first, before sourcing starts on anything. Writing this Monday morning, not "once I have a candidate in mind," is what actually gets a posting live while the role is still fresh in the client's memory.

Worked example. Your raw intake notes:

Client: Meridian Logistics. Senior DevOps Engineer, remote OK (US only).
Must-haves: Kubernetes, AWS, Terraform, 5+ years. Salary 145k-175k.
Role open because the last person got promoted to team lead, not a
firing or a departure. Small team, 4 people, described as friendly and
low-drama. Client explicitly wants no more than 2 interview rounds,
they've lost candidates before to slow processes.

The prompt (from the pack):

I'm writing a job posting for a client. Here are my raw notes from the intake call: . Write a job posting under 400 words. Lead with what makes this role actually different from ten other postings a candidate has already seen, not a generic 'we are seeking a dynamic professional' opener. List must-haves as a short bullet list, not a wall of requirements. Include the real salary range. End with one honest line about what the role won't involve, if candidates commonly assume something incorrectly.

A reasonable Claude output, with your business context file loaded:

This role opened because the previous engineer was promoted to team lead, not because anyone left under pressure. You'd join a four-person DevOps team at Meridian Logistics, fully remote (US-based), with a hiring process capped at two interview rounds. Requirements: 5+ years in DevOps or SRE, hands-on Kubernetes in production, AWS, and Terraform for infrastructure-as-code. Salary range is $145,000-$175,000. One thing worth knowing up front: this isn't a build-from-scratch platform role, the infrastructure is mature and the work is mostly hardening, scaling, and mentoring as the team grows, not greenfield architecture.

Notice what it didn't do: no "rockstar," no "fast-paced environment," no vague "dynamic team." It used the two things that actually make this posting different from a hundred identical Senior DevOps listings, the promotion backstory and the two-round cap, and put them first.

Tuesday: candidate outreach

Every open role gets its sourcing messages the day after the posting goes up, while the intake details are still specific in your head. This is the highest-leverage prompt in the pack, because a message that references something real about the candidate gets a response rate a copy-pasted template never will.

Worked example. A candidate you found for the Meridian role:

Sarah Chen, Staff SRE at a mid-size fintech, 6 years experience. Posted
on LinkedIn last month about leading a Kubernetes migration off a
legacy orchestration system. Not listed as "open to work," but has
engaged with a few DevOps community posts recently. Client is fine with
naming the company at this stage.

The prompt needs one specific real detail to work well, in this case the migration post, not just a title match. A generic "I came across your profile and think you'd be a great fit" gets ignored by someone who's actively engaged and clearly not desperate to move. Referencing the actual migration work signals you read their profile instead of running a keyword search, which is the whole difference between outreach that gets a reply and outreach that gets archived.

Wednesday: the client update

One progress email per active search, sent the same day every week. The content changes weekly, the day doesn't. A client who hears from you on a predictable schedule trusts the process even in a slow week; a client who only hears from you when there's good news starts wondering what's happening the rest of the time.

Worked example. This week's raw status on the Meridian search:

Sourced 40 candidates, screened 8, submitted 3. One interview scheduled
for Thursday. Two submitted candidates have been sitting with the
hiring manager for 5 days with no feedback, which is starting to put
both at risk of taking other offers.

A reasonable Claude output:

Quick update on the Senior DevOps search: we've sourced 40 candidates, screened 8, and submitted 3 so far. One interview is confirmed for Thursday. The thing I want to flag directly: two of the submitted candidates have been waiting 5 days for feedback, and strong DevOps candidates in this market typically have other conversations moving in parallel. I'd like feedback on those two by end of week if possible, even a quick "pass" or "let's talk," so we don't lose good candidates to slower decision-making elsewhere.

Notice it didn't bury the real issue in a chronological list. It led with the numbers, then named the risk plainly and asked for exactly what it needed, instead of a vague "let me know your thoughts whenever you get a chance."

Thursday: offers and counters

Anything requiring a harder conversation, an offer negotiation, a counter-offer response, gets prepared with the relevant prompt before the call, not improvised during it. This is talking points, not a script to read verbatim. Claude is good at ordering the argument and separating the candidate conversation from the client brief; it's bad at knowing your specific candidate's real priorities if you don't give them to it, so the quality of the input matters more here than almost anywhere else in the system.

Worked example. An offer negotiation you need to handle today:

Candidate: Marcus Webb, offered Senior DevOps Engineer at Meridian,
158k (client's range was 145-175k). He's asking for 170k, citing a
competing offer he won't name specifics on. He mentioned in the
screening call that flexibility on remote work mattered more to him
than his last employer's salary. Meridian's remote policy is already
fully flexible.

A reasonable Claude output:

For the candidate conversation: acknowledge the ask directly, "170 is workable to discuss, let me see what I can do." Then, since he flagged remote flexibility as a real priority earlier, it's worth naming that Meridian is already fully remote, which is worth something even if the number doesn't move all the way. Ask one direct question rather than negotiating blind: "Is the 170 a firm number from the other offer, or is there room if the rest of the package is strong?" For the client brief: Marcus is asking for 170k against your 145-175k range, citing a competing offer with no specifics given. He explicitly valued remote flexibility over salary in our screening call, which this offer already delivers. Recommend landing at 165k as a realistic middle ground that's still comfortably inside your stated range, rather than starting a back-and-forth over the full 12k gap.

That's the shape every negotiation conversation should take: acknowledge the ask, surface the one real leverage point you actually know about instead of guessing, ask a direct question rather than assuming, and give the client one specific recommended number with a reason attached. Counter-offer conversations, when a candidate accepts and their current employer counters, run the same way: acknowledge without pressuring, remind them of their own stated reasons for looking in their own words, and ask what's actually changed rather than arguing them out of staying.

Prefer this built and wired up for your business instead of adapting it yourself? Apply for a free strategy call.

Friday: pipeline and rejections

Any candidate who wasn't right for a recent role but is worth keeping warm gets a nurture message. Any rejection still sitting unsent from earlier in the week gets cleared out before the weekend, not left to go stale into the following Monday. Both get skipped constantly because neither feels urgent on any given day, and both compound if they aren't done, a strong candidate who never hears back from you stops thinking of you as their recruiter by the second silence.

A rejection sent within a day or two of the decision, while the candidate still remembers exactly who you are and what role it was for, reads as respectful. The same rejection sent two weeks late reads as an afterthought, even if the words on the page are identical.

As they happen: screening recaps and interview prep

The screening call recap and the interview prep message aren't scheduled because they can't be, they run the same day the call or the interview happens, while the details are specific enough to be worth writing down.

Worked example. You just finished a screening call with a candidate for the Meridian role:

Candidate: Priya Nair. 7 years DevOps, strong Kubernetes and Terraform
answers, walked through a real incident she led the response for.
Slight gap: limited hands-on AWS, mostly GCP at her current company,
but she was upfront about it unprompted. Comp expectation is 160k,
inside range. Available to start in 3 weeks.

A reasonable Claude output:

Strong yes. Priya's Kubernetes and Terraform depth came through clearly, including a real incident-response example, not just rehearsed answers. The one gap worth flagging: her hands-on cloud experience is mostly GCP, not AWS, though she raised this herself unprompted rather than me having to dig for it, which is itself a good sign. Comp expectation is 160k, inside your range, and she can start in 3 weeks. Given the strength everywhere else, I'd move her to the next round and use the technical interview to gauge how fast the AWS gap actually closes in practice.

Notice it led with the recommendation, not a neutral transcript of the call, and it treated the one real gap honestly instead of either hiding it or overweighting it. A hiring manager reading this knows exactly what decision to make next, which is the entire point of a recap.

The compliance section most guides skip

Employment law prohibits discriminatory language and criteria in hiring, and this is genuinely not optional context, it applies regardless of intent. An AI model writing a job posting has no idea it's about to write something that implies a preference for a protected characteristic. It will happily produce "looking for a digital native who thrives in a fast-paced, young team" because that phrase sounds like normal energetic startup copy, not because it's trying to discriminate. Age-coded language like "recent graduate," "digital native," or "young and energetic" has drawn real EEOC scrutiny under age discrimination law, and it's exactly the kind of phrase a model reaches for by default because it's common in training data. The business context file in Step 1 includes an explicit compliance instruction for exactly this reason: it's the cheapest possible insurance against a real problem.

Even with that instruction loaded, read every posting and candidate message before it goes out and watch for language that describes the kind of person who "fits," rather than the actual, measurable job requirement. "5+ years of Kubernetes experience" describes the job. "Looking for someone young and energetic" describes a person, and that's the line.

A few concrete swaps worth having memorized, since these are the phrases that slip through most often:

• Instead of "digital native" or "recent graduate," write "0-2 years of experience" or the specific tools/skills required, an objective bar instead of an age proxy.
• Instead of "native English speaker," write "fluent written and spoken English," unless being born into the language is genuinely and narrowly job-related, which it almost never is.
• Instead of "young and energetic team," write "collaborative team, fast-paced environment" (the description of the work, not the demographic of the people doing it).
• Instead of requiring "no employment gaps" as a screening filter, which can disadvantage caregivers and candidates with disabilities, either drop the filter or ask directly and neutrally: "please note any gaps in your work history you'd like context on."
• Instead of "must be able-bodied," describe the actual physical requirement of the job if there is one: "able to lift 50 lbs" is a defensible, job-related requirement; "able-bodied" is not.

The pattern across all five: describe the job's actual, measurable requirements, never the demographic profile of the person you're picturing in the role. This isn't legal advice, and if you have real questions about a specific posting or hiring process, an employment attorney is the right call, not this article. But this is a well-established rule, and it's worth building the habit of checking for it every single time, not just when something feels obviously off.

One more line worth being explicit about, separate from posting language: never let Claude, or any AI tool, score, rank, or screen candidates for you. This system is built entirely around drafting communications, postings, outreach, updates, recaps, prep messages, not making decisions about who advances. That distinction matters legally, not just ethically. Several jurisdictions now regulate "automated employment decision tools" used to substantially assist or replace human judgment in hiring, including bias-audit and candidate-notice requirements a solo recruiter or small agency is almost never set up to satisfy. Using Claude to help you write faster is a different category of tool entirely from using it to decide who gets an interview. Keep every actual hiring judgment, who to submit, who to pass on, who to recommend, made by you, informed by AI-assisted notes, never delegated to them.

What Claude gets wrong, and how to fix it

It invents specificity when your notes are thin. If you give it three words about a role, it will sometimes fill the gaps with generic recruiting language instead of asking you for more. Fix: feed it more detail, not less. Five real details from the intake call produce a better posting than fifteen generic requirements.

It defaults to hype language unless told not to. "Rockstar," "ninja," "fast-paced environment," these are the recruiting-copy equivalent of filler words, and most models reach for them by default because they're common in training data. The "things I never say" line in your business context file is what stops this. If it still slips through occasionally, just tell it directly in that conversation: "drop the hype language."

It can't tell a genuine competing offer from a bluff. When you ask it to prepare negotiation talking points, it will build the strongest possible case from whatever you tell it, but it has no independent read on whether a candidate's "competing offer" is real or a negotiating tactic. Use your own judgment on that before the call. Claude organizes the argument; you're still the one reading the room.

It doesn't know your market's unwritten rules. Every specialty has conventions Claude has no way of knowing: which comp ranges are actually competitive in your niche right now, which clients move fast versus slow, what "flexible" actually means at a specific company. This is exactly what the business context file is for, and it's worth updating it the first few times you notice Claude missing something an experienced recruiter in your specialty would automatically know.

Extending this to your own business

Every prompt in this system follows the same shape: give Claude real specifics, name what you don't want, ask for a length limit and a clear next step. If you want to add an eleventh prompt for something this pack doesn't cover, a candidate withdrawal conversation, a contract-to-hire conversion pitch, a bench-availability update for temp staffing, write it the same way. The business context file does most of the real work; the individual prompts just point it at a specific task.

If you're not in recruiting, the shape of this system, ten pieces of recurring writing plus a business context file plus a fixed weekly cadence, is the same one used for the real estate, accounting, and marketing agency prompt packs as they publish. The specific prompts change. The system underneath doesn't.

FAQ

Do I need Claude Code, or does Claude.ai work? Claude.ai with a Project works fine to start. Claude Code is worth it once you want Claude reading your actual ATS exports or a running pipeline log directly instead of you copying details in by hand every time.

Will this sound like every other recruiter using the same prompts? Only if you skip the business context file. The prompts are the same for everyone who copies them; your specialty, your tone, and your specific candidate and client details are not. Two recruiters running this exact system on two different searches will produce two different outputs, because the inputs are different.

How long does this take once it's set up? The business context file is a one-time, fifteen-minute setup. After that, each individual prompt takes under a minute to run, the time is in reviewing and editing the output, not generating it, which is the point: it should save you the blank-page time, not the judgment time.

What if Claude writes something inaccurate about a role or candidate? Treat every output as a first draft prepared in thirty seconds instead of ten minutes, not a finished decision. You still need to verify every factual claim (salary range, required skills, candidate background) against your actual notes and ATS before it goes out. Claude doesn't know your pipeline data unless you give it to that conversation.

Does this replace my ATS's automated sequences? No, and it isn't trying to. An ATS's automated sequence is the same three emails to every candidate regardless of what actually happened in the screening call. This system produces one specific, individually reasoned message per person, which is a different kind of tool for a different part of the job. Many recruiters run both: the ATS handles routine status-tracking on autopilot, this handles the writing that genuinely needs a human read of what happened.

What happens the first week I skip a day? Nothing breaks, and that's the point of building this as a cadence rather than a fragile all-or-nothing routine. If Tuesday's outreach doesn't happen, it's still worth doing Wednesday, a slightly late message beats no message. The value isn't in perfect adherence, it's in the writing getting done on most weeks instead of the rare week you happen to have spare time.

Can I use this for a team, not just a solo recruiter? Yes, with one change: give each recruiter their own business context file rather than sharing one. The tone and specialty should reflect the individual recruiter writing the message, not a single team-wide voice, otherwise every recruiter's candidates start receiving messages that sound identical to every other recruiter's candidates, which undercuts the personal relationship the whole system is meant to strengthen.

What this doesn't replace

None of this sources a candidate who doesn't exist, closes a deal, or decides who to hire. Every output here needs a human read before it goes out, especially anything touching compensation or a hiring recommendation, where the actual judgment call is not something a prompt should make for you.

Getting started today

Write your business context file first. It's the one step that makes every prompt after it better, and it takes fifteen minutes. Then pick one day, Monday is the easiest since it only requires one piece of client intake to exist, and run the job posting prompt once on a real role. If the output needs one edit, you're ready for the rest of the week. If it needs five, your intake notes going in were too thin, not the prompt failing, so add more specifics and try again.