The expensive miss in hiring, sales, and vendor review is rarely the bad meeting. It is the good ones spent on a deal that was never going to clear on level, domain, or price. The fix is unglamorous. Score the opportunity before you open it. Weight what you can verify. Penalize what the other side will not disclose. Do not let a certificate, a logo, or a fluent paragraph stand in for work that actually shipped.
That habit is older than any assistant. It is also the only part of a recent promotional post worth taking into an AI for business stack. The post describes a Claude skill called Head Hunter that scores job listings before the author applies. Useful as a specimen. Not useful, yet, as a method.
The same failure, one queue over
The shape travels. In AI for sales, skills overlap becomes capability match. Seniority becomes whether you are talking to someone who can buy. Domain fit becomes whether you have done this industry, not whether the title rhymes. Practical fit becomes the commercial terms: territory, deployment, price.
Say a qualification agent reads “strategic priority” in the notes and writes down a budget. The account never stated a number. If the rubric is doing its job, hidden terms take a penalty you defined in advance, and the score drops. Then you rerun it on deals you already won and lost. If the high scores do not cluster on the wins, you do not have AI automation. You have a confident paragraph with a denominator.
A lead score that invents a budget fails in the same way as a job score that invents a salary. The model is good at completing blanks. Your process has to be better at refusing them.
One rubric, and what it does not show
Head Hunter, as described, scores each posting out of 100. The claimed split is skills overlap at 40, seniority fit at 25, domain fit at 20, and practical fit at 15, covering location, remote policy, and salary. The author ties the heavy weight on skills to what a hiring manager looks at first, and the seniority points to roles that would reject you in a line. The domain points come from a blunt observation: the same title in the wrong industry is not the same job. Those are judgments. This piece does not base them on hiring research, and nothing in Anthropic’s skills documentation grades a job ad.
Two rules are sharper than the weights. A tool mentioned only because it appeared in a course scores zero. Only work used in production counts. When a posting hides salary or seniority, that part is scored low rather than guessed. How low is not specified. Do not invent a deduction and call it theirs.
The post points to thirty open tabs as the mess the skill is meant to sort, and to mismatches that kill an offer after four interviews. Both are the author’s illustrations, not measured dropout rates.
All of this comes from that single promotional post, which is not linked here. No author is named. No skill file, sample score, or outcome is shown. That is a lack of evidence. It is not proof the skill does something else, and it is not proof it does nothing. On what is shown, it grades listings. Nothing shows it writing to employers or submitting applications. The author says the skill arrives in a newsletter welcome email. The newsletter is unnamed.
What a Claude skill actually is
A skill is a folder of instructions. Claude sees only a short label for each installed skill until it decides the skill is relevant and opens the rest. Anthropic calls that progressive disclosure in Equipping agents for the real world with Agent Skills.
The precise package is a directory with a SKILL.md file. The file has to open with a short header, written in YAML, containing a name and a description. At startup, those two fields get loaded into the system prompt. If Claude judges the skill relevant, it reads the full file. Further files, referenced from that core file, stay closed until they are needed.
Anthropic’s PDF skill is the concrete example. The core file points to extra notes, including form-filling guidance kept out of the main instructions, and to a Python script that pulls form fields without loading the script or the PDF into context. The example lives in Anthropic’s skills repository. Skills can bundle code that Claude runs as a tool. Anthropic’s reason is practical. Some work is cheaper and more reliable as a script than as generated text, and code is deterministic, so the workflow repeats. A script can fix the steps a model would otherwise redo differently each time. If that script calls an unstable tool, it only repeats the call.
With a filesystem and code execution, Claude does not have to load an entire skill at once. Anthropic describes the bundled context as “effectively unbounded.” Read that as capacity, not quality. A large skill can still be a bad one.
The job-scoring post never says whether Head Hunter is this kind of package, a saved prompt, or something else. If you are building AI agents for real work, Anthropic’s format is the one to understand.
An unevaluated skill is not a method
Anthropic’s build advice is blunt. Start with evaluation. Run the agent on representative tasks, see where it fails, then add skill content to close those gaps. Watch whether the name and description trigger the skill when they should, and whether they trigger it when they should not. Write the successes and the failures back into the skill.
The Head Hunter post offers weights, two rules, and a welcome email. It does not report representative tasks, failure cases, or validation. By Anthropic’s own standard, that is an unevaluated skill.
A weighted total can still be a guess. If a model is the one reading “senior-ish, ” “competitive pay, ” or “hybrid as needed, ” the number can wobble from run to run. A repeatable score belongs in a calculation: fixed fields, fixed penalties, the same inputs, the same steps. Nothing public shows which approach this skill uses. The refusal to guess points the right way. It is not evidence the penalty lives in code.
Audit the file before it sees a résumé
Anthropic is explicit about the other risk. Skills give Claude new capabilities through instructions and code. A malicious skill can introduce vulnerabilities, or direct Claude to pull data out and take actions you did not intend. Install skills only from trusted sources. Anything less trusted gets an audit first: read the bundled files, check dependencies and scripts, and watch for instructions that reach untrusted networks.
A skill handed out only through a newsletter, with no public code, sits in that audit-before-use category. A job scorer is especially sensitive if it can see a résumé, work history, salary expectations, or location. Nothing here says Head Hunter does anything malicious. Nothing here is a reason to treat it as safe.
The same line applies past job search. If your team is wiring AI agents into hiring, sales qualification, or vendor review, a skill that can read a résumé or a CRM export is not a convenience file. Audit it the way you would audit a script someone emailed to finance.
A private filter is not a rejection engine
The temptation is to turn the scorer around and point it at applicants. That is a different instrument, with different duties.
An applicant filtering their own time is allowed to be idiosyncratic. A rule that counts only production evidence will skip course-only tool lists. It can also zero someone whose real work is worded differently from the ad. A person who ran the system in production under a title the posting does not use can look like a miss. That is an acceptable personal tradeoff when the only cost is an application they chose not to send. It is not acceptable as an automated rejection. The people screened out are no longer choosing the filter.
If a printed score is going to touch a candidate, the evaluation Anthropic describes has to include the failures this kind of rubric creates. Title-mismatch false zeros. Penalties for hidden salary that track how someone was told to write an application, not whether they can do the job. Strict tool rules that miss production work described in plain language. You also need an audit of what the skill can see, and a check on who those rules consistently screen out. A fit score is not a neutral instrument just because it prints a number.
Questions worth asking before you trust the score
- Does a higher Head Hunter score predict interviews or offers?
No one has shown that. The post describes a scoring scheme. It does not report outcomes, accuracy, or how many jobs were scored.
- Are the four weights an official Claude method?
No. They are one author’s claimed split: 40 for skills overlap, 25 for seniority, 20 for domain, 15 for practical fit. Anthropic documents how skills are packaged and loaded, not how to grade a job ad.
- What does “scores low” mean when pay or level is hidden?
The post does not say. It only says the missing part is scored low rather than guessed. Do not assume a zero or a fixed deduction.
- Is “production evidence only” a fair rule?
It is a strict personal rule, not a validated standard. It blocks course-only tool lists, and it can also zero people whose production work is real but worded differently from the ad.
- Should you install a job-scoring skill from a welcome email?
Not until you audit it. Anthropic’s guidance is to trust known sources and to read the files, scripts, dependencies, and any network calls in anything else, especially if the skill can see a résumé or salary expectations.
- Can we point the same rubric at applicants?
Not as a private time-saver. A printed score used to reject people needs the evaluation, an audit of what the skill can see, and a check on who the strict rules zero out.
- What should a business copy, if not the skill?
Four things. Verified fields only. Missing data penalized by a fixed rule you wrote, not by a guess. The arithmetic in code if you need the same score twice. A test on cases whose right score you already know.
Before the next pile of tabs (jobs, leads, vendors, candidates), write down what you will not infer. A language model is happy to complete the blank. That is the feature. In a hiring stack, or a sales stack, it is also the bug.