Claude Code Skills That Earn Their Keep

TLDR verdict: Skills are short markdown files that extend what Claude Code knows how to do. A well-chosen set of ten skills covers the daily grind of most engineering work: commits, reviews, tests, debugging, planning, and design. Install them in ~/.claude/skills/ or a plugin directory, invoke them via the Skill tool, chain them for bigger tasks.

This page walks through ten skills that pay back the install effort. Each one includes what it does, when to invoke it, and the invocation syntax.

What skills are

A skill is a markdown file with YAML frontmatter. Example shape:

---
name: commit
description: Create a git commit using the projects conventional-commit style.
---

# How to commit

1. Run `git status` to see pending changes.
2. Stage the relevant files.
3. Write a conventional-commit message.
4. Run `git commit -m "..."`.

The frontmatter tells Claude the skill name. The body is a prompt that fires when the skill runs. Skills are not code; they are written instructions that get injected into the agents context when invoked.

Skills live in one of two locations:

• ~/.claude/skills/.md for personal skills across every project
• /.claude/skills/.md for project-specific skills that travel with the codebase

At session start Claude Code scans both directories and registers every skill found. Invoke with the Skill tool and a skill name.

How invocation works

Claude calls the skill via the tool:

Skill(skill="commit")

The agent reads the skill body and treats it as a set of instructions for the current task. The skill can call any other tool, including other skills. This composability is the point: small, reusable pieces that combine into bigger flows.

The ten skills

1. commit

Standardizes git commits. The skill reads git status, stages the right files, drafts a conventional-commit message, and creates a commit with a co-author trailer.

Invocation:

Skill(skill="commit", args="-m 'Fix regression in dark-mode toggle'")

When to use: any time you want a well-formed commit without typing the message by hand. Especially good for repos with strict commit-message linting.

2. review-pr

Runs a full PR review: pull the branch, read the diff, check for bugs, missing tests, and style issues, then post a summary. Works well as part of a CI workflow or as a manual pre-merge check.

Invocation:

Skill(skill="review-pr", args="#482")

When to use: before merging any non-trivial PR. Adds a second set of eyes that catches the patterns a human reviewer tends to skim past.

3. test-driven-development

Forces the agent into a TDD loop: write the failing test first, confirm it fails, write the minimum code to pass, refactor, repeat. The skill includes a checklist the agent has to walk through before declaring a feature done.

Invocation:

Skill(skill="test-driven-development")

When to use: any feature or bug fix where tests matter. The discipline pays off in fewer regressions and a cleaner test suite.

4. debugging

A systematic debugging workflow: reproduce the bug, isolate the variable, form a hypothesis, test it, confirm or adjust. The skill fights the agents tendency to jump to a fix before understanding the root cause.

Invocation:

Skill(skill="debugging", args="the date picker returns yesterday in Asia/Tokyo")

When to use: any time a test is failing or a bug report is vague. Forces the agent to slow down and reason before editing.

5. brainstorming

A design-first gate before code. The skill asks the agent to enumerate approaches, compare tradeoffs, and pick one with reasoning. No file edits until the design is explicit.

Invocation:

Skill(skill="brainstorming", args="how should the chat UI handle offline mode?")

When to use: a feature where multiple reasonable implementations exist. Skipping this step is how you ship the wrong design fast.

6. writing-plans

Writes a structured implementation plan with phases, tasks, tests, and risks. The output is a markdown plan that a human can review before any code gets written.

Invocation:

Skill(skill="writing-plans", args="migrate from REST to tRPC")

When to use: any task bigger than a single file change. Plans catch bad assumptions early, when fixing them is free.

7. subagent-driven-development

Executes each plan task in a fresh subagent. Subagents inherit the plan but not each others scratch context, which keeps the main session focused.

Invocation:

Skill(skill="subagent-driven-development", args="plans/tRPC-migration.md")

When to use: multi-phase plans where each phase is independent. Lets the main agent supervise while subagents grind through the tasks.

8. executing-plans

Executes a plan in the current session with review checkpoints after each major phase. The agent pauses for human approval before moving to the next phase.

Invocation:

Skill(skill="executing-plans", args="plans/dark-mode-rollout.md")

When to use: plans where each phase builds on the previous and a human should gate the transitions. Safer than subagent-driven for high-stakes work.

9. frontend-design

Applies design patterns for web UIs: accessibility, keyboard nav, responsive layouts, visual hierarchy, empty states. The skill references a prompt about design quality that keeps the agent from shipping generic-looking components.

Invocation:

Skill(skill="frontend-design", args="pricing page with three tiers")

When to use: any time the agent is writing HTML and CSS. The default output tends toward a same-y modern look; this skill pushes toward something with more intention.

10. mcp-builder

Guides the agent through building a Model Context Protocol server. Covers the SDK choice, the tool schema, error handling, and tests.

Invocation:

Skill(skill="mcp-builder", args="build an MCP server that queries our internal metrics API")

When to use: you want a new data source or action available to Claude and nothing off-the-shelf fits. MCP is the clean way to extend the agents toolset.

Where to find community skills

The official docs ship with a starter set. Beyond that:

• The Claude Code GitHub repo lists community skills in its examples directory
• Team-specific skills usually live in the repo under .claude/skills/
• Third-party collections appear on GitHub under tags like claude-code-skills

For a new project, start with the ten above and add your own as patterns emerge. A skill is cheap: if you catch yourself repeating a prompt three times, write the skill.

Writing your own skill

Four rules for a skill that works:

1. Name it clearly. commit is better than git-commit-helper. Short names are easier to remember.
2. Write the body as instructions, not documentation. The agent runs the skill; it does not read it for reference. Use imperative voice.
3. Include a failure path. If step three cannot complete, what should the agent do? Explicit beats implicit.
4. Test it cold. Run the skill in a fresh session against a fresh repo. If it misbehaves, the skill is wrong, not the agent.

A first draft should be under 100 lines. Skills that grow past 200 lines usually deserve to be broken into smaller skills.

Skill chaining and composition

Skills can call other skills. A common chain:

1. brainstorming decides the approach
2. writing-plans writes the plan
3. executing-plans runs the plan
4. test-driven-development enforces discipline inside each phase
5. commit wraps the work up

This chain covers the full lifecycle of a non-trivial feature without the agent going off-piste. Each link narrows the scope, which keeps the token cost manageable.

For shorter tasks, invoke a single skill and move on. Not every task needs a five-step chain.

Performance notes

Skills cost tokens. Each invocation injects the skill body plus any args into the prompt. A 100-line skill runs roughly 800 input tokens per call. At Sonnet rates, that is about 2 cents. Fine for heavy use. Not fine if you invoke a 500-line skill on every turn.

Keep skill bodies tight. If a skill has three paragraphs of preamble, cut them. The agent does not need context; it needs instructions.

Troubleshooting

When a skill misbehaves:

1. Run /skills list in the session to confirm Claude sees it.
2. Read the skill body yourself. Would a human follow it correctly?
3. Check for contradictions between the skill and CLAUDE.md. The skill usually wins; make it explicit if not.
4. Rename the skill if the name is misleading; "review" is not "review-pr".
5. Rewrite the body in imperative voice, one instruction per line.

Pay-off

Ten skills, installed once, pay back every day. The up-front cost is about two hours to write them and tweak them into shape. After that, the agent behaves consistently across tasks and across teammates. That is the real value: not the skill bodies themselves, but the shared baseline they create.

A realistic first week

Most teams that adopt skills well follow a similar path in the first week. On day one, drop in the ten skills above and invoke each one against a toy task to see how the agent interprets them. On day two, notice which skills the team keeps reaching for and which ones sit unused. On day three, trim the ones nobody uses and expand the ones that do real work. By the end of the first week, the skill library settles into a set of five to eight skills that cover the daily pattern, and the team stops thinking about skills as a separate thing; they just become how the agent works.

The real signal that skills are working: nobody talks about them anymore. They fade into the background of how you run the agent, like a shortcut key you stopped noticing because it became muscle memory. That is the goal.

Short rules to remember

Keep it tight.

One skill, one job.

No fluff in the body.

Version with git.

Delete what you do not use.

The broader picture

Skills are one of three extension points for Claude Code. Hooks gate tool calls. MCP servers add new tools. Skills add new prompts. The three compose: a PreToolUse hook can require a specific skill before allowing a write, an MCP server can provide data the skill uses, and a subagent can run the skill in isolation. The whole system starts to feel less like a chatbot and more like a small, opinionated engineering platform you built to match the way you already work. That is the quiet superpower of the skill system: not that any single skill is clever, but that the set of them encodes the conventions your team has already decided on, in a form the agent can actually read and execute.