Claude Skills in the Enterprise

The whiteboard still shows smudged arrows from last quarter's finance close: CSVs, approvals, three sign-offs. This time, Claude handled 80% of the grind in an hour—because the know-how lived in reusable skills, not in someone's head. Claude Skills, packaged as a governed, repo-first library, are the practical path to scalable, cross-domain human–AI collaboration in the Enterprise.

What You'll Learn

In this post you'll learn:

• What Claude Skills are and how they differ from prompts, MCP servers, and sub-agents
• How to build a "Skillplane"—a governed, repo-first skills library for enterprise deployment
• The practical operating model for Finance, Ops, IT, and HR teams to author and share skills without becoming programmers
• 5 common pitfalls to avoid when deploying skills at scale

Key Terms

Term	Definition
Skill	A folder containing a SKILL.md spec (triggers, steps, inputs/outputs, success checks) and optional support files that define reusable workflows for Claude
Sub-agent	Pre-configured specialist worker processes with separate contexts and tool scopes that a coordinator agent can delegate tasks to for parallel execution
MCP Server	Model Context Protocol server—governed, auditable integration points into enterprise systems like ERPs, ticketing platforms, BI tools, and source control
Domain SME	Subject Matter Expert from Finance, Operations, IT, or HR who authors skill specifications without needing programming expertise
Skillplane	The proposed operating model for deploying Claude Skills as a governed, repo-first library across enterprise departments

Mechanism

Start with the plumbing, not the poetry. A Claude Skill is a folder with a SKILL.md (purpose, triggers, inputs/outputs, steps, success checks) and optional support files (templates, fixtures, code, tests). For comprehensive implementation guidance, see Anthropic's official Claude Code Skills documentation.

Claude sees only the lightweight name/description up front; it "progressively discloses" the rest when a user request matches the skill's triggers. Multiple skills can be active at once—Claude coordinates them like a project manager. When determinism beats tokens, skills call small scripts (e.g., Python) to compute, transform, or validate.

Two things make this more than "prompt snippets":

• Shareable by default. Skills are files—easy to fork, review, diff, and version. You don't need to stand up servers or ship thick prompt payloads for every call. This is where Skills outpace raw MCP server setups for day-one collaboration: zero infra, minimal context overhead, familiar Git workflows.
• Authorable by SMEs. Non-technical domain owners can write a great SKILL.md with examples and checklists. Engineers step in only when a tiny helper script or tooling glue is warranted. The cognitive shift is from "write code" to "write a spec."

Two Socratic checks:

• If a new teammate could not execute your process from the SKILL.md alone, is it really ready for Claude?
• If a process depends on tribal knowledge, why not encode it once and let everyone (humans and AI) benefit?

Where MCP Servers and Sub-Agents Fit

• Skills → knowledge & process plane. What to do, when, with what inputs/outputs, and how to judge success.
• Sub-agents → execution plane. Pre-configured specialists (separate contexts/tool scopes) that a coordinator can delegate to for parallel work.
• MCP servers → integration plane. Model Context Protocol (MCP) servers provide governed, auditable rails into ERPs, ticketing systems, BI platforms, source control, and other enterprise systems.

Here's how these components work together in practice:

Example: Finance Quarterly Close

A quarterly close workflow might load three skills (variance analysis, narrative drafting, and figure-check), spin up two sub-agents for parallel data cleanup, and query the ERP via an MCP server with read-only scopes. Skills decide what and when; sub-agents do the work; MCP connects to enterprise systems.

Example: HR Employee Onboarding

An HR onboarding workflow demonstrates the same pattern across a different domain. The process loads four skills (equipment-requisition, account-provisioning-checklist, compliance-training-assignment, and welcome-package-generation).

One sub-agent handles IT system access requests via MCP integrations with Active Directory and Okta, while another generates personalized welcome materials using templates and employee data. The account-provisioning skill defines the sequence, approval gates, and rollback steps; the sub-agents execute in parallel where possible; and MCP servers enforce least-privilege access to HR and IT systems.

Result: what once took three days of manual coordination and email chains now completes in under an hour, with full audit trails and zero forgotten steps.

The 'Skillplane' Operating Model

Below is my proposal to deploy Claude Skills across departments, based on Anthropic's spec, Jesse Vincent's "superpowers" patterns, and the concrete implementation in my own dotfiles (see .claude/ and docs/claude-code-setup.md).

Goal: To make collaboration with AI agents routine for Finance/Ops/IT/HR without turning everyone into a programmer.

acme-inc-skillplane/
  README.md
  GOVERNANCE.md           # decision rights, approvals, deprecation
  SECURITY.md             # data classes, tool scopes, sandbox rules
  CONTRIBUTING.md         # SME workflow (no-code), PR etiquette
  CODEOWNERS              # owners per domain folder
  registry.yaml           # canonical index (name, owner, triggers, status)
  templates/
    SKILL.md              # spec template: triggers, steps, checks, I/O
    test_plan.md          # given/when/then; edge cases
    checklist.md          # privacy, safety, PII, tool scopes
  tooling/
    validate_skill.py     # lint frontmatter, links, schema
    run_tests.py          # execute scripted checks; collect KPIs
  skills/
    finance/close-quarterly/...
    ops/ticket-triage/...
    it/incident-response/...
    hr/onboarding/...

Roles (no coding required for SMEs)

• Domain SME (Finance/Ops/HR/IT): writes SKILL.md using the template—triggers, inputs/outputs, step list, failure modes, success checks—plus examples/templates.
• Skill Steward (engineer or power user): reviews structure, adds minimal helper scripts if needed, wires tests, enforces progressive disclosure.
• Security Reviewer: validates tool scopes, data classification, sandbox rules.
• Maintainer: merges, versions, monitors telemetry.

Pull-request workflow

1. SME drafts skills/<domain>/<skill>/SKILL.md.
2. CI runs validate_skill.py (lint/schema) and run_tests.py (tabletop scenarios; scripted checks if present).
3. CODEOWNERS require Steward + Security approvals.
4. Merge updates registry.yaml; a bot posts release notes to Slack/Teams.

Versioning & deprecation

• Tag skills skill:<domain>/<name>@vMAJOR.MINOR.
• Maintain a CHANGELOG section at the bottom of each SKILL.md.
• Deprecate via registry.yaml (with successor mapping) and a banner inside the skill.

Discovery & onboarding

• Expose a simple web index from registry.yaml: search by domain, triggers, inputs/outputs, owner.
• Run a 90-minute "Specs, not code" workshop for SMEs, plus a 60-minute Git 101.
• Offer a "First Skill in 30 minutes" path: copy the template, fill triggers/steps/checks, attach a sample input/output.

KPIs to prove it's working

• Adoption: active skills; unique SME contributors; % of tasks routed via skills.
• Time-to-value: median PR lead time; time-to-first-skill per team (target ≤ 2 hours).
• Quality: task success rate; rework %; incident rate tied to skill misuse.
• Ops impact: cycle time deltas per workflow (e.g., ticket triage −60%); hours saved/quarter.

Why this is friendlier than pure MCP—and still plays nicely

• Sharing problem: Skills are files. Fork, review, and ship with zero server setup. MCP shines when you need governed API access to systems (ERP, BI, tickets). Use Skills to define process; use MCP to reach systems.
• Cost & complexity: Skills keep initial token overhead tiny until invoked. MCP descriptors can front-load chunky context; Skills avoid that and still call into MCP when needed.
• Teams, not just engineers: Skills let SMEs author specs and examples. Engineers add scripts sparingly. Everyone aligns on the same template and checks.

What non-engineers must learn (but not code)

To scale this, SMEs need software engineering concepts:

• Specs: write precise triggers, inputs/outputs, step lists, and measurable success checks.
• Planning: scope in/out, name common failure modes, define handoffs.
• Testing: draft Given/When/Then scenarios and golden examples.
• Version control: branch, PR, review, merge, changelog.

That's the bar—not Python mastery. A well-written SKILL.md is the highest-leverage artifact in this system.

Objections & Limits

"We'll drown in skills."

You will—without governance. Skill sprawl is a real risk when every team starts creating their own without coordination.

Mitigation actions:

• Establish a central registry (registry.yaml) as the single source of truth
• Require CODEOWNERS approval for all new skills
• Define explicit, non-overlapping triggers for each skill
• Schedule quarterly reviews to identify redundancy and consolidation opportunities
• Deprecate unused or redundant skills aggressively—track usage metrics
• Set a "rule of three": if three teams need similar functionality, create one shared skill instead of three separate ones

"Security risk if skills run code."

Skills that execute scripts do introduce risk—treat them like any production code change.

Mitigation actions:

• Enforce mandatory security review for any skill containing executable code
• Define tool scopes explicitly (e.g., read-only vs. read-write access)
• Run skills in sandboxed environments with limited network and filesystem access
• Require peer review and approval from both domain SME and engineering steward
• Maintain comprehensive audit logs of skill executions, including inputs, outputs, and system calls
• Prefer declarative guidance in SKILL.md; use scripts only where determinism is critical
• Apply the principle of least privilege: if a skill only needs to read data, don't grant write access

"Model drift will break behavior."

Claude's capabilities evolve, and what works today might not work identically next month.

Mitigation actions:

• Write comprehensive test scenarios for every skill (given/when/then format)
• Run automated checks in CI for each PR and on a regular schedule (daily or weekly)
• Monitor telemetry for task success rates, error patterns, and execution time changes
• Set up alerts for sudden drops in success rate or spikes in error frequency
• Keep "golden examples" of expected inputs and outputs; regression-test against them
• Version skills explicitly and maintain a changelog of behavioral changes
• When model behavior changes, update tests and documentation—don't silently accept degraded performance

Risk Checklist for New Skills

Before merging any new skill, verify:

• ☐ Triggers are specific and non-overlapping with existing skills
• ☐ Inputs and outputs are clearly documented with examples
• ☐ Success criteria are measurable and testable
• ☐ Failure modes are identified with recommended recovery actions
• ☐ Data classification is documented (public, internal, confidential, restricted)
• ☐ Tool scopes are minimal and justified
• ☐ PII handling complies with company policy and regulatory requirements
• ☐ Test scenarios cover happy path and at least three edge cases
• ☐ CODEOWNERS has approved (domain SME + engineering steward + security reviewer)
• ☐ Audit logging is enabled if skill accesses sensitive systems

Implications (Policy/Ops)

• Engineers: Ship the repo template, CI linters, and tiny helper libraries. Be the Steward—not the bottleneck.
• Leaders: Fund the skill catalog/UX and the enablement program ("SOP → Skill" workshops). Make skills a first-class artifact in reviews.
• Policymakers/Security: Define approval paths for code-running skills, data-class constraints, audit trails on skill loads/execs, and a prompt-injection checklist.

Common Pitfalls to Avoid

Based on early deployments and Anthropic's guidance, watch out for these five pitfalls:

1. Treating Skills Like Scripts

The mistake: Writing skills that are just thin wrappers around Python or bash scripts, missing the opportunity for progressive disclosure and human readability.

The fix: Skills should be specifications that humans can read and execute, with scripts reserved only for deterministic operations (validation, transformation, API calls). If a human can't follow the SKILL.md to complete the task manually, Claude probably can't either.

2. Skipping the Registry

The mistake: Teams create skills in isolation without central coordination. Result: five different "ticket triage" skills that overlap and confuse users.

The fix: Maintain registry.yaml from day one. Require registration before deployment. Make discovery easy through a searchable web interface.

3. Over-Engineering on Day One

The mistake: Building elaborate CI pipelines, testing frameworks, and integration layers before anyone has written a single skill that delivers value.

The fix: Start with one high-value skill, a simple template, and manual review. Add automation incrementally as the library grows. Perfect is the enemy of shipped.

4. Token Cost Overrun

The mistake: Loading every available skill into context regardless of relevance, resulting in massive token costs and slower responses.

The fix: Use explicit trigger conditions. Only load skills when the user's request matches documented triggers. Monitor token usage per skill and optimize or deprecate expensive, rarely-used skills.

5. Forgetting Organizational Change Management

The mistake: Assuming that if you build it, they will come. SMEs need training, support, and incentives to participate.

The fix: Run workshops ("SOP → Skill in 90 minutes"). Celebrate early wins publicly. Create "First Skill" awards. Make skill authorship count in performance reviews. Provide office hours where SMEs can get help from engineering stewards.

Next Steps: Your First Skill in 30 Minutes

Ready to start? Follow this quick-win path:

Step 1: Identify Your Candidate Workflow (5 minutes)

Pick one high-friction, repetitive workflow that meets these criteria:

• Takes 30-90 minutes of manual work today
• Happens at least monthly
• Has clear inputs, outputs, and success criteria
• Doesn't require complex judgment calls

Examples: Finance close variance analysis, Ops ticket triage, IT incident runbook, HR onboarding checklist.

Step 2: Draft Your SKILL.md (15 minutes)

Use the official SKILL.md template or reference the implementation in my dotfiles/.claude directory. Include:

• Clear trigger phrases (when should Claude invoke this skill?)
• Required inputs and expected outputs with examples
• Step-by-step process (as if training a new teammate)
• Success checks and common failure modes

Step 3: Test and Iterate (10 minutes)

Run through the skill with Claude. Ask yourself:

• Did it trigger when expected?
• Were the outputs correct and complete?
• Where did it stumble or need clarification?

Refine the SKILL.md based on what you learn. The first version won't be perfect—that's expected.

Get Started Today

Clone the Anthropic Skills repository for templates and examples. For a production-ready implementation pattern, see the setup in my dotfiles documentation.

Have questions or want to share your first skill? Send me an email—I'd love to hear what you're building.

Looking Ahead

Claude Skills are our first real peek at managing a fleet of agents: shared specs, delegated execution, and governed integrations across knowledge, execution, and integration planes. The organizations that figure out the "Skillplane" operating model now will have a significant advantage as AI agents become more capable and autonomous.

Start small. Ship fast. Learn continuously.