Claude Code Skills: When a Full Prompt Deserves to Become a Single Command
A few weeks into using Claude Code seriously, I noticed I was typing the same paragraph at the start of every WordPress plugin session. "Apply WordPress Coding Standards. Use the existing autoloader. Don't modify files outside the directory I specify. Run phpcs after every change." Every time. Sometimes I'd forget a line and remember three messages later why the model kept producing code that wouldn't pass plugin review.
The fix is called a Skill. It takes that paragraph, files it under a slash command, and lets you summon it by name. /wp-context instead of six lines. Claude Code reads the skill file, applies the instructions, and you do the hard work with the rest of your prompt.
Most of the writing about Skills focuses on how to build one. The mechanics aren't complicated, and the official documentation covers them well. The harder question is which prompts deserve to become Skills. That's what this post is about.
What a Claude Code Skill actually is
Quick technical grounding so the rest of the post makes sense.
A Skill is a markdown file with YAML frontmatter that lives in .claude/skills/ (project-level, shared with your team via git) or ~/.claude/skills/ (personal, available everywhere). The directory name becomes the slash command. So ~/.claude/skills/wp-context/SKILL.md gives you /wp-context.
A minimal SKILL.md looks like this:
---
name: wp-context
description: Apply WordPress Coding Standards and project conventions for plugin development.
---
When working in this codebase:
- Apply WordPress Coding Standards strictly
- Use the existing PSR-4 autoloader, do not introduce a new one
- Run phpcs after every code change
- Stop after each change and wait for review before continuing
Type /wp-context at the start of a session, and Claude Code loads those instructions. That's the whole mechanism. The complexity comes from allowed-tools, disable-model-invocation, autonomous triggering via the description field, and a few other knobs. Worth reading the docs once. The interesting part is what you put inside.
The first question: Is it actually repeated?
When you start learning about Skills, the first temptation is to turn every single prompt into a Skill. Resist this as you should resist the Dark Side.
A Skill is an investment in the long term. You write it, test it, update it when the codebase changes, debug it when it stops working. Like any abstraction, it pays off only when the cost of writing and maintaining it is lower than the cost of typing the prompt every time.
If I type a set of prompts three times in a week, it's probably worth a Skill. Twice in a month, it's not. You need to measure the effort and the gains when creating a Skill.
Most of my Skills came from one specific moment: I caught myself copying a prompt from a previous chat into a new chat for the third or fourth time. That's the signal. Not "this prompt is impressive." Not "this prompt would be useful in theory." Just: I'm pasting this thing again.
What ended up promoted, in my own setup: the WordPress context paragraph. A plugin security audit checklist I wrote about in my Claude Code workflows post. A WP-CLI script generator with my standard flags (--dry-run, --verbose, batched in 200, CSV log). A commit message formatter that follows conventional commits and the team's specific scope conventions.
What I deliberately did not promote: anything I do once a quarter, anything client-specific that won't apply to the next client, anything I'm still iterating on. Skills should be stable. Prompts that are still finding their shape don't belong in a file yet.
The second question: who else needs it?
This is where Skills get interesting beyond personal productivity.
Project-level Skills live in .claude/skills/ and get committed alongside the code. Every developer on the team gets the same slash commands. The plugin security audit isn't running differently on my machine versus the junior dev's machine. Same file, version-controlled, reviewed in PRs.
A Skill committed to your repo is team infrastructure. It encodes "how we do things here" in a place the AI can actually read. Onboarding stops being a wiki nobody reads. It becomes git clone and the new dev's Claude Code already knows the conventions.
For my consultancy work, this matters even more. When I hand off a plugin to a client's internal team, I leave the Skills in the repo. The client's developers inherit my standards without having to read them, ask me about them, or argue about them in code review. The Skill is the standard.
And, keep in mind, offering Skills on GitHub is a good way to make your name known. Maybe, packing a good (like, really good) set of skills and selling it can be profitable.
The third question: what level of automation?
Skills have a switch that most tutorials gloss over. By default, a Skill can be invoked manually (/skill-name) AND triggered autonomously by Claude Code if the description matches what it's working on.
For some tasks, this is fine. The model triggering them itself just speeds things up.
For other tasks, autonomous triggering is dangerous. Anything with side effects: deploys, sending messages, publishing releases, and modifying production data. You absolutely do not want Claude Code deciding the code looks ready and triggering /deploy because the description says "deploy the application to production."
The frontmatter handles this with disable-model-invocation: true. When set, the Skill can only be triggered by you, manually, on purpose. The allowed-tools directive is the matching guardrail: a security audit Skill should have allowed-tools: Read, Grep, Glob and physically cannot modify anything, regardless of how confidently the model wants to.
Anything that touches production gets manual-only invocation and a tool allowlist. Always.
Never over-skill
I've watched developers (including myself, for a brief moment) try to turn every workflow into a Skill, or install several Skills available online. The result is a skills directory with thirty-seven files, half untouched in months, and a slash command menu that takes longer to scroll through than typing the prompt would have.
There's also a context cost. Skill descriptions load into Claude Code's context so the model knows what's available. Too many, and descriptions get truncated. The model misses the trigger you carefully wrote. Filling the budget with marginal Skills crowds out the ones that actually matter.
A Skill earns its place by being used regularly enough that you'd notice if it broke. Anything else is clutter that pretends to be productivity.
The CLAUDE.md question
CLAUDE.md is always-on context: it loads at the start of every session in that project.
Skills are on-demand context: they load when invoked.
The rule: if it applies to every session in this project, put it in CLAUDE.md. If it matters sometimes but not always, make it a Skill.
WordPress Coding Standards for a plugin repo? CLAUDE.md. The standard always applies.
A pre-handoff security audit? Skill. You run it before client handoffs, not on every session. Loading it as always-on context wastes tokens on every interaction where it doesn't apply.
Most people get this backwards. They put workflow-specific instructions in CLAUDE.md, where it pollutes every session, and they keep general standards as Skills they have to remember to invoke. The cost shows up as inconsistent behavior.
What I'd build first
If you're starting from zero, build one single Skill. The right candidate is a prompt you typed at least three times this week.
For most WordPress developers, that's probably the security audit pattern from my four workflows post. For others, it's a commit message formatter, a code review checklist, or a deployment pre-flight. The specific choice matters less than picking something boring and high-frequency.
Use it for two weeks. If you reach for it without thinking, build the second one. If you forget it exists, the answer to “Is this prompt worth promoting?" is no.
Skills multiply productivity when they encode something you actually do. They drain it when they encode something you wish you did but actually don't.
If your team is at the stage where AI tools work for individuals but not yet for the whole team, Skills as shared infrastructure is one of the cleanest fixes I know. That's exactly the kind of work I do. Drop a line.