Plugins and Skills: Making Claude Work Your Way
In the last post, I walked through how to get more out of Claude. Give it real source material, iterate until it sounds like you, extract your tone of voice, build up context so each conversation isn't starting from scratch.
That post ended with "build up context over time." Claude now does this automatically. It has a persistent memory system that learns your preferences, your role, how you like to work, and carries that across conversations. Combined with CLAUDE.md files that give it project-specific context, Claude remembers who you are and what you're working on.
But there's still a gap. Memory knows your preferences. CLAUDE.md knows your codebase. Neither one captures how you want things done. The methodology. The steps you follow when reviewing a PR, auditing a page for SEO issues, or writing a commit message. You've figured out what works through trial and error. You're still explaining the process manually every time.
Skills and plugins fill that gap. They're reusable expertise that travels with you across projects. The difference between "let me explain how I want this done" and "just do it the way we agreed."
If you've ever created a shell alias, a code snippet, or an editor macro, you already understand the principle. This is the same thing, applied to AI.
The Landscape
Before getting into the details, here's the mental model. Three layers of context, then the automation on top.
Memory is personal context. Claude learns your preferences, your role, your working style and carries it across conversations automatically. This is the "build up context over time" from the getting started post, but built in.
CLAUDE.md is project context. It lives in your repo and tells Claude how this specific codebase works. The architecture, the gotchas, the rules. Covered in a previous post.
Skills are reusable playbooks. A skill defines a methodology or workflow that works across any project. Think "how to run an SEO audit" rather than "how this repo is structured."
Slash commands are the user-facing shortcuts. Type /commit or /seo audit and a full workflow runs. The interface layer on top of skills.
Hooks are guardrails. They run automatically before or after Claude takes an action. You don't invoke them. They fire when something happens and prevent mistakes before they land.
Plugins bundle everything together. Skills, commands, hooks, and agents in a single installable package. Like a VS Code extension, but for Claude.
Where They Live
All three surfaces support these concepts now. The web app (claude.ai), the desktop app, and Claude Code in the terminal.
On the web and desktop, skills are installed through Settings as ZIP packages. Connectors give you one-click access to external services like GitHub, Slack, and Google Drive. The Cowork plugin marketplace has pre-built plugins for specific workflows. Slash commands come bundled with installed skills and plugins.
In Claude Code, everything is file-driven. Skills are markdown files in directories. MCP servers are configured in settings.json. Slash commands are .md files you write yourself. Hooks give you full lifecycle automation. It's more hands-on, but the tradeoff is complete control over how everything works.
The underlying format is the same. A skill is a SKILL.md file whether you're uploading it through the GUI or placing it in a directory. The why is identical across surfaces. Package your expertise so Claude does it consistently.
One thing worth knowing. Skills created in Claude Code don't automatically appear in the desktop or web app, and vice versa. But Claude Code's remote control feature lets you connect the CLI to the desktop app, giving you access to your CLI skills and tools from the desktop interface.
Skills in Practice
The best way to explain skills is to show one. I use an SEO analysis suite that has 13 specialised skills and 6 subagents. I'll walk through three levels of complexity so you can see where to start and where it can go.
Level 1: A Focused Skill
Here's seo-schema, the simplest skill in the suite. It detects, validates, and generates Schema.org structured data for any page.
---
name: seo-schema
description: >
Detect, validate, and generate Schema.org structured data.
JSON-LD format preferred. Use when user says "schema",
"structured data", "rich results", "JSON-LD", or "markup".
---
That's the frontmatter. A name, and a description. The description is doing more work than it looks. This is how Claude decides whether to activate the skill. Those trigger phrases at the end ("schema", "structured data", "rich results") mean that when I type "check the structured data on this page", Claude automatically loads the skill and follows its methodology.
Get the description wrong and the skill never fires. Too broad and it fires when you don't want it. This is the single most important line in any skill file.
Below the frontmatter is plain markdown. Detection steps, validation rules, a list of current and deprecated schema types, output format. The skill tells Claude exactly how to approach the task, what to check, and how to present the results. It's the methodology I'd follow myself, written down once so I never have to explain it again.
One detail worth calling out. The skill references external files (references/schema-types.md) but explicitly says "do NOT load all at startup." Claude loads reference material on demand, only when it's actually needed. This is progressive disclosure. It keeps the context window clean when you have dozens of skills installed, and means Claude isn't burning tokens reading about deprecated schema types unless it's actually validating markup.
Level 2: The Orchestrator
Individual skills are useful on their own. But the real power shows up when they compose.
The main /seo skill acts as a router. It doesn't do analysis itself. It reads what you're asking for, detects the business type from homepage signals, and delegates to the right specialist.
/seo audit <url> → Full website audit with parallel delegation
/seo schema <url> → Schema detection and generation
/seo technical <url> → Technical SEO (8 categories)
/seo content <url> → E-E-A-T and content quality
/seo geo <url> → AI search optimisation
/seo plan <type> → Strategic SEO planning
Twelve sub-commands, each mapping to a specialist skill. One entry point, many capabilities.
The industry detection is a good example of why this works better as a skill than as a prompt you type each time. The orchestrator analyses homepage signals to classify the site. SaaS sites have pricing pages and free trial CTAs. Local businesses have phone numbers and service areas. E-commerce sites have product schemas and cart functionality. The analysis adjusts based on what it finds. That's logic that was refined over multiple iterations. Once it's in the skill, it runs the same way every time, whether you're auditing a SaaS product or a local plumber's website.
Level 3: Parallel Delegation
/seo audit takes it further. Instead of running checks sequentially, it spawns 6 subagents in parallel. Technical SEO, content quality, schema validation, sitemap analysis, performance measurement, and visual testing. Each subagent runs independently with its own tools and area of focus.
The output is a scored report (0-100), a prioritised action plan grouped by severity (Critical, High, Medium, Low), and desktop plus mobile screenshots. What would take an hour of sequential analysis finishes in minutes.
I won't go deep on agents here. That's a topic for its own post. The point is that skills can delegate to agents, and the skill defines when and how that delegation happens.
The File Structure
Here's what the full suite looks like on disk:
~/.claude/skills/
├── seo/ # Main orchestrator
│ ├── SKILL.md # Router + scoring methodology
│ ├── references/ # On-demand knowledge files
│ ├── schema/ # JSON-LD templates
│ └── scripts/ # Python analysis tools
├── seo-audit/SKILL.md # Full audit workflow
├── seo-schema/SKILL.md # Schema detection/generation
├── seo-technical/SKILL.md # Technical SEO
├── seo-content/SKILL.md # E-E-A-T analysis
├── seo-sitemap/SKILL.md # Sitemap analysis
├── seo-images/SKILL.md # Image optimisation
├── seo-geo/SKILL.md # AI search optimisation
├── seo-plan/SKILL.md # Strategic planning
├── seo-page/SKILL.md # Single page analysis
├── seo-programmatic/SKILL.md
├── seo-competitor-pages/SKILL.md
└── seo-hreflang/SKILL.md
~/.claude/agents/
├── seo-technical.md # 6 specialist subagents
├── seo-content.md # for parallel audit
├── seo-schema.md # delegation
├── seo-sitemap.md
├── seo-performance.md
└── seo-visual.md
13 skills, 6 agents, supporting references and scripts. It started as one file. Each new capability was just another SKILL.md following the same pattern.
The full suite is open source on GitHub if you want to see the complete implementation.
Slash Commands
Skills fire automatically when Claude detects relevance. Slash commands are the explicit version. You type /something and a workflow runs on demand.
In Claude Code, a command is a markdown file in .claude/commands/. It can accept arguments, reference files, and run shell commands. On the web and desktop, commands come bundled with installed skills and plugins.
The value is consistency. Take /commit as an example. Without it, committing is a multi-step conversation. "Stage these files, look at the recent commit style, write a message that matches, create the commit." With the command, it's one word. Same result every time.
The rule of thumb: if you do something more than three times and the steps are always the same, make it a command.
Hooks
Hooks are the part most people skip. They shouldn't.
A hook runs automatically in response to an event. You don't type anything. Claude is about to take an action, and your hook intercepts it. Five event types cover most cases:
- PreToolUse fires before Claude runs a tool. Block dangerous commands before they execute.
- PostToolUse fires after. Run linting after every file edit, for example.
- Stop fires when Claude finishes a response. Good for notifications or cleanup.
- SessionStart fires when a new conversation begins. Set up context automatically.
- UserPromptSubmit fires when you send a message. Validate or transform input.
The practical pattern: every time Claude does something you didn't want, add a hook. Force-pushed to main? Add a PreToolUse hook that blocks git push --force on protected branches. Forgot to lint? Add a PostToolUse hook that runs the linter after file edits.
Over time, the guardrails build up. The mistakes stop repeating. It's the same principle as CLAUDE.md, but for actions instead of knowledge.
Hooks are currently a Claude Code feature. The web and desktop apps don't expose hook authoring directly, though plugins can include hook definitions.
Plugins
Once you have a few related skills, some commands, and a hook or two, you're looking at a plugin. A plugin bundles everything into a single installable package with a plugin.json manifest.
I use several. Chrome DevTools MCP for live browser debugging. The GitHub plugin for PR management. Serena for semantic code navigation. And my own SEO suite with 13 skills and 6 agents.
You don't need to start with a plugin. If it's just for you and it's a few files, loose skills work fine. Graduate to a plugin when you're sharing it, or when you have skills, commands, hooks, and agents that need to work together as a unit.
Where to Start
If you've read this far and want to try it, here's the progression I'd follow.
Start with one skill for a task you do weekly. Something focused, like a code review checklist or a deployment verification. Write the SKILL.md, get the trigger description right, and test it by chatting naturally to see if Claude picks it up.
Add a slash command for anything you do more than three times with the same steps. Commits, PR creation, test runs. One command, consistent output.
Add hooks reactively. Don't try to anticipate every failure. Wait until Claude does something you didn't want, then add the guardrail. They build up naturally.
Graduate to a plugin when you've got 3-4 related skills that belong together. Not before.
The temptation is to over-engineer early. Resist it. The first version of any skill should be embarrassingly simple. The SEO suite I use started as a single skill. It grew to 13 because each addition solved a real problem, not because someone planned it that way.
What I Got Wrong
A few lessons from working with these.
Skills that try to do too much don't work well. A skill that handles "all SEO tasks" is too vague for Claude to use effectively. Splitting it into focused specialists (schema, technical, content) made each one more reliable.
Trigger descriptions need tuning. Too broad and the skill fires on unrelated conversations. Too narrow and you have to invoke it manually every time. The sweet spot takes a few iterations.
Writing skills that duplicate CLAUDE.md is a waste. If the information is project-specific, it belongs in CLAUDE.md. Skills are for methodology that applies everywhere.
And the biggest one: treating the first version as the final version. Skills improve through use. Run them, notice what's missing, add it. The feedback loop is the point.
What's Next
Skills tell Claude how to do things. They encode methodology and expertise. But they can only work with what Claude can already access.
MCP servers change that equation. They give Claude direct access to external systems. Your NAS, your workflow automation, your live documentation. That's the next post.