The 4 Rules Anthropic Engineers Use to Prompt Claude Code

Objectives: understand what a skill actually is, see the model → agents → skills abstraction, and make the mental shift from one-off prompts to invoking skills.

When people start with AI, they write a fresh prompt for everything. But most real work is repetitive — the same email reply, the same script-writing task, the same review checklist. Writing a new artisanal prompt each time throws that effort away the moment the chat closes.

Anthropic built skills to capture repetitive work. In the words of an Anthropic engineer quoted in the video:

"Skills are organized collections of files that package composable procedural knowledge for agents."

Stripped of jargon: a skill is a folder that holds a documented way to get a task done. The mental shift Rule 1 asks for is simple — stop thinking in traditional prompts, start thinking in invoking skills.

The video adapts an abstraction diagram from Anthropic's engineering presentation. There are three layers:

• Layer 1 — the AI model. The raw model you are using.
• Layer 2 — agents and prompts. How most people interact with AI today: typing prompts at an agent.
• Layer 3 — skills. The application layer of the AI world.

The analogy from the video: Anthropic is building the phone. Skills are the apps. That is the layer you control, and the layer where leverage lives.

Say you want to reply to an email in your own voice. The Layer 2 way is to paste a long prompt describing your tone, style, and sign-off every single time. The Layer 3 way is to build that knowledge into a skill once, then type:

/draft-email

…and hand it the email you want to answer. The official docs confirm a key payoff: if a skill's description is well written, you do not even have to invoke it by name — Claude loads it automatically when your request matches. You are no longer writing custom prompts; you are writing requests that cleanly reference skills.

---

Objectives: learn the three internal layers of a skill, read an annotated /draft-email SKILL.md, and understand why the tools layer carries the most leverage.

Creating a skill is easy — you can literally tell Claude "build me a skill for X." Using skills well requires knowing what is inside one. A skill is not just a prompt in a folder. It has three internal layers:

1. The description. What Claude checks on every request to decide whether to use this skill. Think of it as the label on the folder: vague label, Claude can't tell when to reach for it; specific label, it triggers exactly when it should.
2. The instructions. Once Claude picks the skill, this is the playbook — the step-by-step process for completing the task.
3. The tools. Scripts, API calls, reference files. This is where a skill becomes far more than a prompt — and where most of the leverage lives.

Most people stop at layer 2. Anthropic engineers focus on layer 3. Eric from the Anthropic team, quoted in the video, put it bluntly:

"People will put a lot of effort into creating these really beautiful, detailed prompts… and then the tools that they make to give the model are sort of these incredibly bare-bones — no documentation, the parameters are named A and B."

Here is an illustrative /draft-email skill built to the documented Claude Code skill format. A skill is a SKILL.md file inside its own folder — for a personal skill, ~/.claude/skills/draft-email/SKILL.md. The file has two parts: YAML frontmatter between --- markers, then the markdown body.

---
# LAYER 1 — THE DESCRIPTION
# Claude reads this on every request to decide whether to load
# the skill. Be specific: name the trigger situations explicitly.
description: >-
  Draft a reply to an email in the user's voice. Use whenever the
  user pastes an email and asks for a response, reply, or follow-up.
---

# LAYER 2 — THE INSTRUCTIONS
# The step-by-step playbook Claude follows once this skill loads.

## Voice
- Warm but concise. No corporate filler. Sign off as "— Nat".
- Match the sender's formality; never more formal than they were.

## Steps
1. Summarize what the sender is actually asking in one line.
2. Draft a reply that answers every open question.
3. If a question can't be answered yet, say so and give a timeframe.
4. Return only the email body — no subject line, no preamble.

What each part does:

• The description is layer 1. The phrase "use whenever the user pastes an email and asks for a response" is the trigger text Claude matches against — concrete situations, not marketing copy. According to the official docs, a weak description is the single most common reason a skill silently never fires.
• Everything below the frontmatter is layer 2 — the instructions. Plain markdown. No code yet.
• This particular skill has no layer 3 because drafting an email needs no scripts. The next lesson shows a skill that does.

The video's clearest tools-layer example: the narrator needed to find available domain names. Instead of asking Claude to guess and manually checking each one, he built a custom skill that programmatically checks domain availability through a real tool. Every domain it suggested was already verified as purchasable.

The leverage compounded: with that tool inside a skill, he could point ten sub-agents at the same skill and sweep 10,000+ domains — something he says he "literally would have never been able to do before." A bare prompt could never do that; a skill with a real tool could.

---

Objectives: see why one giant skill fails, learn the three benefits of small composable skills, and apply the save-scripts and invocation-control patterns.

Anthropic's engineering blog, cited in the video, describes skills as "composable, portable, efficient, and powerful." Composability means multiple small skills work together while Claude coordinates which to use.

The video's cautionary tale: the narrator first built one /content-creation skill that did everything — idea generation, script writing, social posts. "One skill, a million possibilities," and it became unmanageable. Every change risked breaking something invisible. The fix was to split it into focused skills — youtube-idea-research, youtube-script-writer, linkedin-post — each with one job, each able to call the others.

Three concrete reasons, straight from the video:

1. Issues are easy to spot. When a focused skill breaks, you know exactly where to look.
2. Improvements compound. Upgrade youtube-idea-research once and every workflow that calls it improves automatically. A giant skill duplicates that logic, so you fix it in one place and it stays broken in another.
3. You reuse instead of rebuild. A domain-checker skill plugs into any workflow that needs available domains — you never rebuild it.

Composability is wired in the body of the skill. Here is an illustrative name-research skill that chains to the domain-checker skill — one skill calling another as a step:

---
description: >-
  Research and validate a product name. Use when the user wants a
  brandable name with a matching available domain.
---

## Steps
1. Generate 20 candidate names that fit the brief.
2. For each candidate, use the `domain-checker` skill to confirm
   the .com is actually purchasable. Discard names that fail.
3. Return only names that passed, with the verified domain.

That single line — "use the domain-checker skill" — makes Claude load domain-checker mid-workflow and hand off to it. The small skill does one thing well; the larger one composes it. Stack these and you get modular skill chains instead of one brittle monolith.

Pattern 1 — Save scripts inside skills. Barry, at the AI Engineering Code Summit, described seeing Claude rewrite the same Python slide-styling script every session. The fix: save the script inside the skill folder as a tool "for his future self." Now Claude reruns the script instead of regenerating it. The principle: if you can use code instead of AI, you should. Code is deterministic — same input, same output — and you trade expensive, variable AI tokens for cheap, repeatable compute. You don't even have to write the code; have AI write it once, then reuse it forever. Pattern 2 — Control who can invoke what. Two frontmatter flags most people have never heard of:

---
description: Deploy the current build to production.
# Only the user can run this — the model never triggers it on its own.
# Use for high-risk actions: deploys, sending messages, anything irreversible.
disable-model-invocation: true
---

• user-invocable: false hides the skill from your / menu — it becomes an agent-only tool you never think about.
• disable-model-invocation: true does the opposite — only you can run it, the model can't. Perfect for risky actions like deploying to production or sending a message.

Both behaviors are confirmed in the official Claude Code skills documentation.

---

Objectives: understand the compounding-improvement loop, learn the one question to ask after every skill run, and get a copy-paste prompt that extracts a chat session into a permanent skill.

A sentence prompt disappears the moment you close the chat. A skill stays — and every time you use it, you get a chance to sharpen it. The Anthropic engineering team framed the payoff as a guarantee, quoted in the video:

"Anything that Claude writes down can be used efficiently by the future version of itself. Our goal is that Claude on day 30 of working with you is going to be a lot better than Claude on day 1."

Every time Claude learns something about your voice, your process, or an edge case, you write it into the skill. The next session starts smarter than the last.

Most people run a skill, take the output, and move on. Anthropic engineers add one step. After each run, when the output isn't quite right, ask:

Is this a one-time fix, or should this be in the skill forever?

If it's forever, update the skill — add the rule, the example, the missed edge case. That single habit is the difference between a skill that plateaus and one that compounds.

You don't have to do this by hand. Your chat history is the raw material. After a back-and-forth where you corrected Claude several times, paste this:

Review the back and forth I just had after using this skill. Can we enhance the skill so this is handled automatically and we don't make the same mistake again?

Claude reads the correction trail and folds those lessons into the skill's instructions. That is the entire improvement loop: use the skill → notice what was wrong → ask whether it belongs in the skill forever → persist it. Iterate, extract, persist.

---

The Four Rules, In One Place

1. Use skills, not prompts. Stop writing one-off prompts; invoke skills.
2. Build tools, not just skills with prompts. The leverage is in layer 3 — scripts, APIs, files — not a prettier prompt.
3. Build composable skills, not custom skills. Small, focused, reusable skills that chain beat one unmanageable monolith.
4. Update your skills every time you use them. Each session is a chance to make the skill — and Claude — permanently better.

Using Claude like an engineer isn't about technical skill. It's about treating skills as the durable artifact and prompts as disposable.

---

Source: This guide is based on How Anthropic Engineers ACTUALLY Prompt Claude Code, with skill-format details verified against the official Claude Code skills documentation. Direct quotes from Anthropic engineers (Barry, Eric, and the engineering team) are reproduced from the video; the /draft-email, name-research, and domain-checker skill files are illustrative examples written to the documented skill format.