Your job description is not a skill spec - here is how to fix that

Most job descriptions are not what you think they are.

You read them as a list of requirements. The candidate reads them as a list to mirror back at you. The applicant tracking system reads them as a list of keywords to match. And somewhere in that round trip, a fundamental confusion takes hold: that the document was ever a skill specification in the first place.

It was not. It was advertising.

What job descriptions are actually for

Job descriptions get written by HR teams or hiring managers, often under time pressure, with one main goal: get good people to apply. That goal pulls the writing in a particular direction. You end up with phrases like "excellent communication skills", "strong attention to detail", "able to work in a fast-paced environment". These are reassuring to the reader because they describe the kind of workplace they want. They are useless as filters because every candidate writes the same words back at you.

The problem compounds at scale. The applicant tracking system parses the JD, extracts the keywords, and ranks every applicant by how often they used those same keywords. Twenty CVs come out at the top of the pile - and the only thing they have in common is that they read the JD and copied the language. You have not filtered for skill. You have filtered for thoroughness in CV writing.

What a real skill spec looks like

If a job description is the front cover of the role, the skill spec is the manual underneath. It is the actual list of capabilities the person needs in order to do the work, and where each one sits on a scale from "aware of" through to "competent and confident".

The big difference: a skill spec uses your organisation's vocabulary, not the careers-page boilerplate. "Communication skills" becomes specific things like "explaining technical decisions to non-technical stakeholders" or "running a team debrief after an incident". "Attention to detail" becomes "writing audit-ready case notes" or "reviewing supplier contracts for tail-risk clauses". These phrases mean something. They are testable. They show up in the work your existing team is already doing.

Turning a job description into a skill spec

The applications module in SkillDrill takes a job description as the starting point and asks a different question of it: what skills, in our actual taxonomy, does this role really need?

You paste the JD in. The AI reads it against the skills already mapped on your existing team - the things your current staff have demonstrated, the levels they have reached, the language they use to describe their work. It then returns a draft skill spec made up of those internal skills, with suggested minimum levels and prerequisites. You review, edit, and publish.

What that gets you is something the JD on its own never could: a hiring filter built from the ground truth of your organisation, not from generic templates. Two roles with similar job descriptions but different teams will produce different skill specs - because the underlying needs really are different, and your existing data already shows that.

What candidates do next

Once the spec exists, the candidate experience changes. Instead of a CV upload and a generic form, applicants go through the same conversational discovery your existing staff use. They are asked about their experience in plain language. The AI prompts for examples and detail. It maps the answers back to the same skill taxonomy your spec is written in.

The output is not a CV ranked by keyword density. It is a candidate skill profile in the same shape as every staff profile in the system. You see what they can do, at what level, against the actual requirements - not against words.

For the candidate, the experience feels less like a barrier and more like a conversation. People who would not have written a strong CV - career changers, returners after a break, internal candidates with non-obvious backgrounds - get a fairer shot. People who normally lean on CV polish lose the unfair advantage they had in the keyword-matching system.

Why this matters after the hire

The biggest payoff is not at the offer stage. It is what happens on day one.

In a typical organisation, a new starter goes through induction and then sits down to fill in a skills audit. They are asked to describe what they can do, often in a form, often without context, and often six weeks late. The result tends to be a thin, hastily written record that under-represents the person and gets ignored from then on.

When the application itself is the skills conversation, none of that needs to happen. The new starter already has a complete profile in the system. They show up in skills search from their first day. They appear in career pathways with their gaps already mapped. The knowledge assistant they consult about policies already knows the tags and access scope that apply to them. Hiring and development become one continuous record, not two systems trying to talk to each other.

The mindset shift

The job description still has a job to do. It is advertising. It tells someone whether they want to apply, and it shapes how they think about the role before the conversation starts. None of that is going away.

What is going away - or at least, ought to be going away - is the assumption that the same document should also do the work of skill assessment. Those are different jobs. They need different artefacts. And once you separate them, hiring stops being a guessing game and starts being a calibration against data you already trust.

If you are recruiting at the moment, before you click "post" on your next vacancy, take five minutes to ask: if the JD was the only thing you used to make this decision, would you trust the result? If the answer is no, the JD is not the problem. The problem is what is missing alongside it.