How Anthropic Engineers ACTUALLY Prompt Claude Code

Austin Marchese · 10m 46s · Watch on YouTube · 7 sources

I have enough verified material. Producing the document now.

Decision Card

Effort: A focused afternoon — pick one repetitive task you already do (e.g. drafting emails, a release checklist), have Claude scaffold a SKILL.md for it, then spend the rest of the time adding a real script and tightening the description field; ongoing cost is ~2 minutes per session to update the skill after each use.

Honest take: The advice is sound and matches Anthropic’s own docs, but the framing (“almost everyone is prompting wrong,” “four rules they actually use”) overstates a single idea — write reusable skills with real tools instead of one-off prompts — and the video is light on the actual failure mode it gestures at: a vague description means the skill never triggers, which is the hard part and gets one sentence. It’s an introductory explainer built around clipped conference soundbites, not an engineering deep-dive.

Concrete next steps:

  • Read Anthropic’s primary source before the video’s interpretation — the Agent Skills engineering post and skill authoring best practices (~30 min).
  • Convert your most-repeated prompt into a SKILL.md with a precise description, then add one deterministic script to its folder so Claude reruns code instead of regenerating it (~1 hr).
  • Audit which of your skills need the disable-model-invocation / user-invocable flags for side-effecting actions like deploy/send (~15 min).
  • Skip if you don’t yet have a recurring, well-defined workflow — for genuinely one-off or exploratory tasks a plain prompt is still correct, and premature skill-building just adds maintenance overhead.

TL;DR

A creator distills Anthropic engineers’ conference talks into four rules for using Claude Code: stop writing one-off prompts and build reusable skills instead, invest in the tools/scripts layer (not just the prompt), keep skills small and composable rather than monolithic, and update each skill after every use so it compounds over time. The underlying concepts are accurate and traceable to Anthropic’s published Agent Skills documentation, though the video is a beginner-oriented explainer rather than novel insider technique.

Key Points

  • Rule 1: shift from writing fresh prompts each time to invoking skills — reusable, named procedures (e.g. /draft email) — which the speaker positions as the “application layer” you control on top of the model. 01:17
  • A skill is “procedural knowledge for agents” — i.e. a folder of files — and if its description is precise, Claude auto-selects it without you explicitly calling it. 00:42
  • Rule 2: a skill has three layers — description (when to use it), instructions (the playbook), and tools (scripts, API calls, reference files) — and most people stop at instructions, missing where the leverage lives. 02:33
  • The most-cited weakness, per Anthropic’s Eric: people craft beautiful prompts but give the model bare-bones tools with no documentation and parameters named “A and B.” 03:23
  • Rule 3: build small, focused, composable skills that call each other, not one giant skill — so failures are easy to localize, improvements compound, and pieces are reusable. 04:35
  • Pattern: save the script Claude keeps rewriting inside the skill folder, trading non-deterministic AI tokens for cheaper, faster, repeatable code compute — “if you can use code instead of AI, you should.” 07:05
  • Two invocation flags: user-invocable: false hides a skill from the slash menu (agent-only), and disabling model invocation makes a skill user-only — useful for higher-risk actions like deploys or sending messages. 07:36
  • Rule 4: after each run, ask “one-time fix or should this live in the skill forever?” and write durable lessons back into the skill so the next session starts smarter. 09:36
  • A reusable closing prompt: “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?” 10:09

Notable Quotes

“Skills are organized collections of files that package composable procedural knowledge for agents. In other words, they’re folders.” 00:42

“Maybe the funniest things I see is that people will put a lot of effort into creating these really beautiful, detailed prompts. Um, and then the tools that they make to give the model are sort of these incredibly bare-bones, uh, like, you know, no documentation, func- like the parameters are named A and B.” 03:23

“Our goal is that Claude on day 30 of working with you is going to be a lot better on Claude on day one.” 09:23

Verified Claims

Claim: Skills are “organized collections of files that package composable procedural knowledge for agents.” 00:42

Claim: A skill is structured in three layers — a description/frontmatter that determines when it’s used, the instructions body, and tools/scripts/resources. 02:33

  • Sources: Agent Skills overview (Claude Docs)
  • Verdict: Confirmed — the docs define three levels of progressive disclosure: Level 1 metadata (name/description in YAML frontmatter), Level 2 the SKILL.md instructions body, and Level 3 bundled resources and executable scripts.

Claim: If a skill’s description is properly written, Claude automatically decides when to use it without an explicit call. 00:51

Claim: Skills are composable, portable, efficient, and powerful, with Claude coordinating which to use. 04:35

Claim: Saving a script inside a skill trades non-deterministic AI tokens for cheaper, faster, repeatable code execution. 07:05

  • Sources: Agent Skills overview — script execution (Claude Docs)
  • Verdict: Confirmed — docs state scripts run via bash, the script code “never loads into the context window,” only its output costs tokens, and “this makes scripts far more efficient than having Claude generate equivalent code on the fly.”

Claim: user-invocable: false hides a skill from the slash menu (agent-only), and disabling model invocation makes a skill user-only. 07:36

  • Sources: Extend Claude with skills (Claude Code Docs), Issue #19141: clarify user-invocable vs disable-model-invocation
  • Verdict: Confirmed — user-invocable: false controls slash-menu visibility (background knowledge, Claude-only), while disable-model-invocation: true prevents Claude from auto-triggering so only the user can run it (recommended for side-effecting commands like /commit, /deploy). Note: the video presents these as a clean mirror image; the docs note user-invocable: false alone does not stop Claude from triggering the skill, so the two flags are subtler than implied.

Claim: Writing lessons back into a skill makes future sessions start smarter — “Claude on day 30 is going to be a lot better than Claude on day one.” 09:23

Tools, Papers & Standards Mentioned

Follow-up Questions

  1. What concretely makes a skill description reliably trigger vs. silently fail to load? The video names this as the make-or-break factor but doesn’t show good vs. bad examples — what do Anthropic’s best practices recommend for disambiguating overlapping skills?
  2. How does skill composability actually resolve at runtime when multiple skills match a request — does Claude chain them, pick one, or can skills explicitly invoke each other, and what are the token/latency costs of deep skill chains?
  3. What are the security and governance implications of the “save scripts inside skills” pattern at team scale, given Anthropic’s own warning that skills should only come from trusted sources and can be vectors for data exfiltration?

Sources