Source: raw/How_Anthropic_Engineers_ACTUALLY_Prompt_Claude_Code.md — YouTube tutorial qOvc9IUKEIc. Creator unidentified in transcript (refers to their own “channel” + “anti-slop agreement” + a prior video on Boris Cherny’s Claude usage as a follow-up). Quotes Anthropic engineers Eric and Barry directly from the AI Engineering Code Summit + cites the Anthropic engineering blog.
Four rules distilled from Anthropic-internal prompting practice, sourced from named Anthropic engineers’ AI Code Summit talks. Thesis: most users still prompt Claude Code like they prompt chat — sentence-shaped intent, one-shot. Anthropic’s own engineers prompt skills, treat skills as 3-layer composites (description + instructions + tools), keep skills small and composable, and update the skill every session to compound. Reframes the prompt-engineering mental model around skills as the unit of leverage, not prompts.
Key Takeaways
Rule 1 — Prompt skills, not Claude
- Stop writing one-off prompts for repetitive tasks.
- Anthropic’s framing (Eric): “Skills are organized collections of files that package composable procedural knowledge for agents. In other words, they’re folders.” Barry’s description: “procedural knowledge for agents.”
- The mental shift: instead of typing a long prompt “respond to this email in my voice / tone / style”, you write a
/draft-emailskill once, then call it with/draft-email <email>. Same task. Skill gets sharper each time it’s used. - Three-layer architecture Anthropic adapted from their engineering presentation:
| Layer | What it is | Who uses it |
|---|---|---|
| 1 | AI model (Claude Opus 4.7, etc.) | Anthropic builds it |
| 2 | AI agents + raw prompts | Where most users live today |
| 3 | Skills (the application layer) | Where Anthropic engineers spend their time |
“Anthropic is building the phone itself. You have to create the apps. That’s the layer to control.”
Rule 2 — Skills are more than prompts (the 3-layer skill model)
A skill is not just a prompt that lives in a folder. Inside every skill, three load-bearing layers:
| Layer | Purpose | Risk if neglected |
|---|---|---|
| Description | What Claude reads to decide whether to invoke the skill. Acts as the “label on the folder.” | Vague description → Claude can’t recognize when to use it. Specific description → auto-invokes correctly without explicit /slash call. |
| Instructions | The step-by-step playbook Claude follows once it grabs the skill. | This is where most users stop. |
| Tools | Scripts, API calls, reference files the skill has access to. | Where most leverage lives — and where most users skip. |
Eric (Anthropic) on the symptom of users stopping at the instructions layer:
“The funniest things I see is that 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, like the parameters are named A and B, and it’s kind of like, oh, an engineer wouldn’t be able to work with this as a function.”
Anthropic engineers do the opposite — they focus on the tools layer. Example from the video: the creator built a check-domain skill where instead of having Claude reason about domain availability in tokens, the skill calls a programmatic domain-check tool. Result: 10 subagents can iterate through 10,000+ domains in parallel to find the right one — a task that wasn’t possible with prompt-only skills.
Rule 3 — Build composable skills, not custom skills
Pulled directly from Anthropic’s engineering blog: skills should be composable, portable, efficient, and powerful.
- Composable = multiple skills can work together with Claude automatically coordinating which to use.
- Anti-pattern: one massive
/content-creationskill that generates ideas, writes scripts, drafts social posts, all in one file. Unmanageable. - Pattern: split into focused units —
/youtube-idea-research,/youtube-script-writer,/linkedin-post. Each can call the others. Claude does the chaining.
Three concrete benefits of composability:
- Issues are easy to spot. When a focused skill breaks, you know exactly where to look. With a mega-skill, you don’t know which part broke.
- Improvements compound. Update
/youtube-idea-researchonce → every workflow that calls it gets upgraded. Mega-skill = overlapping functionality + you fix in one place, still broken in another. - Reuse instead of rebuild. A
/check-domainskill plugs into any workflow. Not rebuilding the wheel each time.
Technical patterns from Anthropic engineers:
- Save scripts inside skills (tools-layer pattern). Barry at AI Engineering Code Summit: “We kept seeing Claude write the same Python script over and over again to apply styling to slides. So we just asked Claude to save it inside of the skill as a tool for his future self. Now we can just run the script — that makes everything a lot more consistent.” Token math: code is deterministic (same input → same output → reusable), AI is non-deterministic (interprets, guesses, costs tokens per run). General rule: if you can use code instead of AI, you should.
- Two invocation control flags most users don’t know about:
| Flag | What it does | Use case |
|---|---|---|
user_invocable: false | Hides the skill from the /slash menu. Only agents can invoke. | AI-internal sub-skills you don’t want polluting your menu. |
disable_model_invocation: true | Only the user can run it. The model can’t invoke it autonomously. | High-risk skills — deploy to production, send a message, drop a database. |
Rule 4 — Update your skill every session (the compounding loop)
Where Anthropic engineers pull ahead is treating skills as living artifacts.
- A one-off prompt evaporates the moment you close the chat. A skill persists. Every use is a chance to sharpen it.
- Anthropic engineering team quote: “Our goal is that Claude on day 30 of working with you is going to be a lot better than Claude on day one. 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.”
The one question Anthropic engineers ask after every skill run:
“Is this a one-time fix or should this be in the skill forever? If forever, update the skill.”
Add the rule, the example, or the edge case. Most users skip this entirely — run skill → get output → continue. Anthropic engineers run skill → get output → update the skill → compound.
One-line meta-prompt for the update loop (paraphrased from the transcript):
“Review the back and forth I just had after using this skill. Can we enhance the skill so this is handled automatically or we don’t make the same mistake again?”
The four rules zoomed out
- Use skills, not prompts.
- Build tools, not just skills with prompts. (The 3-layer model — description + instructions + tools.)
- Build skills that are composable, not custom. (Small focused vs giant mega.)
- Update your skills every time you use them. (Compounding loop.)
The transcript closes with: “Using Claude like an engineer doesn’t have to be complicated.” Followup video promised on Boris Cherny’s specific skill usage.
Open Questions
- Creator identity — not named in transcript. Likely a separate creator from the Agentic Academy (skill-systems author) given different framing + reference to “my channel” + “anti-slop agreement” branding.
- AI Engineering Code Summit primary source — the talks by Eric and Barry are the canonical sources for rules 1-3. Recording / publication URL not in transcript. Worth tracking down.
- Anthropic engineering blog post — referenced as the source for “composable, portable, efficient, powerful” framing. Specific URL not given.
- Boris Cherny skill-usage video — promised as a follow-up by this same creator.
user_invocable/disable_model_invocationflag documentation — referenced as if shipped in the official skill frontmatter spec. Verify in Anthropic skill docs.
Related
- skills — base skills reference
- skill-creator — Anthropic’s official skill-creator skill
- skill-systems-orchestrator-child-pattern — the orchestrator+child pattern (companion to rule 3 on composability)
- seven-claude-skills-run-my-business — operator catalog of curated skills
- nine-claude-code-plugins-10x-faster — operator catalog of plugins
- _index — broader prompt-engineering corpus
- troubleshooting-claude — the where-skills-fail / drift dimension
- karpathy-techniques-for-claude-code — Karpathy’s adjacent CLAUDE.md / repeatability patterns
Try It
- Audit one repetitive prompt. Pick a task you’ve prompted Claude 3+ times this month. Convert it into a skill (
/your-skill-name) with a clear description, instructions, and at least one tool reference. Useskill-creatorto scaffold it. - Add the tools layer. Wherever the skill currently asks Claude to “do X” via prompt, ask whether X could be a script. If yes — write the script once, save it inside the skill folder, reference it from the instructions.
- Audit one mega-skill. Find your largest
SKILL.md(probably one you wrote that does end-to-end content/research/posting). Decompose into 2-3 focused units. Have a tiny orchestrator skill chain them. Same logic — better leverage. - Set
user_invocable: falseon any skill that’s only meant for the agent to call autonomously (e.g., internal sub-skills). Cleans up the/slashmenu. - Set
disable_model_invocation: trueon any skill that touches production, sends messages, or runs destructive ops. Forces a human confirmation step. - Add the compounding loop. End every skill-run session by asking the meta-prompt: “Review what we just did. Can we enhance the skill so this is handled automatically next time?” Update if yes. Skip if it was truly one-off.
- Track day-30 improvement. Pick one skill. Note its
SKILL.mdsize + behavior on day 1. After 30 days of updates, compare. If it hasn’t gotten more specific to your voice/workflow, the compounding loop isn’t running.