AI job descriptions, postings and SOPs: one Claude project

HR documents have a way of eating whole evenings. A two-paragraph job posting takes hours, the job description gets copied from someone's decade-old template, and the SOP sits on the "someday" list for months. Yet all three draw on the same underlying material: how your company is structured, who reports to whom, and how you talk to people.

That is exactly why one-off prompts underdeliver here, while one well-configured Claude project keeps paying off. Let's walk through how to set it up and how to get job postings, role charters, and SOPs out of it from a five-line brief.

Why a project beats three separate prompts

Ask a blank chat to "write a job posting for a sales manager" and you get an average of other companies' postings: "a fast-growing company is looking for an ambitious...". The model is not the problem. It simply has nothing of yours to work with: no structure, no voice, no real terms of employment.

A Claude project fixes this once. You load your company context into it, and every document after that is written from inside the company rather than from the internet's average. We covered how projects work in a separate guide; here is the short version for HR.

What goes into the project:

• Structure. Teams, reporting lines, headcount. A one-page text description is enough.
• Voice. Two or three texts that sound like you: a past posting that worked, a note to the team, a page from your internal wiki.
• Real terms. Work format, benefits, how probation works. Only what actually exists today, nothing aspirational.
• Project instructions. Which documents to build from which briefs, and what to avoid. Add a banned-phrase list here: "dream team", "rockstar", "we're a family".

Setup takes an evening. After that, every document starts from a short brief instead of a blank page.

Step by step: a job posting

1. Collect the brief: role, responsibilities, requirements, terms. Five minutes with the manager who is actually hiring.
2. Send the brief to the project.
3. Interrogate the draft: ask for two headline options, cut everything that was not in the brief, ask "why does this role need a degree".
4. Run the text through the manual checks listed below.

Example prompt:

``` Write a job posting from this brief.

Role: B2B sales manager Team: sales team of 4, reports to the head of sales Responsibilities: outbound calls to warm leads, managing deals in the CRM, weekly pipeline report Must have: 2+ years in B2B sales, comfortable with quotas Nice to have: experience with long sales cycles Terms: hybrid, base plus commission Do not state a salary range; we discuss it at the interview Format: headline, three sections (what you'll do, what we need, what we offer), under 300 words ```

The more specific the brief, the less the model improvises. Anything you leave unsaid it will fill in from market averages, and that is the main source of junk.

What changes for a job description or role charter

This is an internal document with legal weight, so the brief changes. It adds real duties (ask the person already in the seat what they actually do all day), decision rights, accountability, the reporting line, and how success is measured.

Claude carries the structure and the phrasing here. But a document becomes binding through procedure, not through fluent wording: legal review, approval, the employee's signature. Worth writing straight into the project instructions: never cite laws or regulations unless the citation can be verified.

What changes for an SOP

An SOP describes a process, so the brief is built around steps: what follows what, who is involved, deadlines, what counts as done, what to do when things break.

A trick that works: talk through the process as it runs today, by voice memo or messy text, paste the transcript into the chat, and ask Claude to shape it into an SOP. It is excellent at turning a raw ramble into clean structure. It has no idea how work really flows in your company, though, so the draft must be read by someone who runs that process daily.

Where AI gets it wrong and what to check by hand

• Stock phrases. "Dream team", "fast-paced environment", "competitive salary". A banned list in the project instructions helps, but you still proofread.
• Invented perks. The model can add health insurance, learning budgets, or a "friendly team" that were never in your brief. Anything you did not state, cut without mercy.
• Salary numbers. Ranges come from your brief or not at all. If the model volunteered one, that is a market-shaped guess, not data.
• Legal wording. Clauses about liability, termination, or labor law go past a lawyer, or at minimum past the primary source.
• Averaged duties. Job descriptions can pick up responsibilities nobody in your company actually has. Check the list against the real person in the role.

Privacy: what belongs in the project

HR data is sensitive, so keep the rules strict:

• Load material that describes the company, not individuals: structure, processes, voice.
• Employees' personal data (IDs, named salaries, medical details) stays out entirely. Anonymize examples: "manager N", "market-rate base".
• If your company has a policy on external tools, clear the upload list against it before you start, not after.
• Keep projects separate: the HR documents project is no place for candidate files or correspondence from disputes.

The short version

One evening of setup, then a draft from a brief in minutes instead of an evening per document. Claude owns the structure and the wording; you stay the source of facts: real terms, real numbers, legal review. The same approach works for other business documents, and we walked through it for weekly reports as well.

If you would rather learn this hands-on, AGINE Academy teaches it as practice inside the real Claude: a mission, a working artifact at the end of each lesson, an AI mentor alongside. The first block of 4 lessons is free, no signup needed.