Are Claude Skills Just an Alternative to Reading a Book or is there more than that?

I’ve too long treating skills like magic incantations of a topic that really, I don’t fully understand. I strated out not really thinking about skills or embracing them. I still don’t, fully, becuase most of what I do is command line, terminal, etc etc – I’m on top of computer use! BUT – I have a terrible weakness. Design. I could never profess to be one, and i’m certainly not going to pretend.

---

So I use a design skills, skill. It works (it’s the gen 2 flavour of “that’s vibe coded” finger pointing. Alas, for now all is quiet.

Come on then, what’s a Claude Skill?

Skills are executable knowledge. When you set up an MCP server, you give Claude access to tools , DataForSEO’s API, my local database, whatever. But tools alone don’t guarantee outcomes (quite the opposite becuase they represent a utterly different way of work execution we haven;t fully pinned down yet). Skills are this layer that tells Claude how to use its abilities tools reliably, in sequence, with guardrails that prevent the errors.

We’ve moved past the prompt engineering era. The shift happened quietly, somewhere between October’s skill launches and now. Your .claude folder has become your team’s operational brain. Meanwhile, skills have evolved from simple triggers to the substrate for agent behavior that you can truly ship on a weekly / fortnighly basis.

The “modern workspace” now, in my opinion, has three layers: tool access (MCPs), execution logic (skills), and the orchestration config that ties them together. I’m dedicating most of this post to getting that setup right, with clear differentiators between what MCPs do and what skills enable.

The Knowledge-Action Gap

Reading a README is static. Claude forgets. You ask it to do something complex, and it fumbles through the API docs again, makes the same mistake, and you end up rewriting the prompt with more detail just to get the same result tomorrow.

Skills bridge this gap by being triggers rather than documentation. Think of it like Anthropic’s kitchen analogy: an MCP is the professional kitchen, stove, knives, ingredients all laid out. A skill is the recipe that ensures you actually cook something edible instead of just waving utensils around hoping for dinner.

For SEOs and digital marketers, the difference is concrete. You don’t just want Claude to have access to a web scraper. You want it to have the skill of technical SEO auditing, crawl the site, flag broken canonical tags, spot orphaned pages, check hreflang errors, without you listing the fifteen steps every time. That’s what a skill does. It codifies the workflow so the model executes it consistently.

The .claude folder is where this lives. Commands and Skills both trigger actions, and they now live in the same folder structure because Anthropic merged them. One folder, two names for the same thing. I use skills when I don’t know what I’m doing. It’s the only part of my setup I don’t fully understand. But it works, and that’s enough to keep building.

Phase 1: Mapping the .claude Control Center

The project-level .claude/ folder is the control centre for how Claude behaves when it opens your project, and it’s the one that matters for team setups.

The hierarchy splits into two parts: CLAUDE.md at the root (the instruction manual) and .claude/rules/ inside the folder (the modular scale). CLAUDE.md is your project’s single source of truth. Architectural decisions, build commands, naming patterns, coding style. It lives at the root because Claude looks there first. The .claude/ folder holds the granular stuff: individual rules files, per-file overrides, session state if you’re running Claude Code.

Avi Chawla’s guide Anatomy of the .claude/ Folder breaks down the anatomy well, and one rule stuck: keep CLAUDE.md under 200 lines. Past that it starts eating too much context, and instruction adherence drops. I tested this at 250 lines, Claude began ignoring the bottom half of my setup instructions. Now I keep the main file lean and split detailed rules into separate files inside .claude/rules/.

Element	Purpose	Location	Length limit
CLAUDE.md	Project-wide instructions	Root directory	Under 200 lines
.claude/rules/	Modular rule files	Inside .claude/	No strict limit
Build commands	How to run/test/deploy	CLAUDE.md top section	Terse
Naming patterns	File/function conventions	CLAUDE.md or rules/	Examples-driven

Thing is, project-level .claude/ gets committed to git. It’s for the whole team. Your personal preferences (API keys, editor settings, your preferred tone for responses) live in ~/.claude/ in your home directory. That one doesn’t get committed. Two folders, same name, different jobs.

Phase 2: The Three Layers of Progressive Disclosure

Claude decides whether to load a skill based on the description field in the YAML frontmatter, and that description has a hard limit of 1024 characters. This is layer one. Always loaded, always in memory, always how Claude decides “does this conversation need the postgres-query skill or not?”

You get 1024 characters to explain what the skill does, when to use it, and what makes it different from other skills in the workspace. Not a lot. I spent about twenty minutes on a recent skill just trying to fit the description inside the limit without losing the important bits about when not to use it. The temptation is to cram in XML tags for structure. Don’t. XML in the frontmatter is blocked for security reasons. Plain text only.

If Claude decides the skill is relevant (based on that description), it loads layer two: the SKILL.md body. This is where the actual instructions live, how to validate input, what order to run steps in, edge cases to watch for. It’s only pulled into context when needed, which is why this works better than a system prompt. System prompts are always loaded. Skills get loaded on-demand.

Layer three is linked files. If SKILL.md references assets/config-template.json or references/api-spec.md, Claude s there only when the conversation hits that part of the workflow. You’re not paying token cost for documentation Claude hasn’t opened yet.

Layer	When loaded	Token cost	What it contains
YAML frontmatter	Always	~50-150 tokens	Skill name, description, trigger relevance
SKILL.md body	When relevant	~500-2000 tokens	Instructions, validation, step order
Linked files	As needed	Variable	Examples, templates, specs, context

The differentiator is conditional loading. Skills let you maintain a library of specialised expertise without frontloading everything into a single system prompt. The skill I use most is markdown-to-html, Claude loads it when I’m publishing, ignores it the rest of the time. A system prompt would carry that weight in every conversation.

Phase 3: Deploying the Skill-Creator for Rapid Setup

Using the skill-creator to build a working skill

I’ll walk through using the skill-creator to build a working skill, becuase i believe in always starting for a consistent, up to date and template based place. I use this little by comparison to my agentic prompt templates, repos, MCPs. But a skill is supposed to be static and repeatable – a skill should be the dependenable consistency AI output can lack if you’re not paying attention.

Thing is, really I understand MCP servers. I make them! Data in, may be we write that data to SQLlite, Claude processes it, data out. Skills remain slightly opaque to me. They work, the Claude design skill has helped massively, but the internal logic of when Claude invokes a skill versus when it ignores one? Still a bit of a black box from where I sit, it just feels like a consistency gotcha.

So Skills were an interesting devekopment but I have this little feeling. If i’d written “the” book on a design system that I later found as a Claude skill, I would be very upset.

---

Related