Industry Insight · For Engineering Teams

Claude Code Skills.
The power feature most teams are ignoring.

Skills turn Claude from a smart autocomplete into a disciplined engineer that follows your team's exact playbook. Here's the SKILL.md format, the frontmatter, the directory layout, and the advanced patterns that make them production-grade.

By YNDR Engineering/Claude Code · Agent SDK/2026-05-19
The premise

Most teams are leaving Claude Code's most powerful feature completely untouched.

They use it to write functions, debug errors, and generate boilerplate. All valid use cases. All scratching the surface.

Skills change the game. They give Claude persistent, reusable instructions that transform it from a generic coding assistant into an opinionated team member that knows your architecture, your conventions, and your workflow, and follows them every single time.

Without skills, you re-explain your conventions every conversation. With skills, Claude remembers. Permanently. Version-controlled. Shippable.

What a Skill is

A markdown file with YAML frontmatter.

A Skill is a markdown file (specifically a SKILL.md) that gives Claude a structured set of instructions it loads before executing a task. Think of it as a runbook: when you invoke a skill, Claude reads the file and follows it like a senior engineer following an internal playbook.

Skills live in your project's .claude/skills/ directory (or in ~/.claude/skills/ for global skills). Each one is a self-contained unit Claude can invoke by name, via slash commands, or automatically when it detects a matching task.

The SKILL.md format

YAML up top. Markdown below.

Every skill file follows the same shape. Frontmatter configures how the skill gets activated. The body tells Claude what to do once it's loaded.

SKILL.md
---
name: my-skill
description: A concise description of what this skill does
trigger: invocation
---

# My Skill

Instructions for Claude go here. You can use full markdown:

## Step 1
Do this first.

## Step 2
Then do this.

```typescript
// You can include code examples Claude should follow
const example = "Claude will use this as a reference"
```
The frontmatter fields

Five fields. Most you can ignore.

The frontmatter is where you control the skill's identity and behavior. Start with name and description. Reach for the rest when the workflow demands it.

01name· string

Unique identifier. Used for slash command invocation.

02description· string

Claude uses this to decide when to auto-trigger the skill.

03trigger· string

invocation (manual only) or automatic (Claude triggers when the description matches the work).

04allowed_tools· string[]

Restrict which tools Claude can use during this skill.

05model· string

Override the default model. Use a fast model for high-volume, low-risk skills.

Use trigger: automatic sparingly. It's powerful, but it can fire when you don't expect it. Start with invocation and graduate to automatic once the skill has earned your trust.

Where skills live

Project-local or global.

Each skill gets its own directory. The SKILL.md file is required. Everything else is optional supporting material your skill instructions can reference. Claude can read any file in the skill directory during execution.

Project structure
your-project/
├── .claude/
│   └── skills/
│       ├── pr-review/
│       │   ├── SKILL.md
│       │   └── templates/
│       │       └── review-checklist.md
│       ├── deploy/
│       │   └── SKILL.md
│       └── migration/
│           ├── SKILL.md
│           └── scripts/
│               └── validate.sh

~/.claude/
└── skills/
    └── global-formatting/
        └── SKILL.md
Build one end to end

A PR review skill, step by step.

Say your team has specific PR review standards. You want Claude to check for breaking changes, verify test coverage, enforce naming conventions, and flag security concerns. Here's how you encode that into a skill.

01Step 1

Create the directory

One directory per skill. SKILL.md is required. Everything else is supporting material.

Terminal
mkdir -p .claude/skills/pr-review
touch .claude/skills/pr-review/SKILL.md
02Step 2

Write the frontmatter

The description field is what Claude reads when deciding whether the skill is relevant. Be specific. Vague descriptions produce vague behavior.

.claude/skills/pr-review/SKILL.md
---
name: pr-review
description: >
  Review pull requests against our team standards. Checks for
  breaking changes, test coverage, naming conventions, security
  issues, and documentation completeness.
trigger: invocation
---
03Step 3

Write the instructions

Encode your team's actual standards. Be concrete. Claude follows instructions better when they are specific rather than abstract.

.claude/skills/pr-review/SKILL.md (body)
# PR Review Skill

When reviewing a PR, follow this exact checklist:

## 1. Breaking Changes
- Check all modified function signatures for parameter changes
- Look for renamed or removed exports
- Verify database migration compatibility
- Flag any changes to public API contracts

## 2. Test Coverage
- Every new function MUST have at least one unit test
- Modified functions must have updated tests
- Integration tests required for any new API endpoint
- If test coverage drops below the team threshold, flag as blocking

## 3. Naming Conventions
- Functions: camelCase
- Components: PascalCase
- Constants: SCREAMING_SNAKE_CASE
- Files: kebab-case for utilities, PascalCase for components
- Database columns: snake_case

## 4. Security Review
- No hardcoded secrets, tokens, or API keys
- All user input must be validated and sanitized
- SQL queries must use parameterized statements
- Check for exposed internal endpoints

## 5. Output Format
Produce a structured review with:
- Summary: one paragraph overview
- Blocking Issues: must fix before merge
- Suggestions: nice-to-have improvements
- Approval Status: APPROVE, REQUEST_CHANGES, or NEEDS_DISCUSSION
04Step 4

Use it

Invoke the skill with a slash command, or reference it inside a longer instruction. Every review now hits the same checkpoints and produces the same output format.

Claude Code
/pr-review

# Or with context:
Review the PR at #142 using the pr-review skill

The result: every PR review follows the same structure, hits the same checkpoints, produces the same output format. No more inconsistent reviews depending on who, or what, is doing the review.

Advanced patterns

Six patterns that unlock serious power.

Once you're comfortable with the basics, these are the moves that turn skills from convenience into infrastructure.

01

Invocation control

Set trigger: automatic and Claude will fire the skill whenever the description matches the current work. Great for skills like 'always format SQL migrations this way' where you want consistency without remembering to invoke. Use sparingly. Start with invocation and graduate to automatic only after the skill has earned your trust.

auto-migration-format/SKILL.md
---
name: auto-migration-format
description: >
  Automatically formats SQL migration files with proper headers,
  rollback scripts, and version tracking. Triggers whenever the
  user creates or modifies a file in the migrations/ directory.
trigger: automatic
---

# Migration Formatting

When you detect a SQL migration file being created or modified:

1. Add a header comment with timestamp and description
2. Ensure UP and DOWN migrations are both present
3. Add a version number following semver
4. Validate SQL syntax before saving
02

Dynamic context loading

Skills can reference other files in their directory. Keep templates, examples, and reference docs alongside the SKILL.md and tell Claude to read them at runtime. The skill becomes a folder, not a file.

api-endpoint/ (directory)
.claude/skills/api-endpoint/
├── SKILL.md
├── templates/
│   ├── controller.ts.template
│   ├── service.ts.template
│   └── test.ts.template
└── examples/
    └── user-endpoint.ts

# In SKILL.md:
When creating a new API endpoint, read the templates in
./templates/ and follow their structure exactly. Reference
./examples/user-endpoint.ts as a working example.
03

Subagent execution

For complex multi-step skills, instruct Claude to spawn subagents. Separate Claude instances that handle parts of the task in parallel. Especially useful when the skill needs to analyze multiple files or run multiple checks at once.

full-audit/SKILL.md (excerpt)
# Full Codebase Audit

Execute the following checks in parallel using subagents:

1. Security Audit. Spawn a subagent to scan for vulnerabilities
2. Performance Check. Spawn a subagent to identify N+1 queries
   and unnecessary re-renders
3. Style Compliance. Spawn a subagent to verify code style
4. Dependency Audit. Spawn a subagent to check for outdated
   or vulnerable dependencies

Collect all results and produce a unified report.
04

Tool restriction

The allowed_tools field sandboxes what Claude can do during a skill. This is the safety boundary that turns a 'review only' skill into one that physically cannot modify files. The lock comes before the receipt.

read-only-review/SKILL.md
---
name: read-only-review
description: Review code without making any changes
trigger: invocation
allowed_tools:
  - read
  - grep
  - glob
---

# Read-Only Code Review

Analyze the codebase and provide recommendations.
DO NOT modify any files. This is a review-only skill.
05

Script bundling

Skills can include shell scripts that Claude executes as part of the workflow. Bundle validation scripts, build scripts, or test runners alongside the SKILL.md so the agent and the team are using the same source of truth.

deploy/SKILL.md
---
name: deploy
description: Deploy the current branch to staging or production
trigger: invocation
---

# Deployment Skill

Before deploying, run the validation script:

bash .claude/skills/deploy/scripts/pre-deploy-check.sh

If validation passes, proceed with deployment.
If it fails, report the errors and stop.
06

String substitutions

Use dynamic placeholders in your skill instructions that Claude resolves at runtime. Reference the current branch, file paths, user input, and other context variables to make a single skill adaptable across many situations.

Skills are version-controlled. Commit them alongside your code. When your standards change, update the skill. Every developer, human and AI, gets the update instantly.

What this means for your team

The difference between "we use Claude Code" and Claude Code is part of how we ship.

Skills encode institutional knowledge in a format that's version-controlled, shareable, and consistently executed. They're the bridge between "we use Claude Code" and "Claude Code is an integrated part of our engineering process."

Teams that invest in skills see dramatic improvements in consistency. Code reviews follow the same rubric. Migrations follow the same format. New endpoints match existing patterns. The AI isn't guessing what your team prefers. It knows, because you told it, in writing, in a file the rest of the team can read and revise.

Start small. Pick the one workflow where your team wastes the most time explaining conventions, and encode it as a skill. Once you see the results, you'll want to encode everything.

"The best AI tools don't replace process. They enforce it. Skills make Claude an opinionated team member, not a generic assistant."

YNDR Engineering

Talk to YNDR

Want hands-on Claude training
for your engineering team?

YNDR helps engineering teams master Claude Code, build production-grade skills, and ship full agentic pipelines on the Claude Agent SDK. Book a working session and we will tell you which workflow to encode first.

About YNDR · Operational AI company. Builds production agents on the Claude Agent SDK and trains engineering teams on Claude Code skills and SOPs. chris@yndr.com