Claude Skills FTW.

Key Takeaways

• Claude Skills are markdown instruction files that teach AI how to perform specific tasks your way, turning a general-purpose assistant into one that understands your organization’s terminology, compliance requirements, templates, and decision logic. They take minutes to create and compound in value with every use.

• The real power of Skills isn’t automation. It’s knowledge capture. When your best compensation analyst retires, their expertise doesn’t have to leave with them. A well-written Skill encodes the judgment calls, the edge cases, the “here’s what we actually do when the policy says X but the situation is Y” knowledge that no SOP document has ever successfully preserved.

• Anthropic’s best-practices research shows that chunked, focused Skills outperform monolithic ones. Three separate Skills for voice, corporate writing, and newsletter formatting beat a single “writing” Skill. This mirrors what organizational design research has always said: specificity beats generality when you’re encoding expertise.

• HR teams that treat Skills as a governance layer rather than a convenience feature are building something strategic. A Skill that enforces your FLSA classification logic or your adverse impact analysis methodology isn’t just saving time. It’s creating auditable, repeatable, institutionally consistent AI behavior that you control.

The Skill Layer.

The difference between AI that helps and AI that knows how you work

An HR operations manager asks Claude to draft a severance agreement. The output is competent. Clean formatting. Standard release of claims, consideration period, revocation window. It looks like a severance agreement. It is not her company’s severance agreement. It misses the equity acceleration provisions for involuntary terminations during change-in-control. It doesn’t include the non-disparagement language their counsel spent three months negotiating. It doesn’t know that COBRA subsidy is six months for directors and three for everyone else, or that the California addendum requires different ADEA formatting.

She fixes all of this manually. It takes forty minutes. The AI saved her maybe twenty minutes of formatting and boilerplate, then cost her forty minutes of corrections and additions that she could have avoided if the tool had known what she knows.

This is the gap that most HR teams are living inside right now. They have access to genuinely capable AI. They are using it as a sophisticated autocomplete. And the distance between “generally helpful” and “specifically useful” is not a technology problem. It’s a knowledge-transfer problem. The AI doesn’t know what you know. More precisely, you haven’t told it.

That’s what Skills are for. And the organizations that figure this out first are going to build something that compounds in ways that vendor purchases never will.

What a Skill Actually Is

Strip away the product terminology, and a Skill is a deceptively simple thing: a markdown file with instructions that tells Claude how to do a specific task, stored in a folder where Claude can find and use it. That’s it. No code required. No API integrations. No developer involvement. A SKILL.md file with a name, a description, and a set of instructions written in plain English.

The structure follows a pattern that Anthropic standardized as an open specification called Agent Skills. At the top of the file sits YAML frontmatter, which is metadata that tells Claude when the Skill is relevant and how it should behave. Below that sits the actual instruction content in markdown. When you ask Claude to do something that matches a Skill’s description, it pulls in those instructions and follows them.

Here’s what the frontmatter looks like in practice:

---
name: severance-agreement
description: Drafts severance agreements following company-specific templates, equity provisions, and state-specific compliance requirements. Use when creating separation agreements, severance packages, or termination documentation.
---

The name field becomes a slash command. Type /severance-agreement and Claude loads the full instructions. The description field is what Claude uses to decide whether to load the Skill automatically when you mention something related. Write a vague description, and Claude won’t find it when you need it. Write a specific one with the actual terms your team uses, and it surfaces reliably.

Below the frontmatter, you write instructions the way you’d explain the task to a sharp new hire on their first week. What templates to follow. What compliance requirements to check. What edge cases to watch for. What the output should look like. What mistakes to avoid.

This is the part that most people underestimate. They think the hard part is the technology. The hard part is articulating what you actually do.

The Knowledge-Capture Problem That Skills Solve

Every HR team has institutional knowledge that exists in exactly one place: the heads of the people who’ve been doing the work for years. The compensation analyst who knows that the FLSA exemption test for your hybrid account executives requires a different duties analysis than the DOL guidance suggests, because your specific role blends inside and outside sales in a way that triggered an audit in 2019. The HRIS specialist who knows that the Workday integration breaks when a contractor conversion happens mid-pay-period because the position management module treats it as a termination-rehire rather than a job change. The employment attorney who knows that your standard arbitration clause needs different language in California, Montana, and any state that enacted the 2024 FAIR Act provisions.

This knowledge is real. It is valuable. It is almost never documented in a way that anyone else can use. SOPs capture the happy path. They don’t capture the judgment calls. They don’t capture the “yes, but” qualifications that separate someone who’s been doing the work for ten years from someone following the procedure for the first time.

Skills can encode this. Not perfectly. Not completely. But in a way that’s meaningfully better than the status quo, which in most organizations is “hope the person who knows this doesn’t quit before someone shadows them for eighteen months.”

A well-structured Skill for adverse impact analysis doesn’t just tell Claude to run the four-fifths rule. It tells Claude that your organization uses the Fisher’s exact test when cell sizes drop below five, that your standard comparison group for RIF analyses is the department plus one level up unless the selection pool was explicitly defined differently, that your legal team requires both the stock and flow analysis for any action affecting more than twenty people, and that the California DFEH filing threshold is different from the federal EEOC standard. That’s not automation. That’s knowledge transfer with a feedback loop, because the Skill gets better every time someone catches something it missed and adds it to the instructions.

Josh Bersin’s 2026 research on AI in HR found that organizations with documented, repeatable AI workflows saw 2.4 times faster time-to-value on AI initiatives than those using AI ad hoc. The mechanism isn’t complicated. When the AI knows how you work, you spend less time correcting it and more time doing the work that actually requires your judgment.

Why Chunked Skills Beat Monolithic Ones

Anthropic’s own testing revealed something that organizational design researchers would recognize immediately: specificity matters more than comprehensiveness when you’re encoding expertise.

Their skill authoring best practices documentation is explicit on this point. Three separate Skills for voice guidelines, corporate writing standards, and newsletter formatting consistently produce better output than a single “writing” Skill that tries to cover all three. The reason maps directly to how Skills consume context. Claude has a finite context window. Every token in a Skill competes with conversation history, other Skills’ metadata, and the actual task at hand. A 500-line omnibus Skill that covers ten use cases wastes context on nine of them every time it fires.

But the quality improvement goes beyond token economics. Focused Skills are easier to trigger correctly because their descriptions can be more specific. A Skill described as “Drafts FLSA exemption analyses following company methodology including state-specific tests and hybrid role classifications” will fire precisely when you need it. A Skill described as “Helps with compliance stuff” will fire when you don’t want it and miss when you do.

This principle has direct implications for how HR teams should organize their Skill libraries. Don’t build “The HR Skills Mega-Pack.” Build separate Skills for:

The offer letter generator that knows your compensation bands, your equity grant schedules, and your state-specific at-will language variations. The job description writer that follows your competency framework and knows which phrases your legal team has flagged as potential ADA concerns. The exit interview analyzer that codes responses against your specific attrition taxonomy and knows the difference between voluntary regrettable and voluntary non-regrettable in your organization’s retention model. The I-9 compliance checker that knows your E-Verify enrollment status and which worksites require additional state verification.

Each one is a focused tool. Together, they constitute an institutional knowledge layer that no vendor can replicate, because the knowledge is yours.

Anatomy of a Real HR Skill: The Compensation Analysis Deep Dive

Abstract principles are useful. Working examples are better. Here’s what a production-grade compensation Skill looks like for a mid-sized organization, with annotations explaining why each piece exists.

The Skill lives in a folder structure like this:

comp-analysis/
├── SKILL.md              # Core instructions
├── band-structure.md     # Current comp bands by level and function
├── market-data-guide.md  # How to interpret and weight survey sources
└── examples/
    └── sample-analysis.md  # Annotated example of a completed analysis

The SKILL.md file starts with frontmatter:

---
name: comp-analysis
description: Performs compensation analyses using company band structure, approved market data sources, and internal equity methodology. Use when analyzing pay equity, evaluating offer competitiveness, conducting annual merit modeling, or reviewing compensation for new roles. Handles geographic differentials, FLSA classification checks, and EEO-1 component analysis.
---

Notice the description. It includes the actual terms a compensation practitioner would use: “merit modeling,” “geographic differentials,” “EEO-1 component analysis.” This isn’t keyword stuffing. It’s making the Skill discoverable by the people who need it, using the language they actually speak.

The instruction body follows. Here’s a representative section:

# Compensation Analysis Workflow

## Before You Start

Read the current band structure from [band-structure.md](band-structure.md).
If the role involves geographic differentials, apply the tier adjustments
documented in that file before any market comparison.

## Market Data Interpretation

Read [market-data-guide.md](market-data-guide.md) for source weighting.

Our approved sources in priority order:
1. Radford (tech roles, engineering, product)
2. Mercer Total Remuneration Survey (all other functions)
3. Culpepper (startup/pre-IPO benchmarking only)

When survey data conflicts by more than 15% between sources, use the
source most specific to the role's industry and company size.
Never average conflicting sources — select the most applicable one
and note the discrepancy.

## Internal Equity Check

For any offer or adjustment, compare to:
- Direct peers (same job code, same level, same location tier)
- Adjacent peers (one level above and below in same function)

Flag any case where the proposed action creates a variance of
more than 10% from the peer median without a documented justification.

## FLSA Classification

For any new role or reclassification, apply the duties test using
our hybrid methodology:
- Primary duty must constitute >50% of work time
- For roles blending exempt and non-exempt functions, default to
  non-exempt unless three of the four secondary criteria are met
- California roles use the Borello test, not the federal economic
  reality test

## Output Format

Every analysis must include:
1. Executive summary (3-5 sentences, state the recommendation first)
2. Market positioning (percentile against applicable survey)
3. Internal equity comparison (peer group analysis)
4. Total compensation view (base + bonus + equity at current value)
5. Risk flags (FLSA, pay equity, compression, inversion)

Several design decisions here matter. The Skill references supporting files rather than cramming everything into one document. This follows what Anthropic calls progressive disclosure: Claude loads band-structure.md and market-data-guide.md only when the task requires them, preserving context window for the actual analysis. The instructions specify decision rules, not just procedures. “Never average conflicting sources” is a judgment call that took years to develop internally. Now it’s encoded. The output format ensures consistency across every analysis regardless of who runs it.

The examples/sample-analysis.md file serves as what prompt engineering researchers call a “few-shot example.” Anthropic’s best practices documentation is direct about this: including example inputs and outputs helps Claude understand what success looks like more effectively than description alone. One annotated example of a completed analysis, showing the format, the level of detail, and how edge cases were handled, teaches Claude more than ten additional paragraphs of instruction.

Building Your First Skill in Fifteen Minutes

You don’t need to start with a production-grade compensation Skill. You need to start. Here’s the minimum viable path.

Step one: Pick one task you do repeatedly that requires organizational context. Not a task Claude can already handle generically. A task where you always end up correcting the output because Claude doesn’t know something specific to your organization. Offer letters. Job descriptions. Policy exception memos. Exit interview summaries. Benefits comparison documents.

Step two: Open a text editor and write the frontmatter. Give it a name in lowercase with hyphens. Write a description that uses the actual words your team uses when they talk about this task.

Step three: Write the instructions the way you’d explain the task to someone competent but new. Don’t over-explain concepts Claude already understands. Do explain what’s specific to your organization: your terminology, your templates, your decision rules, your compliance quirks. Anthropic’s guidance here is pointed: “Only add context Claude doesn’t already have. Challenge each piece of information: Does Claude really need this explanation?”

Step four: Save it. In Cowork, Skills live in your project’s .claude/skills/ directory or in your personal ~/.claude/skills/ directory. Create a folder with the Skill’s name, put the SKILL.md inside it, and Claude picks it up automatically.

Step five: Test it by doing the actual task. Not with a synthetic prompt. With the next real instance of whatever work the Skill was built for. See what Claude gets right. See what it misses. Add what was missing. Repeat.

This iterative approach is not a shortcut. It’s the method Anthropic’s own documentation recommends. Their skill authoring best practices describe a development cycle where you work through a task with Claude, identify what context you had to provide manually, capture that context in a Skill, test the Skill with a fresh instance of Claude, and refine based on what that fresh instance gets wrong. The Skill improves every time you use it and notice a gap.

The Governance Dimension That Most Teams Miss

Here is where Skills become strategic rather than merely convenient.

A Skill isn’t just a productivity accelerator. It’s a governance mechanism. When your compensation Skill encodes your FLSA classification methodology, every analysis Claude produces follows that methodology. When your exit interview Skill specifies your adverse impact analysis approach, every analysis runs the same way. When your offer letter Skill includes your state-specific at-will language, every offer letter gets it right without someone remembering to check.

This is a fundamentally different value proposition than “AI makes things faster.” This is: AI makes things consistent, auditable, and organizationally aligned. The Skill becomes a control point.

Gartner’s research on citizen development governance is relevant here. They estimate that by 2026, citizen developers at large enterprises will outnumber professional developers four to one, and 80% of low-code tool users will operate outside formal IT departments. The governance challenge isn’t whether people will build things with AI. They already are. The question is whether what they build reflects organizational standards or individual interpretation.

Skills address this directly. A centrally maintained Skill for RIF analysis that encodes your legal team’s methodology, your WARN Act notification rules, and your adverse impact thresholds creates a standard that every practitioner follows. Not because of a policy document they may or may not have read. Because the AI enforces it every time the task is invoked. The Skill becomes the policy’s operational expression.

For HR technology teams specifically, this reframes the role. You’re not building dashboards and automations for people. You’re building the Skill layer that ensures the AI everyone is already using operates within organizational guardrails. That’s a platform function, not a service desk function. And it’s a role that gets more valuable as AI adoption accelerates.

Plugins, Connectors, and the Skill Ecosystem

Skills don’t exist in isolation. Anthropic launched plugins for Cowork in January 2026, and by February had expanded the library to cover HR, finance, engineering, legal, and operations. A plugin is a bundle that packages Skills, connectors to external services (like Google Drive, Slack, or HRIS platforms), sub-agents, and slash commands into a single installable package.

This matters for HR teams because it means Skills can interact with your actual systems. A compensation analysis Skill can pull data from your HRIS through a connector rather than requiring manual data entry. An onboarding workflow Skill can create tasks in your project management tool, draft welcome emails, and generate Day 1 documentation in a coordinated sequence. The Skill provides the organizational intelligence. The connectors provide the data access. The combination produces something that functions less like a chatbot and more like a knowledgeable colleague who happens to have API access to every system you use.

The open-source repository Anthropic published on GitHub contains plugin templates that organizations can fork and customize. Enterprise organizations can deploy plugins across teams through managed settings, ensuring that every practitioner in the compensation function has access to the same Skills with the same decision rules and compliance guardrails.

But the most valuable plugins won’t come from Anthropic or from the marketplace. They’ll come from your own team, encoding your own workflows, your own compliance requirements, your own institutional knowledge. The marketplace plugins are a starting point. The organizational plugins are the competitive advantage.

What Actually Works

The organizations getting the most value from Skills share a few common practices.

They start with the tasks where AI consistently produces “close but wrong” output. Those tasks reveal exactly what organizational knowledge the AI is missing, and that knowledge becomes the Skill. They don’t try to boil the ocean with a comprehensive Skills library on day one. They pick the three or four most-repeated, most-correction-intensive workflows and build Skills for those first.

They assign Skill ownership to subject matter experts, not to IT. The compensation lead owns the compensation Skills. The employment counsel reviews the compliance-adjacent Skills. The HRIS team maintains the data-integration Skills. This distributes the authoring load across the people who actually understand the work, which is exactly where Anthropic’s documentation says authoring should happen: “Claude A helps you design and refine instructions, while Claude B tests them in real tasks.”

They treat Skills as living documents. A Skill that was written six months ago and never updated is a Skill encoding potentially outdated policy. The best teams incorporate Skill reviews into their regular governance cadence, the same way they review SOPs and process documentation. Except Skills are shorter, more focused, and directly tied to operational output, which means they’re more likely to actually get maintained.

They version control their Skills. Because Skills are plain markdown files in folders, they can be committed to version control, reviewed in pull requests, and tracked over time. This isn’t a nice-to-have for HR. When your OFCCP auditor asks how you ensure consistency in your adverse impact analyses, “We use a version-controlled Skill that encodes our methodology and is reviewed quarterly by employment counsel” is a better answer than “Our senior analyst knows how to do it.”

And they resist the temptation to over-engineer. A 50-line Skill that captures the ten most important things about how your organization handles a specific task is more valuable than a 500-line Skill that tries to capture everything. Anthropic’s testing confirms this: keep SKILL.md under 500 lines, move detailed reference material to separate files, and trust that Claude is already smart enough to handle the parts you don’t need to specify.

The Real Question

The question is not whether your team will use AI for HR operations work. They already are, with or without your blessing. The question is whether the AI they use will carry your organization’s institutional knowledge, your compliance requirements, your decision logic, and your quality standards, or whether it will operate on generic training data and produce generic output that somebody has to fix every time.

Skills are not a product feature. They’re a design decision about how your organization’s expertise scales. Every time a practitioner corrects Claude’s output and moves on without capturing that correction in a Skill, the organization loses an opportunity to get permanently smarter. Every time someone encodes a judgment call, a compliance requirement, or a workflow decision into a Skill, that knowledge becomes available to every practitioner on the team, every time the task comes up, forever.

The HR teams that figure this out in 2026 won’t just be more efficient. They’ll have built something that doesn’t depreciate when a vendor changes their pricing model or a key employee changes jobs. They’ll have built an institutional knowledge layer that belongs to them, improves with use, and makes every AI interaction more valuable than the last.

The technology for this exists today. It’s a markdown file in a folder. The hard part, as it always is, is the organizational work: deciding what you know that’s worth encoding, writing it down clearly enough for an AI to follow, and building the habit of capturing expertise instead of hoarding it.

That’s not a technology problem. That’s a leadership one.