Create .claude/commands/ when you have well defined repeatable, multi-step actions you want to take. I have a command `/triage` where I provide it a bug report and it asks me questions to start scaffolding a work area, lookup related issues, create patches, etc.
Create .claude/agents/ when you have a narrow scoped thing that you want to happen, but not pollute the main context and have a well formed output. Also handy for reducing costs by using a different model for a class of actions you repeat often. For example, the "lookup related issues" from `/triage` is a Sonnet agent that finds Trac issues for a bug reports. Main context only needs the small list of matches and not the dozens of not relevant ones.
Create .claude/skills/ for job description like behaviors you want. For example, code reviewer or security researcher.
For any of these, install the `/plugin` skill-creator. Run `/init` if you don't have a claude.md and then ask the skill creator to help you improve the claude.md and create useful commands and skills.
I used them for repeated problems or workflows I encounter when running with the default. If I find myself needing to repeat myself about a certain thing a lot, I put it into claude.md. When that gets too big or I want to have detailed token-heavy instructions that are only occasionally needed, I create a skill.
I also import skills or groups of skills like Superpowers (https://github.com/obra/superpowers) when I want to try out someone else's approach to claude code for a while.
You observe what it does to accomplish a particular task, and note any instances where it:
1. Had to consume context and turns by reading files, searching web, running several commands for what was otherwise a straightforward task
2. Whatever tool it used wasn't designed with agent usage in mind. Which most of the time will mean agent has to do tail, head, grep on the output by re-running the same command.
Then you create a skill that teaches how to do this in fewer turns, possibly even adding custom scripts it can use as part of that skill.
You almost never need a skill per se, most models will figure things out themselves eventually, skill is usually just an optimization technique.
Apart from this, you can also use it to teach your own protocols and conventions. For example, I have skills that teach Claude, Codex, Gemini how to communicate between themselves using tmux with some helper scripts. And then another skill that tell it to do a code review using two models from two providers, synthesize findings from both and flag anything that both reported.
Although, I have abandoned the built-in skill system completely, instead using my own tmux wrapper that injects them using predefined triggers, but this is stepping into more advanced territory. Built in skill system will serve you well initially, and since skills are nothing but markdown files + maybe some scripts, you can migrate them easily into whatever you want later.
Anytime I do something as a one-off that I know I'll do in the future, at the end of the session I'll ask Claude to write a new skill based on what it did. For instance, I had to run some queries on Azure to check the logs for certain output and for the frequency of output. Did it once in a session and then had it write the skill for it. Now I can just run the skill whenever I need that data and it pulls it for me.
