You've been explaining your coding standards to Claude every single session. Skills are the markdown files that make it stop. Here's how they work — and why they matter for agent architecture.
Every time you explain your team's coding standards to Claude, you're paying a tax. Every PR review where you re-describe how you want feedback structured. Every commit message where you remind Claude of your preferred format. Every documentation task where you re-explain your company's voice.
That tax compounds. Across a team of five developers running twenty Claude sessions a day, you're spending real cognitive budget on the same instructions, over and over. It's not a Claude problem — it's an architecture problem.
Skills fix this.
A skill is a markdown file that teaches Claude how to do something once. Claude then applies that knowledge automatically whenever the situation matches. No slash commands. No copy-pasting prompts. No remembering to mention your preferences.
Think of it as a persistent instruction set that only activates when it's relevant. You write a SKILL.md file. It contains a description — this is how Claude decides whether to use it — and the actual instructions for the task.
# SKILL.md — PR Review Standards
description: Use this skill when reviewing pull requests.
Applies to any code review, PR feedback, or merge
request evaluation.
## Review Checklist
- Check for breaking changes in public APIs
- Verify test coverage for new code paths
- Flag any hardcoded credentials or secrets
- Ensure error handling follows team patterns
- Validate naming conventions (camelCase for JS)
## Feedback Format
Structure every review as:
1. Summary — one-line verdict
2. Critical — must fix before merge
3. Suggestions — nice to have
4. Praise — what was done wellWhen you ask Claude to review a PR, it matches your request against all available skill descriptions and finds this one. It reads the full instructions. It applies your standards. You never explain the format again.
Skills live in specific locations depending on who needs them. This is where the architecture gets interesting — and where the analogy to agent systems becomes concrete.
Personal skills live in ~/.claude/skills/ and follow you across every project. Your personal preferences: commit message style, how you like code explained, your documentation format. Think of these as your personal agent's learned behaviors. Persistent. Portable. Yours.
Project skills live in .claude/skills/ at the repository root and ship with the repo. Anyone who clones it gets these skills automatically. Team coding standards, brand guidelines, API patterns. The team's shared knowledge base — institutional memory that survives personnel changes.
Claude Code has several customization layers. The differences matter.
claude.md files load into every conversation. If you want Claude to always use TypeScript strict mode, that's a claude.md directive. It's always present, always consuming context window space, regardless of what you're actually doing.
Skills load on demand. Only the name and description are indexed. Your PR review checklist doesn't occupy context when you're debugging a memory leak — it loads when you actually ask for a review. This is smart resource management. Context windows aren't infinite, and every token matters.
Slash commands require you to remember and type them. Skills don't — Claude activates them when it recognizes the situation. The difference is the gap between a tool you have to reach for and knowledge that's just there.
This is the same principle behind Glorics' agent design. Our Monitor agents don't scan every data source for every client on every run. They match the mission brief against their capabilities, load only the relevant tools, and execute. Same pattern. Different scale.
Skills work best for specialized knowledge that applies to specific tasks. If you find yourself explaining the same thing to Claude more than twice, that's a skill waiting to be written.
The strongest candidates: code review standards your team follows, commit message formats you've agreed on, brand guidelines for web projects, documentation templates for specific contexts, and testing patterns unique to your stack.
The description field is critical — it's the matching engine. Write it the way you'd write a job description: specific enough to activate on the right tasks, broad enough not to miss edge cases.
Skills are a small-scale demonstration of something we think about constantly at Glorics: how do you build agents that accumulate institutional knowledge over time?
A skill file is static — you write it, Claude reads it. But the pattern it establishes is the foundation for dynamic learning systems where agents build and refine their own operational memory. One orchestrator reads the mission. Specialized agents load only what they need. The accumulated knowledge persists across sessions, getting sharper with every iteration.
That's not science fiction. That's what we ship on Monday mornings.