Experiments with Claude — Episode 03 (Free)
You've Got Skills: You Already Know How to Do This
There’s a skill HR practitioners have been using for decades that most of them don’t realize is exactly what building a Claude Skill requires.
It’s process analysis.
Job analysis. SOP design. Competency framework development. Workflow documentation (which can translate nicely into workflow automations, eventually).
The structured practice of making implicit work explicit — asking “what does this role actually do, step by step, and what does good performance look like at each step?” HR has been doing this longer than most functions. We more or less invented the methodology.
Encoding a Claude Skill is the same work. You take a process you run on judgment and instinct, you excavate the reasoning inside it, and you write it down in a format something else can follow. The output used to be a job description or a process manual. Now it’s a SKILL.md file. The intellectual work is identical.
This matters for one important reason: it means this isn’t a new skill you need to acquire. It’s a new application of something you already do well.
Where the value actually lives
Most of the conversation about AI in HR focuses on tasks — which ones AI can do, which ones it can’t. That’s the wrong frame. Rather than asking “which tasks are safe?”, you should be asking “where does my value actually live?”
The honest answer: it has never been in execution.
It has always been in knowing what needs to be executed, and how.
The practitioner who spends eight hours, in every cycle, drafting performance reviews is executing. The practitioner who has encoded their performance review framework into a Skill — who has made their judgment, their criteria, their standards explicit and systematic — is orchestrating. They’re not doing less work. They’re doing different work, at a different level.
The execution is handled by AI (under human guidance supervision, of course). They’re spending their time on the decisions that can’t be systematized: what the framework should be, when to deviate from it, how to handle the cases that don’t fit.
That’s the move. And building Skills is one of the components to make it happen.
The practitioners who will lead in the next few years aren’t the ones who resist this shift. They’re the ones who recognize it early and reposition, from doing the work to designing how the work gets done.
What encoding actually requires
Here’s the thing that makes encoding hard, and why most people who try to do it superficially end up with Skills that are consistently mediocre rather than occasionally wrong.
Claude doesn’t know how you evaluate a comp offer. It doesn’t know that your organization weights peer feedback at 30% and has a history of rating inflation that leadership is trying to correct. It doesn’t know that in your culture, a performance conversation framed as “development” lands better than one framed as “improvement.”
Prompting teaches Claude what to do. Encoding your knowledge teaches Claude how you do it. Those are different things, and the gap between them is the gap between useful and genuinely valuable.
Here’s a concrete example. Take the job description process that scored 11/12 on the Readiness Assessment — the worked example in Episode 01.
“Split requirements into Essential and Desirable” is a step that looks simple on paper. As a prompt instruction to Claude, it’s nearly useless. But here’s what that step actually contains, once you excavate it:
- If the role involves direct reports, always include a leadership competency in the requirements section.
- Credential inflation is the most common failure mode — a PhD listed as Essential when it’s really Desirable screens out qualified candidates before they self-select in.
- Vague scope in the role summary causes requirements to drift; tighten the summary first, then write requirements against it.
- A good JD requires fewer than two rounds of editing from the hiring manager — if you’re on round three, something in the requirements is still unresolved.
Those are four concrete rules. None of them appear in “split requirements into Essential and Desirable.” All of them live in the head of someone who has been writing JDs for years.
The moment those rules are written down and given to Claude, the output improves immediately — not because Claude became more capable, but because you finally told it what you actually know.
The trap: analysis paralysis
HR practitioners are good at process analysis. That can work against you here.
The instinct, when building something that’s supposed to encode a process, is to define everything upfront. Every edge case. Every exception. Every possible variation. The result is a 40-section document that takes two weeks to write and still doesn’t work well on day one, because the real failure modes only show up when you test against actual use.
The better approach is iterative. And it maps directly to how good HR practitioners actually work when they design something new.
Define the architecture first. What is the skill for? What does it need as input? What should it produce? In what format? What are the trigger phrases — and equally important, what are the non-triggers, the situations where this skill should stay inactive?
Write the initial instructions. Not everything — the core steps, the most important criteria, the most critical guardrails. A lean first version you can test is more valuable than a comprehensive first version you can’t evaluate.
Test against real prompts. Not idealized test cases. The prompts you would actually type. “Help me draft something for the team about the reorg” — not “please invoke the team-email-drafting skill to draft a formal internal communication.” If it doesn’t work the way you’d actually use it, it doesn’t work.
Refine based on what you observe. Every failure mode tells you something specific: the skill never triggers (the description doesn’t match how you talk), the output is too generic (the criteria aren’t specific enough), it activates when it shouldn’t (the non-triggers need work).
This is a recipe, not a blueprint. A blueprint specifies everything before construction begins. A recipe gives you the method and the key ingredients, then expects you to taste and adjust.
Which brings me to something the Skill Builder Template addresses directly, and that most people skip on their first attempt: building quality in from the start.
Don’t trust your skill. Test it.
The most common mistake after building a first skill is assuming it works because the instructions look right. They usually don’t — not fully. The real failure modes only show up when you run it against the prompts you’d actually type.
The Template includes a quality checks section and asks you to provide concrete examples of good and bad output. These aren’t optional. They’re where your judgment becomes operational. Claude can follow instructions, but it can’t define what “good” looks like for your performance review framework. You can. Writing that down — what a strong draft looks like, what a weak one looks like and why — is what separates a skill that performs reliably from one that works most of the time.
Three things worth doing before you declare a skill ready:
Anticipate the error-prone areas. Every process has a step where judgment is most concentrated — the one you’d be most nervous about someone else skipping. That’s where the skill is most likely to produce generic output. Give it extra criteria. Give it an example. Make the standard explicit.
Write at least one bad output example. This sounds counterintuitive, but it forces you to articulate exactly what you’re trying to avoid. “A layoff-adjacent communication that sounds like a Friday wins email” is more useful to Claude than three generic paragraphs on tone.
Test with prompts you’d actually type. Not “invoke the team-email-drafting skill to produce a formal internal communication.” Try “help me write something to the team about the reorg.” If it doesn’t trigger or doesn’t perform on real language, the description or the steps need work.
This isn’t a new discipline. HR practitioners calibrate performance standards, pilot new processes with small cohorts, and debrief on what broke before rolling something out. Building a skill is the same practice. The output is different. The rigor is identical.
Why the architecture of your environment matters first
One more thing before the tools.
A common experience: someone builds a solid skill and gets inconsistent results anyway. The skill is fine. The environment isn’t.
Claude’s instruction layers work like an iceberg. The conversation you have — the messages you type — is the visible tip. Below the waterline: your project system prompt, your account-level custom instructions, your skill library, Anthropic’s training. Each layer loads in every relevant conversation, and they can conflict with each other.
The most common problem: everything is in the conversation. Every session starts with re-explaining your role, your company, your context. That context belongs in a project system prompt — defined once, loaded always. If you’re repeating something in every message, it belongs in a higher layer.
The second: no projects. Without projects, context from your compensation work bleeds into your ER conversations. Projects isolate context. A Skill activates everywhere, but the project system prompt gives it the right frame.
The Architecture Guidebook attached to this article has a Setup Decisions worksheet: a short checklist to work through before your first skill, and your environment is actually ready for what you’re about to build.
What’s in this week’s free release
The Claude Architecture Guidebook — Two pages. The instruction layers diagram (with the iceberg thumbnail showing the three zones of control) plus the Setup Decisions worksheet — a checklist that makes sure your environment is ready before you build.
The Skill Builder Cheat Sheet — One page. The complete reference for what goes into a SKILL.md file: structure, naming rules, trigger logic, the recipe metaphor for progressive disclosure, the build-test-refine loop, and a troubleshooting guide for the four most common failure modes.
The single most important line on the sheet: the description is your trigger. Claude reads every skill’s description to decide whether to load it. Underinvest in this line and the skill sits unused. Get it right and it activates exactly when it should.
What’s in the paid release
For paid subscribers: the Tacit Knowledge Extractor and the Skill Builder Template.
The Extractor is the workbook that pulls the reasoning out of your head — the rules you apply without articulating them, the criteria you use without writing them down. The paid article goes deep on how to use it without falling into the analysis paralysis trap, and how to design the quality checks that tell you whether what you built actually works.
The Template is where extracted knowledge becomes a working SKILL.md file.
Coming in next installments
Some of the topics I’ll probably cover in future installments are:
Plugins (if Skills document a task, think of Plugins as documenting a function)
Evals (to help Claude better understand what good quality looks like)
Claude Cowork (for executing some of the tasks you documented)
Some experiments with Claude Code (vibe coding is not just for developers)
Some experiments with Dispatch (to assign tasks remotely in Cowork)
Some experiments with Computer (to let Claude use your whole computer)
and more (I’m sure the folks at Anthropic will have something new soon)
Many of these features are still in Research Preview mode (e.g. Cowork), which essentially means that we’re helping Anthropic test. I do not consider myself an expert in everything Claude. But I am an expert learner, always figuring things out. These articles are a documentation of my learning journey.
Let me know in the comments if you want to read about something else.
HR practitioners have been doing process analysis for decades. The skill isn’t new. The output format is.
The practitioners who move fastest on this aren’t the ones who know the most about AI. They’re the ones who already know how to make implicit knowledge explicit — and recognize that’s exactly what this requires.
If you ran the Skill Readiness Assessment in Episode 01 and found a strong candidate, reply and tell me what process you chose. I’m genuinely curious what HR practitioners are deciding to encode first.