4 Rules Anthropic Engineers Use to Prompt Claude Code
Why almost everyone is doing it wrong — and how to fix it.
I listened to Anthropic’s engineers at the AI Code Summit and learned something I wasn’t expecting: almost everyone is prompting Claude Code wrong. After studying everything Anthropic engineers have published, I uncovered four rules for how they actually prompt Claude Code — and it turns out you don’t need any technical experience to implement them.
The four rules we will cover
- Prompt skills, not Claude — shift your mental model from writing prompts to building skills.
- Skills are more than prompts — the real leverage lives in the tools layer, not the instructions.
- Build composable skills, not custom ones — small, focused, reusable skills that chain together.
- Make your prompts get smarter every session — a compounding loop of improvement.
1They Prompt Skills, Not Claude
Before we get to the rules that will transform how you work, we need to understand the foundation of how Anthropic engineers use Claude.
The mental shift
Generally, when people first start using AI, they write new prompts for everything they do. But the reality is most of what people do is repetitive tasks.
Anthropic engineers created Claude Skills to help tackle these repetitive tasks. As Barry from Anthropic describes it:
In other words, they’re folders. “Procedural knowledge for agents” is a fancy way to say a way to get a task done.
Practical example
Here’s what it could look like if you wanted to draft a response to an email:
- Old way: write a crazy prompt to help you respond to an email with your voice, your tone, and your writing style.
- New way: just type
/draft-emailand then bring in the email you want to respond to.
The three-layer model
If you were to compare this to your cell phone, Anthropic is building the phone itself. You have to create the apps. That’s the layer to control.
2Skills Are More Than Prompts
So you’re convinced you need to change how you prompt to prompt skills. The next question is: how do you actually create skills that work?
The three layers inside a skill
A skill is more than a prompt that lives in a folder. Inside a skill, there are three layers:
- Layer 1: the description. This is what Claude checks every time you ask a specific question, and it determines whether it should use the skill or not. Think of it like a title on a folder. If the label’s vague, Claude will have a tough time identifying when to use it. If it’s specific, it’ll know exactly when it’s needed. You don’t need to explicitly call a skill if it’s properly described — Claude will automatically know when to use it.
- Layer 2: the instructions. Once Claude grabs the skill, this is the playbook it follows — a step-by-step process on how to actually complete the task.
- Layer 3: the tools. This is code scripts, API calls, reference files. This is where a skill becomes a lot more than prompts, and layer three is where most of the leverage lives — but most people stop at layer two.
Real example: domain checking
Instead of going back and forth manually thinking about domains, the author created a custom skill that could check domains programmatically. Whatever domains Claude suggested, it already verified that they could be purchased.
By giving this skill access to the right tool, it leveled up the entire process. Now 10 different sub-agents could use this skill to look through 10,000+ domains to find the right one — something literally impossible to do manually.
3They Build Composable Skills, Not Custom Skills
Pulling directly from Anthropic’s engineering blog about what skills are and how to position them, they are: composable, portable, efficient, and powerful.
What does composable mean?
Composability means multiple skills can work together, with Claude automatically coordinating which to use. You should have small, focused, reusable skills that work together, versus a single massive skill that does everything.
Real example: content creation
When the author first started building skills for their content engine, they built a single /content-creation skill that did everything: generated ideas, wrote scripts, drafted social posts. All of it. One skill, a million possibilities — and it just became unmanageable.
Every time they wanted to change how scripts were written, they had to rewrite the whole skill and didn’t know what it actually impacted.
The solution? Split it into more specific skills:
/youtube-idea-research/youtube-script-writer/linkedin-post
Each skill had a specific goal in mind, and the benefit is that each can call the others, so they start chaining together.
Three benefits of composable skills
- Issues are easy to spot. When a focused skill breaks, you know exactly where to look. With a giant skill, you don’t know what exactly the issue was.
- Improvements compound. If you update
/youtube-idea-research, every workflow that uses it automatically gets upgraded. With a giant skill you get overlapping functionality — you’ll fix it in one place and it’ll still be broken elsewhere. - You can reuse instead of rebuilding. If you build something like the check-domain skill mentioned earlier, you can plug it into any workflow you want. You’re not rebuilding the wheel every time.
Technical patterns from Anthropic engineers
Pattern 1: save scripts inside of skills
This is part of the tools layer of a skill, and it’s how you actually make them sharper. Barry at the AI Engineering Code Summit explained:
Claude kept rewriting the same Python script every session. Instead of letting it rewrite the script, they saved it inside a skill folder. Now the next session Claude doesn’t have to rewrite it — it just reruns it.
General rule of thumb: if you can use code instead of AI, you should. And you don’t have to write the code — you can have AI write it once, then reuse it as much as you want.
Pattern 2: control who invokes what
Most people don’t know this exists, but Anthropic built two flags into Claude’s skills that are important to understand:
- User Invocable (set to false). This hides the skill from your slash menu. The user can’t directly invoke it — it’s only a skill for agents. Perfect for AI agent-specific tools you don’t even want to think about.
- Disable Model Invocation. This does the opposite. Only you can run it and the model can’t. Great for higher-risk things like a skill that sends a message or deploys a new version of your code to production.
4Their Prompts Get Smarter Every Session
Here’s where Anthropic engineers really pull ahead. Their skills — and in turn their prompting — don’t just work. They get better every session.
The compounding loop
When you prompt Claude with a sentence, that prompt disappears the moment you close the chat. When you prompt with a skill, the skill stays — and every time you use it, you have a chance to sharpen it.
How to actually do this
Every time Claude learns something about how you work — your voice, your process, your edge cases — you write it down in the skill. Next session starts smarter than the last.
Every time you run a skill and the output isn’t exactly what you want, ask yourself one question:
The common mistake
A lot of people skip this entirely. They just run the skill, get an output, and continue with their day. But Anthropic engineers use a skill, get the output, then update the skill so there’s a compounding loop that improves over time.
It’s really quite simple. You can literally use your chat history as a reference point to improve the skill itself. Just say:
Summary: the four rules
- Rule #1 — Use skills, not prompts. Shift your mental model from writing prompts to building skills.
- Rule #2 — Build tools, not just prompts. Focus on Layer 3 (tools), where the real leverage lives.
- Rule #3 — Build composable skills, not custom skills. Small, focused, reusable skills that work together.
- Rule #4 — Update your skills every time. Create a compounding loop of improvement.
Using Claude like an engineer doesn’t have to be complicated. Start with these four rules and watch your productivity transform.