I've been using Claude Code full-time for about four months now. The default setup — install, run claude in your project directory, give it tasks — works well. But the part that actually changed how I use it is the skills system, and I've talked to maybe eight or nine developers who use Claude Code regularly without knowing it exists.
Quick version: Claude Code skills are reusable prompt modules that live as Markdown files in .claude/skills/. You invoke them via the Skill tool, and they load structured context into the conversation. Think of them as stored SOPs for recurring workflows — not macros, not plugins, but something more like documented ways of working that the agent reads and follows.
What skills actually do
A skill file is a Markdown document with a YAML frontmatter block (name, description) and then the actual instructions. When the Skill tool loads it, that content becomes part of the agent's working context for that task.
The practical effect: instead of re-explaining your debugging process every session, you write it once, give it a name, and invoke it when needed. The agent reads the full document — including specific steps, anti-patterns to avoid, verification criteria — and applies it to whatever it's working on.
I have skills set up for: code review (with project-specific conventions), database migration safety checks, SEO content publishing workflows, and a debugging sequence I adapted from scientific method principles. None of these are doing anything fancy — they're just structured instructions that would otherwise take three minutes of re-typing per session.
Skills vs plugins
This is the confusion I see most often. Claude Code plugins (more precisely: MCP servers that Claude Code connects to) expose external tools — databases, APIs, file systems, search engines. The AI can call these tools to get information or trigger actions.
Skills are different. They don't add tools. They add structured behavior patterns — sequences of reasoning, checklists, specific terminology the project uses, formats for output. A plugin gives Claude Code access to your Postgres database. A skill tells Claude Code how you want it to handle migrations specifically: what pre-checks to run, what to verify before committing, how to structure the migration file.
You'd use both: plugin to access the database, skill to apply your migration SOP.
The gap I keep seeing
Most developers discover Claude Code as a terminal-based Cursor alternative and use it that way: give it a task, review the output, iterate. That's a completely legitimate workflow.
The skills system becomes relevant when you start noticing that you're giving the same context repeatedly. "When you're doing X, always do Y first. Check for Z. Don't do W." If you're saying that more than a couple of times, it probably belongs in a skill.
The friction point is that writing a good skill takes 20-30 minutes, which is hard to justify in the moment. The payoff shows up over repeated sessions — which means developers who only use Claude Code occasionally don't hit the friction point and never develop the habit.
How I structure mine
I keep skill files simple: name, one-paragraph description (this matters for the description frontmatter — it's how the agent decides whether a skill is relevant), then the actual instructions in plain Markdown.
One pattern I've found useful: write the skill by capturing what I'd actually say if I were onboarding someone to this workflow. Not what I think they should know theoretically, but what I'd tell them in the first five minutes. That framing tends to produce skills that are actually useful rather than skills that look thorough but miss the practical edge cases.
What doesn't work well
Skills are not good for:
- Context that changes frequently (use project documentation for that, not skills)
- Highly technical domain knowledge (the agent already has this; a skill adds structure, not facts)
- Tasks you only do once (the setup cost isn't worth it)
They're also not versioned by default, which creates drift over time. I do a quarterly review — checking each skill against the workflows I actually ran in the last three months and updating anything that's become stale.
The workflow skills I'd build first
If you're starting from scratch: debugging flow first (what steps to go through before escalating, what information to gather, what to check first), then code review conventions (project-specific patterns, what to flag, what to ignore), then any publishing or deployment SOP you repeat.
The skills that pay off fastest are the ones where you'd otherwise spend five minutes in the first message explaining how you want things done. Every time you save that five minutes is compounding — and the agent follows the skill more consistently than it would follow a re-typed explanation, which tends to be less precise than what you wrote when you had time to think it through.
I wrote a longer breakdown of how I use the skills system day-to-day, including the specific skill files I've built and how they interact with Claude Code's MCP setup, but that's a longer post for another day. The short version: if you're a regular Claude Code user and haven't looked at the skills system, it's worth 30 minutes of your time.
Top comments (0)