Prompt Engineering for HR: Prompt Blocks and the PAIR Framework

I've been training HR professionals to work with artificial intelligence for several years now. During this time, I've noticed a pattern that's common among almost everyone. Someone opens an AI tool, types in a task in ordinary terms, gets an average answer, gets frustrated, and concludes, "Well, this isn't for my job." Then that same person watches their colleague use the same tool to put together in ten minutes what used to take a day. The difference between them isn't the subscription or the model. It's the way the task is framed.

There's a figure that simultaneously pleases and confuses me. Over the past two years, the share of HR professionals using artificial intelligence has grown from 26% to 53%—effectively doubling. That's excellent growth. But the flip side of this same figure: almost half of HR professionals, 47%, still don't use AI at all. And even more of those who use it remain at the most basic level—"write a job posting," "create an offer template." The result is predictable: a primitive request, a primitive response.

The most frustrating thing about the current situation is that the problem isn't a lack of familiarity with the tool. Many people know how to use AI. What's missing is achieving consistent results.

Without a ready-made system for working with prompts, this is what happens:

• one request takes up to ten iterations , you rewrite the same thing over and over again;

•every time you get a new result, even if the task is the same;

•hours are spent on rewriting and finalizing;

•it is impossible to convey this to the team - your method lives only in your head;

•the output is still text that is embarrassing to show.

I check all homework assignments myself. Six months after ChatGPT went public, I noticed that many students were doing their homework with AI. At first, I was against it, then I changed my approach and allowed it—but thoughtfully. And today, I see two extremes. First, I receive very basic responses, where it's immediately clear that the request was a one-line one, no one checked the quality, and the result is so-so. Second, I receive work whose volume, format, and presentation clearly indicate that a human being collaborated with AI—but the work is so well done, so thoughtfully integrated, that it deserves both respect and credit. The difference between these two types of work is precisely the system this article is about.

The lack of a promt architecture creates three predictable problems.

When you learn to speak AI's language, these three pain points disappear: you get predictable quality, spend ten minutes instead of an hour, don't burn tokens where they're counted, and—most importantly—your template works not just for you but for any colleague.

The model I built the course around is called PAIR . The name says it all: you work with the AI ​​in pairs, rather than handing it a task through a wall. Each letter represents a separate skill layer.

The logic is sequential: first you learn to assemble a correct request, then you strengthen it with techniques, then you put context underneath it, and only then does it make sense to talk about agents. The reverse order does not work — an agent built on a poor prompt with no context simply produces bad output faster.

Before changing anything, it helps to be honest about your starting position. I see three levels.

Level 1. User. Types “write a job description for a backend developer,” “make an offer template,” “write a sales manager job posting.” Then says: “I don’t like it, make it better.” It works, but it is the most basic level. The real issue is that most people are stuck here not out of laziness, but because they simply do not realise other levels exist.

Level 2. Prompt user. This person goes further: they search for and copy ready-made prompts from collections and build their own library. That genuinely works for standard tasks. Our first academy courses were exactly about this — a couple of months after ChatGPT became publicly available I recorded “ChatGPT for HR,” then “ChatGPT for Recruiters,” and they consisted of solid ready-made prompts with guidance that people could copy.

Level 3. Prompt engineer. You assemble a prompt from seven blocks for any task, you get consistent quality, and you can scale — producing large volumes of work without losing quality.

What does being a prompt engineer mean for me personally? I taught artificial intelligence to write books for me for Amazon — books people buy, built from my own material. It does not look like “here’s a deck, write me a book.” That does not work. I prepared a framework, described the task, the expected result, the constraints and the requirements. Now all I have to do is upload a set of my lectures — I transcribe my videos, so I have the text of what I actually said — plus my decks, plus tools, plus my instructions. What comes out is a book with my stories, my work experience, my examples. Not empty filler that instantly reads as machine-generated. One book takes me a couple of hours.

This is not a marketing number but an empirical pattern visible across model benchmarks: roughly 70% of answer quality is determined by who you told the model to be and what you told it about the situation. The remaining 30% comes from a correctly formulated task, the format, examples and clarifications.

Why does role matter so much? We tend to treat AI as a super-genius that can do anything. It genuinely holds an enormous amount of knowledge. But it does not know who it is supposed to be right now. The same task handed to different people produces different work: HR does it one way, a marketer another, a developer a third. Inside the model there are millions of possible roles, and when you address it without instruction, it guesses. Sometimes it guesses right. More often it does not.

Context is the second half of that 70%. Without your context — about you, your company, your specifics — the model answers on behalf of an average company. And your company is not average.

Here is the structure I unpack in the first lesson. These are not magic words; this is an engineering construction.

Most people write only block three — what to do. That is roughly 10–20% of the construction.

Assigning a role with a level of expertise removes the “average voice” and switches the model into the mode of a specific professional. When you say “act as a copywriter,” the model reaches into its suitcase of roles, pulls out a copywriter and starts answering like one.

Weak: Write a job description for a backend developer. That is like asking a random journalist or office manager for the same thing.

Strong:

You are a senior technical recruiter with 8 years of experience

hiring backend engineers at a product company. You write job

descriptions that pass a CTO's technical review without edits.

The narrower the role, the higher the precision. “HR” is worse than “senior IT recruiter at a company of this size.” What you are really doing at this moment is creating a digital assistant. When someone posts on social media “I built an entire marketing department inside my AI,” it means they wrote out eight roles: copywriter, designer, brand marketer, strategist and so on. There are nuances, but that is the basic mechanic.

Let me tell you how I did it. For a long time I used ChatGPT, then I tried Claude and realised I would be working there from now on. But there was a problem: ChatGPT had learned a great deal about me through our conversations, and Claude knew nothing. So for the first few days I literally transferred myself.

Here is what I did:

1.On walks I turned on a voice recorder and dictated who I am, what I do, what matters to me, what I want. We were simply getting acquainted.

2.I connected Gmail and asked it to find emails I had written across different years — the inbox has thousands of messages and plenty of spam, while sent mail is far smaller in volume and describes a person far more accurately.

3.I asked ChatGPT to build my digital profile based on everything it knew about me, and uploaded that profile into Claude.

4.I uploaded all my CVs and the articles I found that I had written for Lifehacker.

5.For the academy, I uploaded the first 20 course decks, every deck from one specific course, the full course list, plus statistics and analytics.

For about a week I was “teaching” Claude who I am and what I do. Now, when I ask for a tool, a post, a draft or a book, it is already in context. It can still make mistakes, and I correct them. But the fact that it works as if I had done the work myself is due not only to instructions but, to a huge degree, to context.

Formulate the task like a KPI: what the output is, at what quality, for which audience. The word “write” is not a task. Write a 280–320 word job description for a senior backend Go developer is a task. SMART goal-setting logic applies perfectly here: the more specific and detailed you are, the better the result.

Recently I built a Mario-style game for the academy with Claude. When you simply ask for “a game,” you get a primitive text game — decent in principle, but nothing more. When you describe what the game should be, what mechanics it needs, which elements matter, the result is entirely different. The gap between a generic brief and a detailed one can be tenfold.

If you have good examples, use them — this works extremely well. Need a policy? Upload examples of policies you admire. Need job postings? Upload the postings you are proud of.

When I was teaching Claude to build tools for my courses, I uploaded up to 200 examples of tools I liked — ones I had made and ones I had found — and said: “This is what I want.” The model extracted the underlying principles, and I now use that to create new tools.

A practical tip: keep a folder of reference examples. Whenever you see a perfect job posting, a perfect training programme, a perfect report — save it. Those examples become a personal asset.

If you set no constraints, the model reaches for something like an arithmetic mean of everything in its memory. That is where “dynamically growing company” and “family atmosphere” come from.

Forbidden: corporate cliches, phrases like "family atmosphere"

or "multitasking".

Mandatory: compensation range, remote work policy.

I have my own set of standing rules. At one point I noticed the model was inventing links — to academy courses, to me, to other things. So I wrote it plainly: never invent links, always ask me. Then I added: never invent facts or figures, always search online. Many people also ask the model to avoid certain punctuation marks that look machine-generated. Personally I do not think using them is a problem; you simply need to know what you are doing.

Format sets exactly the shape you need at the output: markdown, JSON, a table, an email. “Make a presentation” — no idea what you will get. “Make a PowerPoint presentation” — you get PowerPoint. “Make a table” — unclear. “Make an Excel table with six tabs, pivot tables and charts” — you get precisely what you asked for.

An example from my own practice: I use Claude for messages in our Telegram channel and always ask for Telegram markup formatting, because Telegram supports bold text, quote blocks and other elements. The result is a finished message I copy and paste, and it looks polished immediately.

This is the self-check step. Even a good model can drift during generation, and you end up with something slightly off.

A classic case: a LinkedIn connection message has a 300-character limit. Even if you explicitly wrote “under 300 characters,” you may well get 310. But if you add Before delivering, verify that the message really fits within 300 characters, the model writes the text, checks itself, says “you’re right, it’s over” and rewrites it. Asking for this is entirely normal.

Prompt engineering as a discipline appeared roughly two years ago: people started writing about it, job openings appeared, and ready-made frameworks emerged. In essence they are the same seven blocks, compressed and named differently by different authors. Tellingly, role appears in all of them: Role in RISEN, Personality in CRISP, Role in RTF, Character in CREATE.

RISEN — for processes

RISEN walks the model through stages. Example:
Role: you are a recruitment lead building the hiring funnel
for a Senior Backend Go position.
Input: the role has been open 3 weeks, 8 CVs arrive per week,
offer conversion is 0%.
Steps: 1) diagnose the causes of low conversion; 2) five
hypotheses with metrics; 3) a two-week experiment plan.
Expectation: a diagnostic report prioritising hypotheses
by impact and effort.
Narrowing: do not propose solutions outside a recruiter's authority.

CRISP — for strategic texts

CRISP forces the model to take a position instead of staying neutral.
Capacity: you are a people officer with 15 years of experience
in scale-ups that grew from 100 to 1,000 employees.
Insight: most 2026 HR strategies copy 2022, ignoring the shift
caused by AI.
Statement: formulate three principles of a 2026 HR strategy
without which a company will lose the labour market.
Personality: direct, concrete, numbers-driven, no euphemisms
or corporate cliches.
Experiment: give three versions — radical, balanced, evolutionary —
and show the benefits and costs of each.

CREATE — for content artefacts

The most thought-through of the four, because it includes both examples and output type.
Character: senior technical recruiter, 8 years at product companies.
Request: a JD for a senior backend Go engineer, 280–320 words.
Examples: the style of "we are building a system where...",
verbs instead of abstractions.
Adjust: if the stack is niche, add a comparison with market
alternatives.
Type: markdown with heading structure, three sections,
a requirements checklist.
Extras: compensation range, process length of 10 days.

RTF — for fast operations

The minimal format. Example: Role: senior recruiter. Task: summarise a candidate CV into a five-second teaser for the hiring manager. Format: three bullets — experience is relevant / relevant with caveats / red flags. In 30 seconds you get something the manager can read on the move. Ideal for screening.

At first you consciously write requests by framework. Then you absorb the way of communicating, forget the names, and simply write well — intuitively choosing the right level of detail for each task. It becomes automatic.

1.Fix the role and the audience. A narrow role, a level of expertise, who will read the result, the tone of voice. The audience directly determines the shape of the text.

2.Load the context. Ideally have your contexts prepared in advance. I built a set of MD files together with Claude: one holds my biography, another information about the academy, a third my article-writing format, another the academy’s brand colours. I load whichever one the task needs.

3.Formulate the task as a KPI. Length, audience, deadline, priority.

4.Add examples. Always state explicitly: “this is an example.”

5.Write the checks and constraints. A checklist or bullets both work. One especially useful rule is to ask the model to raise clarifying questions whenever it is uncertain.

•“Help me with this task” — no role, no context.

•One long paragraph with no structure.

•No examples at all.

•“Make it shorter” at the end instead of a proper format block.

•No verification rules, so you end up catching errors by eye.

Each of these disappears the moment you add one of the seven blocks.

Since HR loves metrics, here are metrics for prompts, with reference points.

You do not need to track these like an accountant, but you should pay attention. I watch time, for instance: if a task took suspiciously long, I write directly to the model — “let’s do a retrospective. Why did this take so long? What got in the way?” It handles that well, and I take the lessons forward.

I put Claude first — a deliberate choice based on experience. I hold subscriptions to ChatGPT, Grok, Gemini and Claude, so it is not a question of access. I simply see that Claude performs better. Beyond those there is Perplexity and narrow alternatives such as Mistral.

An important note on cross-platform work: these services compete and roll out similar capabilities under different names.

So everything we cover using Claude transfers to another system — you just need to know what they call it.

1.Identify your current level: user, prompt user or prompt engineer.

2.Take one recurring task — a job posting, for example — and rebuild its prompt using the seven blocks.

3.Assemble your context files: about the company, the team, your style. Keep them ready to load.

4.Start a folder of reference examples of what you consider excellent in your profession.

5.Write down your standing constraints — including the rule never to invent links, facts or figures.

6.Always add a validation block to tasks with hard limits.

7.Track the five metrics at least roughly and compare them against the benchmarks.