Claude Code Skills After Three Weeks: 5 Rules That Actually Make Them Work
Three weeks ago I wrote an article called "1,400 Skills, Filtered Down to 5." The most common question in the comments wasn't "Which one should I install?" — it was "How do I use them after installing?" After three weeks of use, I've found that the way most people install Skills guarantees they won't work well.
Installed Equals Unused — This Is Not an Exaggeration
Look at a real scenario: you install a code-review Skill, then eagerly ask Claude Code to review a piece of React code.
The result is a bunch of useless advice like "variable naming isn't semantic enough" or "consider adding comments."
You think: how is this any different from not installing it at all?
The problem isn't the Skill itself; it's that you didn't tell it what your project looks like. The same Skill, under different project configurations, performs drastically differently.
After three weeks of stumbling through pitfalls, I've summarized five iron rules.
Iron Rule 1: How You Write SKILL.md Is 10 Times More Important Than Which Skill You Choose
Most people install Skills this way: find one that looks good → one-click install → expect a miracle.
But a Skill is essentially a piece of prompt text. Its effectiveness depends entirely on how much context it can get about your project.
Look at this comparison:
# Bad SKILL.md (most people's state)
---
name: code-review
description: Review code for issues
---
Review the code and find problems.
# Good SKILL.md (doubles the effectiveness)
---
name: code-review
description: Review React/TypeScript code following team conventions
---
## Review Scope
- React components: check hooks dependency arrays, memo usage, re-render risks
- TypeScript: check `any` escape, type assertion abuse, missing generic constraints
- State management: check props drilling depth, context abuse
## Project Conventions
- Component files use PascalCase, hooks use the `use` prefix
- API layer uniformly uses react-query; direct `fetch` inside components is forbidden
- Error handling uniformly uses ErrorBoundary; no try-catch inside components
## Ignore Items
- Do not check style class names (Tailwind is used, no naming convention)
- Do not check import order (ESLint rules handle this automatically)
What's the difference? The second version tells the Skill three things:
- What to check (specific React/TS issues)
- Project conventions (no need to guess your coding style)
- What not to check (avoids outputting useless advice)
With the same review Skill, the first writing style outputs 10 suggestions, 8 of which are useless. The second style outputs 5 suggestions, and every single one can be applied directly.
Core principle: A Skill is an "instruction manual" for your project, not a one-sentence description.
Iron Rule 2: 3 Well-Tuned Skills > 20 Installed Skills
The Skills ecosystem already has hundreds of thousands of entries. But I now keep only 3-5.
The reason is simple: Claude Code's context window is limited. Every Skill you install consumes context space. Installing too many is like asking an AI to listen to 20 people talking at once — it can't hear any of them clearly.
My firsthand comparison:
| Configuration | Number Installed | Actual Effect |
|---|---|---|
| Install-All Type | 15+ Skills | Responses slow down, often irrelevant, sometimes contradictory |
| Curated Type | 3-5 Skills | Responses precise, fast, almost error-free |
It's like installing apps on a phone — you install 200, but you only use about 5 regularly. The rest just sit in the background consuming memory.
How to choose these 3-5? Ask yourself one question: In my daily development, which 3 scenarios do I most frequently need AI help with?
For me, they are:
- New component scaffolding (needs design + code)
- Code review (needs checking against project standards)
- Debugging tricky problems (needs systematic investigation)
Other scenarios come up occasionally, but they aren't worth keeping resident.
Iron Rule 3: A 10-Line Skill You Write Yourself Works Better Than a 100-Line Skill Someone Else Wrote (Most Counter-Intuitive)
This one is the most counter-intuitive, but it's also my biggest takeaway from three weeks.
Superpowers has 2000+ lines of configuration, Frontend Design has 500+ lines of prompts. They are indeed useful — but for your project, a 10-line Skill you write yourself might work even better than they do.
Why? Because you know your own project best.
For example, my frontend project uses the React + TypeScript + Zustand + React Query stack. I wrote a 10-line Skill:
---
name: component-scaffold
description: Scaffold React component with project conventions
---
Follow this structure when creating a new component:
1. Create ComponentName/index.tsx + ComponentName.types.ts + ComponentName.test.tsx
2. State management: local state uses useState, cross-component uses Zustand store, server data uses useQuery
3. Styling uses Tailwind, no CSS files
4. Export types and the component; keep the types file separate
5. Test file uses Testing Library, at least covering rendering and main interactions
Just these 10 lines work better than any generic component generation Skill. Because it precisely matches my tech stack and team conventions.
No matter how good a generic Skill is, it still has to guess whether you use CSS Modules or Tailwind, whether your state management is Redux or Zustand, whether your testing framework is Enzyme or Testing Library. Guessing means imprecision.
Template for writing a custom Skill:
---
name: [scenario name, use kebab-case]
description: [one-sentence description of what this Skill does]
---
## Trigger Conditions
[Under what circumstances this Skill activates]
## Execution Steps
1. [Step one]
2. [Step two]
...
## Project Conventions
- [Your tech stack]
- [Your coding standards]
- [Your file structure conventions]
Three fields are enough: when to use it, how to use it, and what the project looks like.
Iron Rule 4: Skills Should Be Chained Together, Not Used in Isolation
Most people use Skills this way: when they need a review, they call the Review Skill; when they need to debug, they call the Debug Skill. One by one, each doing its own thing.
But the truly efficient way is to chain Skills into a workflow.
My frontend development workflow:
Requirement → [brainstorming] Clarify the plan
→ [component-scaffold] Generate component skeleton
→ Write business code (I do this step myself)
→ [code-review] Automatic review
→ [tdd] Supplement test cases
The output of each step naturally becomes the input for the next. Brainstorming determines the plan, so scaffold knows what component to generate; once the code is written, the review context already contains the complete business logic.
This is much more effective than manually calling them step by step. The reason is: when used in a chain, the AI accumulates a complete context chain — it knows what you are doing, why you are doing it, and what decisions were made earlier.
When called individually, it's a cold start every time; the AI has to re-understand your intent.
Quick Reference: Skill Chaining Plans for Common Frontend Scenarios
| Scenario | Recommended Chain | Effect |
|---|---|---|
| New Feature Development | brainstorm → scaffold → code → review → test | Full process coverage, no missed steps |
| Bug Fix | debug (systematic investigation) → fix → review → test | Avoids "fixing A breaks B" |
| Refactoring | review (find problems) → plan (define scope) → refactor → test | No over-refactoring |
| Code Review | review → check file by file → summary report | No missed files, structured output |
| New Project Initialization | scaffold → directory structure → base config → doc generation | Project skeleton set up in 10 minutes |
Iron Rule 5: CLAUDE.md + Skills + .mcp.json — The Holy Trinity
This is the most easily overlooked rule.
Many people think installing Skills is enough. But Skills are just one of three configuration components:
CLAUDE.md → Global project rules ("This project uses TypeScript strict mode")
Skills → Behavior patterns for specific scenarios ("Do this when creating a new component")
.mcp.json → External tool connections ("Can access databases/API documentation")
The relationship between the three:
| Layer | File | Analogy | Function |
|---|---|---|---|
| Global Rules | CLAUDE.md | Company policy | "All code must be TypeScript, forbid any" |
| Scenario Behavior | Skills | Job manual | "Check these 5 items during review" |
| External Capability | .mcp.json | Toolbox | "Can look up API docs, read databases" |
Installing Skills without writing CLAUDE.md is like giving an employee an operations manual but not telling them the company rules. The Skill doesn't know what tech stack your project uses, what coding standards you follow, or what Git branching strategy you have — that's CLAUDE.md's job.
A minimal but complete configuration example:
# CLAUDE.md
- Tech stack: React 18 + TypeScript 5 + Zustand + React Query + Tailwind
- Code standards: ESLint + Prettier already configured, AI does not need to check formatting
- Git: commit messages use conventional commits format
- Testing: Jest + Testing Library, coverage requirement >80%
- Forbidden: `any` type, committing `console.log`, direct DOM manipulation
// .mcp.json (if your project needs external data)
{
"mcpServers": {
"context7": {
"command": "npx",
"args": ["-y", "@anthropic/context7-mcp"]
}
}
}
CLAUDE.md sets the rules, Skills set the processes, MCP connects external tools. Configure all three well, and the effectiveness of Skills at least doubles.
Ultimate Quick Reference: Skills Usage Comparison
| Wrong Usage | Correct Usage | Difference |
|---|---|---|
| Installed 15 Skills | Curated 3-5, deleted the rest | Response precision ↑↑ |
| SKILL.md only has one sentence | Clearly write review scope + project conventions + ignore items | Effective suggestion rate from 20% → 80% |
| Only use Skills written by others | Write a 10-line project-specific Skill yourself | Match rate from 60% → 95% |
| Call each Skill individually | Chain into a workflow with continuous context | Most noticeable efficiency gain |
| Only install Skills, no CLAUDE.md | CLAUDE.md + Skills + MCP holy trinity | Unlocks full capability |
| Install and ignore, expecting a miracle | Adjust configuration weekly based on usage | Continuous optimization |
The day I installed Skills three weeks ago, I thought this thing was plug-and-play. Three weeks later, I understand: Skills are not plug-and-play plugins; they are tools that need to be tuned.
Spending 5 minutes writing a project-specific SKILL.md is as effective as scouring the entire Skills marketplace.
How many Skills have you installed in Claude Code? Have you written any yourself? Share your configuration plan in the comments.