AI

Claude Skills in depth: what they look like with and without

This is a practical, in-depth guide to Claude Skills — what they are, how to add them, which ones to install, and how to write your own. And because the difference is easiest to see, it is built around pictures: what a task actually looks like without a Skill versus with one.

It is written in plain language, with worked examples you can see, more detail on how Skills work under the hood, and a practical path for rolling them out across a team. If you only read one section, make it the three before-and-after examples below.

The one-line idea

Claude is a brilliant generalist. A Skill makes it a specialist at one job, done your way — and it remembers. You write the instructions once, hand them over as a small folder, and from then on Claude does that task the same way every time. No re-explaining, no copy-pasting a prompt you keep in a notes app.

The difference is easiest to see. Here is the same request, answered first with no Skill, then with the right Skill installed.

Example 1 — Making a document

You ask for a board report. Without a document Skill, Claude does its best with plain text. With the pdf skill installed, it produces an actual file — cover, brand bar, a chart, a clean table, footed pages.

EXAMPLE · DOCUMENTS“Turn these Q3 numbers into a branded report I can send the board.”
No skill

# Q3 Results

Revenue was 2.4M, up 18% on Q2. Churn fell to 3.1%. New customers: 412. Here is a summary you can copy into a document…

* Revenue: 2.4M
* Churn: 3.1%
* New: 412

A wall of plain text. No layout, no brand, not a real file you can send.

With pdf skill
Q3 Board ReportAzoth Edge · ConfidentialPage 1 of 6

A real PDF — cover, brand bar, a chart, a clean table, page footer.

Nothing about the request changed. The only difference is that one version knows how to build a real PDF, because someone taught it once. The same is true for docx, xlsx and pptx — Word docs with tracked changes, Excel models with pivots and charts, branded slide decks.

Example 2 — Reviewing SQL

Generic Claude will happily tell you a query “looks fine.” A Skill that knows your schema does something far more useful: it checks the query against your tables and indexes, flags what will be slow in production, and rewrites it.

EXAMPLE · SQL REVIEW“Review this query before it ships to production.”
No skill

Looks fine to me! 👍 The query is valid SQL and should return the rows you want.

A friendly shrug. Nothing about your schema, your indexes, or what will be slow.

With sql-reviewer skill

⚠ Full table scan on orders — no index on customer_id.

Fix add idx_orders_customer, then:

SELECT o.id, o.total
FROM orders o
WHERE o.customer_id = $1
  AND o.created_at >= now() - interval '30 days';

Checked against your schema: catches the full table scan and rewrites it.

This is the kind of Skill nobody can publish for you, because it depends on your database. That is exactly why it is so valuable — and, as we will see, so easy to build.

Example 3 — Writing code the safe way

Ask for a new feature and Claude will write the code. Ask with the test-driven-development skill on, and it changes the order of operations: a failing test first, then just enough code to pass, then a clean-up. Edge cases get caught before they ship, not after.

EXAMPLE · TEST-DRIVEN“Add a discount-code feature to checkout.”
No skill

Sure — here is the applyDiscount() function and the checkout wiring.

// 80 lines of code, no tests yet…

Jumps straight to code. Tests come later, if at all — and edge cases slip through.

With TDD skill
1 · RED — write a failing test for an expired code2 · GREEN — minimal code to pass3 · REFACTOR — clean it up, tests still green

Failing test first, then just enough code, then a tidy-up. Edge cases are caught up front.

That is the whole point of Skills in one picture: not a smarter model, but a disciplined one, following the method you would want a careful colleague to follow.

The newest skills — when Claude works while you don’t

The three examples above are about quality: the same task, done properly. The latest additions to Claude Code are about something different — time. They let Claude keep working between your turns, on a schedule, or as a whole team of agents at once. These ship built into Claude Code as slash-commands rather than as files you install, but the idea is the same: hand over a job, get it done your way. Here are the three worth knowing, each as a before-and-after.

/loop — stop babysitting long jobs

This is the one people ask about most. A deploy, a CI run, a slow build — anything you would normally sit and re-check. With /loop, Claude does the re-checking for you, and the clever part is how it paces itself.

LATEST · /loop“Watch the deploy and tell me the moment it is done.”
By hand
$ check deploy… still building$ check deploy… still building$ check deploy… still building…you, every few minutes, all afternoon

You re-check every few minutes and hope you catch the moment it lands.

With /loop
> /loop check the deployiter 1 · building — waits 2miter 2 · still building — backs off, waits 5miter 3 · ✓ live — pinged you, loop ends

Claude polls for you, waits longer when it is quiet, pings you the moment it lands — then stops on its own.

There are two modes. Give it an interval — /loop 5m check the deploy — and it runs on a fixed cadence. Leave the interval off — /loop check whether CI passed and fix any review comments — and Claude chooses the wait itself after each pass: short while a build is active, longer once things go quiet, and it can end the loop on its own once the job is provably done. A bare /loop runs a built-in “tend the branch” maintenance prompt, or your own .claude/loop.md if you write one. Loops are session-scoped and expire after seven days, so a forgotten one can’t run forever.

/schedule — work that runs without your laptop

/loop needs your session open. A Routine does not. You define a job once — a prompt, the repo it may touch, the connectors it needs — and it runs on Anthropic’s cloud on a schedule, on a GitHub event (a PR opened, a release published), or on your own webhook. Your machine can be off.

LATEST · /schedule · Routines“Triage new issues every weekday morning.”
Only if you remember

Mon — ran it ✓

Tue — forgot 🙈

Wed — laptop was asleep

Thu — ran it ✓

It runs when your laptop is on and you remember to kick it off. Miss a day and nothing happens.

With a Routine
☁ Cloud routineTriage new issues⏱ Weekdays · 9:00 local◇ myrepo · runs on a fresh clonefired today — labelled 5, asked 2 for repro

A cloud agent fires on a schedule — or on a GitHub event — with no machine running and nothing to remember.

The trade-off is simple: /loop is for quick polling during a session and can see your local files; a Routine is for work that must happen reliably whether or not you are at your desk, and runs on a fresh clone in the cloud. Weekly dependency checks, morning issue-triage, a post-merge review — set them once and forget them.

/code-review ultra — a whole review team, not one tired reader

A normal review is one pass. Ultra review sends your branch to a fleet of agents in the cloud that review in parallel, each from a different angle, and then runs an adversarial pass that tries to disprove every finding — so the false alarms get dropped and only the real bugs reach you.

LATEST · /code-review ultra“Review this branch before we merge.”
One pass

LGTM 👍 A couple of nits on naming, otherwise looks good to merge.

A single read-through. Subtle bugs slip past a tired reviewer at 6pm.

With ultra review
4 agents · parallel⚠ race condition in retry path — confirmed⚠ off-by-one on page boundary — confirmed✕ "possible N+1" — refuted, dropped

A fleet of agents reviews in parallel in the cloud, then an adversarial pass throws out false alarms — only real findings remain.

It is the heavyweight option: slower and billed as extra usage, so you reach for it before a risky merge, not on every tiny change. For everyday diffs, the lighter /code-review is plenty. Think of ultra as the second opinion you call in when the stakes are high.

Two more newer building blocks are worth a mention even without a picture. Sub-agents let Claude fan a big job out to several agents working in parallel — one reads the database layer while another reads the API — then gather the answers. And persistent memory lets Claude keep notes across sessions, so you stop re-explaining your project every morning. Together with /loop and Routines, the direction is clear: less of you waiting on Claude, more of Claude working while you get on with something else.

What a Skill actually is

Underneath, a Skill is refreshingly boring: a folder with one required file, SKILL.md. That file has a name, a description, and instructions. It can optionally bundle scripts and reference files alongside it.

---
name: sql-reviewer
description: Review and optimise SQL against our schema and conventions.
  Use when the user writes, reviews, or tunes SQL queries.
---

# SQL reviewer

When given a query, check it against db/schema.sql, flag full table
scans, suggest indexes, and rewrite to our house style...

The clever part is how Claude uses it. It always sees the name and description of every installed Skill — that is cheap, just a sentence each. But it only loads the full instructions when your request matches the description. So you can install dozens of Skills and only “pay” (in context, in attention) for the one or two a given task actually needs. This is why the description matters so much: it is the trigger. A vague description means the Skill never fires; a sharp one (“Use when the user writes, reviews, or tunes SQL”) means it fires at exactly the right moment.

Adding Skills — every way that works

On the web (claude.ai)

Go to Settings → Capabilities and switch on “Code execution and file creation.” Then open Customize → Skills. From there you can toggle the built-in Skills (the document ones live here) or click “+” → “Create skill” → “Upload a skill” to drop in your own as a ZIP. This works on Free, Pro, Max, Team and Enterprise plans.

In Claude Code (the terminal)

Two routes. The first is just files — drop a folder in place:

# personal, available everywhere
~/.claude/skills/<name>/SKILL.md

# project-local, shared with your team through Git
.claude/skills/<name>/SKILL.md

The second is marketplaces, which is where the good community Skills live. You add a marketplace once, then install Skills like apps:

# add a marketplace, then install from it
/plugin marketplace add anthropics/skills
/plugin install document-skills@anthropic-agent-skills

# or clone any skill repo straight into your skills folder
git clone https://github.com/owner/skill-name ~/.claude/skills/skill-name

Project-local Skills (the .claude/skills/ route) are the quiet hero for teams: commit them to your repo and every teammate — and every CI run — gets the same Skill automatically, no setup.

The Skills actually worth installing

Grouped by the job they do. Sources and install lines follow in the next section.

Documents & data

  • pdf, docx, xlsx, pptx (anthropics/skills) — the document workhorses from Example 1. Build a branded deck, generate an Excel model with pivots and charts, edit Word docs with tracked changes, pull text and tables out of PDFs. Install: /plugin install document-skills@anthropic-agent-skills.
  • csv-processing — parse, clean, validate and analyse CSV files. The everyday data-wrangling skill.
  • SQL — build your own (Example 2). A Skill that knows your schema, naming and query conventions beats any generic one. We show how below.

Code quality & QA

  • test-driven-development (obra/superpowers) — the RED → GREEN → REFACTOR discipline from Example 3. Pairs with testing-anti-patterns and condition-based-waiting for non-flaky async tests.
  • systematic-debugging (superpowers) — a four-phase root-cause method instead of guess-and-check, plus verification-before-completion to prove the fix actually works.
  • webapp-testing (anthropics/skills) — drives a real browser with Playwright to verify your UI works.
  • requesting-code-review / receiving-code-review (superpowers) — a pre-review checklist with severity-tagged findings, and a calm way to fold feedback back in.

Thinking before building (the “grill”)

  • brainstorming (superpowers) — a Socratic grilling that interrogates your plan with hard questions before you write a line of code. The cheapest way to kill a bad idea.
  • writing-plans (superpowers) — breaks work into tiny, verifiable tasks with exact file paths, so execution is boring in the best way.
  • request-refactor-plan — turns a scary refactor into a series of small, safe commits instead of one big risky leap.

Writing & communication

  • writing-fragments → writing-shape → writing-beats — a family that takes you from a messy pile of notes, to a shaped draft, to a finished article, one decision at a time. Genuinely good for posts and proposals.
  • brand-guidelines (anthropics/skills) — keeps every document and message on-brand: your voice, your rules.
  • internal-comms — drafts memos, announcements and updates in a consistent tone.

Git, shipping & connecting tools

  • using-git-worktrees and finishing-a-development-branch (superpowers) — work several branches in parallel without losing your place, then make a clean merge/PR decision.
  • commit & PR helpers (official marketplace) — consistent commit messages and pull requests across a team.
  • mcp-builder (anthropics/skills) — build a connector so Claude can reach your own systems and data. This is how you wire Claude into the tools you already run.

Where to find them

  • github.com/anthropics/skills — Anthropic’s official collection (document skills, webapp-testing, mcp-builder, brand-guidelines, canvas-design and more) plus a template for your own. Add with /plugin marketplace add anthropics/skills.
  • obra/superpowers — the most-loved community library: TDD, debugging, brainstorming, planning, code-review and git workflows. Install with /plugin install superpowers@claude-plugins-official (or /plugin marketplace add obra/superpowers-marketplace).
  • claude.com/plugins — the official marketplace, browsable inside Claude Code with /plugin. Connectors and toolkits from teams like GitHub, Stripe and Figma.
  • “awesome-claude-skills” lists — community directories cataloguing hundreds of Skills by category. karanb192/awesome-claude-skills and ComposioHQ/awesome-claude-skills are good starting points.

Writing your own in ten minutes

The most valuable Skill is the one only you can write. Here is the whole recipe for the SQL reviewer from Example 2:

  1. Make a folder: ~/.claude/skills/sql-reviewer/.
  2. Drop your schema.sql in it, so Claude can see your real tables.
  3. Add a SKILL.md with a sharp description and your house rules (the snippet earlier is a complete starting point).
  4. Ask Claude to review a query. The description matches, the Skill loads, and you get Example 2’s output.

That is the entire loop. The hard part is not the format — it is deciding what “your way” actually means, writing it down once, and never explaining it again.

One rule before you install anything

Skills can run code on your machine, so treat installing one exactly like installing software: prefer Skills you wrote or that come from a source you trust, and read the SKILL.md first. Two minutes of reading is cheap insurance against a Skill that quietly does something you did not ask for. For teams, the project-local .claude/skills/ folder plus normal code review is the safest model — Skills get the same scrutiny as any other code you ship.

The takeaway

Look again at the three pictures above. In every case the model is the same and the request is the same — only the discipline changed. That is what a Skill is: a way to hand Claude your standards once and have them applied every time. Install a handful from the lists above to feel the difference, then write the one nobody else can publish for you — the one that knows your schema, your brand, your way of shipping. That is when Claude stops being a clever generalist and becomes genuinely yours.

Want help putting this into practice?

We turn Adobe, data and AI strategy into shipped, measurable outcomes.