Claude Code Custom Skills: Encoding Your Team's Standards Into AI Workflows

Your team's coding standards live in a Confluence page last updated eight months ago. New hires skim it once during onboarding. Everyone else forgot it existed.

I keep running into this pattern. Teams invest weeks writing down their conventions, then wonder why code reviews still catch the same style violations, the same missing test patterns, the same commit messages that say "fix stuff." The standards exist. Nobody reads them in the moment that matters.

As of early 2026, Claude Code custom skills solve this. A skill is a SKILL.md file you drop into your repo. Claude reads it before every relevant task, automatically. Your standards stop being documentation and start being instructions.

What Skills Are (and What They Replace)

A skill is a markdown file inside a .claude/skills/ directory. It contains frontmatter (metadata Claude uses for triggering and context loading) and a body (the instructions themselves). That's it.

What makes skills different from a CLAUDE.md project config? Scope and activation. CLAUDE.md loads on every conversation. Skills load only when triggered, either by a keyword match, an explicit slash command, or Claude's own judgment about relevance. This keeps your context window clean.

Skills use progressive disclosure. When Claude Code starts, it loads only each skill's description into context. The full SKILL.md body loads only when the skill gets triggered. Bundled reference files (API specs, templates, example collections) load on demand after that. You can install dozens of skills without burning context on the ones that aren't relevant to the current task.

Where does MCP (Model Context Protocol) fit? MCP servers give Claude access to external data like Jira tickets and GitHub PRs. Skills tell Claude how to use that data according to your team's standards. They're complementary. MCP is the input. Skills are the playbook.

Three Skills Every Engineering Team Needs

Here are three skills I set up for my engineering team. Each one replaces a standard that was being enforced manually in code reviews.

1. Code Review Checklist

---
name: code-review
description: Enforces team code review standards when reviewing code or preparing a PR
---

## Code Review Standards

When reviewing code or preparing changes for review, check every item:

- [ ] No new functions without JSDoc describing parameters and return value
- [ ] Error paths tested: every try/catch has a corresponding test case
- [ ] No magic numbers: extract to named constants
- [ ] API changes include updated OpenAPI spec
- [ ] Database migrations are reversible
- [ ] New dependencies justified in the PR description

2. Commit Message Standards

---
name: commit-standards
description: Enforces conventional commit format and scope rules when creating commits
---

## Commit Format

Follow conventional commits: `type(scope): description`

Allowed types: feat, fix, refactor, test, docs, chore, ci
Allowed scopes: api, ui, db, auth, infra, deps

Rules:
- Subject line under 72 characters
- Body wraps at 80 characters
- Reference the ticket number: `Closes PROJ-1234`
- No generic messages: "fix bug", "update code", "changes"

3. Deployment Procedure

---
name: deploy
description: Production deployment checklist for releases and deploys
disable-model-invocation: true
---

## Pre-Deployment Checklist

Before deploying to production:

1. Confirm all CI checks pass on the release branch
2. Verify database migrations run cleanly against staging
3. Check that feature flags are configured for gradual rollout
4. Update the CHANGELOG with user-facing changes
5. Tag the release: `git tag -a v{version} -m "Release v{version}"`
6. Notify #engineering in Slack after deploy completes

Notice disable-model-invocation: true on the deploy skill. That's the safety net. Claude won't trigger this skill on its own. A developer has to type /deploy explicitly. You don't want Claude autonomously starting a production deployment because it detected the word "release" in a conversation.

Scope and Safety Controls

Skills live at four levels, and the hierarchy matters.

Enterprise skills (managed settings) override everything. If your security team mandates a credential-handling standard, it applies across all projects for all developers. Project skills live in .claude/skills/ inside your repo and travel with the code. Every engineer who clones the repo gets the same standards. Beyond those two, personal skills (~/.claude/skills/) handle individual preferences, and plugin skills come from the marketplace.

The allowed-tools frontmatter field controls which tools Claude can use without asking permission when a skill is active. A code review skill might grant access to read-only tools only, so Claude reads but doesn't edit. A commit skill might whitelist git operations and nothing else. You define the boundary.

Getting Started

Five minutes to your first skill:

1. Create the directory: mkdir -p .claude/skills/my-skill
2. Write a SKILL.md file with frontmatter (name and description) and your instructions in the body
3. Test it in Claude Code by asking Claude to do something that matches your skill's description
4. Commit the .claude/skills/ directory to your repo

Anthropic maintains a public skills repository. It covers everything from code review templates to document generation. Browse the examples and use them as templates for your own.

For a deeper look at how skills fit into broader Claude Code workflows, including CI/CD integration and code review automation, start there and layer skills on top. For a complete methodology that puts skills, CLAUDE.md, and verification into a repeatable four-phase process, see The Agentic Development Starter Guide.

Your Standards, Executable

Every team has standards. Most teams enforce them through code review comments written over and over again. Skills move that enforcement earlier. Claude follows your conventions while writing the code, before it ever reaches a reviewer.

The best part? Skills are markdown files in your repo. They're just text files. Readable, reviewable, diffable. When your standards change, update the skill and every team member gets the new version on their next pull.

If you want help identifying which standards to encode first or building skills tailored to your team's workflow, let's talk.