{"slug": "claude-agent-skills-how-anthropic-builds-reusable-ai-workflows", "title": "Claude Agent Skills: How Anthropic Builds Reusable AI Workflows", "summary": "Anthropic engineers Barry Zhang and Mahesh Murag have moved away from building a separate custom agent for every use case, packaging reusable \"agent skills\" — folders of instructions, scripts, and reference files — that give a general-purpose agent one narrow capability instead. The approach uses progressive disclosure, so Claude reads only a skill's name and description upfront and loads full instructions only when a task matches, and treats skills as an open, portable format testable across compatible agent tools. Anthropic's team also found Claude repeatedly rewrote near-identical Python scripts to style slide decks, wasting tokens and producing inconsistent results, and recommends saving working code into the skill folder and pointing skill.md at it instead of regenerating it.", "body_md": "# Claude Agent Skills: How Anthropic Builds Reusable AI Workflows\n\nAnthropic engineers stopped rebuilding agents for every task. Here's how Claude agent skills work and four practices that make them stick.\n\n## What are Claude agent skills, and how are they different from agents?\n\nA Claude agent skill is a packaged folder of instructions, scripts, and reference files that tells a general purpose agent how to do one specific job well, instead of asking the agent to reinvent that job from scratch every time. Anthropic engineers Barry Zhang and Mahesh Murag, who worked on agent skills at Anthropic, have described moving away from building a separate custom agent for every use case. The underlying agent turned out to be general purpose enough that the real work shifted to giving it narrow, reusable capabilities rather than rebuilding its core logic each time.\n\n## TL;DR\n\n- Anthropic’s agent skills approach treats the model and agent runtime like a **phone’s processor and operating system** , with skills acting as the apps that add specific capabilities on top.\n- Claude tends to **re-solve the same technical problems** repeatedly (like styling a slide deck), burning tokens and producing inconsistent results unless the working solution gets saved and reused.\n- **Progressive disclosure** means Claude only reads a skill’s name and description upfront, and loads the full instructions, scripts, or references only when a task actually matches that skill.\n- Vague or overlapping skill descriptions cause **trigger confusion** , where Claude guesses wrong about which skill to use or fails to use one at all.\n- Corrections should get written back into the skill file itself, turning one-off fixes into **durable instructions** the skill remembers on future runs.\n- **Self-verification** built into a skill (screenshots, source checks, persona reviews) catches problems before a human ever sees the output, instead of leaving that last 20-30% of quality control to the user.\n- Skills are described as an **open, portable format** , meaning a well-built skill folder can be tested across different compatible agent tools, not locked to one product.\n\n## \nPlans first.\n*Then code.*\n\nRemy writes the spec, manages the build, and ships the app.\n\n## Why did Anthropic engineers stop building custom agents?\n\nThe shift comes from a practical observation: once an agent runtime can already read files, write code, call tools, and reason through multi-step tasks, building a brand-new agent for every use case is redundant. Claude Code, for example, already has the general capability to research a company, draft a document, or write code. What changes from task to task isn’t the agent’s core ability to act, it’s the specific process, context, and tooling needed for that job.\n\nThat’s the logic behind the phone analogy Anthropic engineers use: the model is the processor, the agent runtime is the operating system, and skills are the apps. A handful of companies build and maintain the processor and OS. Everyone else focuses on the app layer, where a skill gives the same general-purpose agent a defined capability, like creating a presentation, researching a company, or writing a LinkedIn post, without touching the agent’s underlying architecture.\n\n## How do you stop Claude from redoing the same work every time?\n\nThe first practice is simple: save what already works instead of letting Claude regenerate it. Anthropic’s team noticed Claude repeatedly writing nearly identical Python scripts to style slide decks. Since it rebuilt the code from scratch each run, results varied and tokens were wasted on work that had already been solved once.\n\nThe fix is the same principle developers have used for decades: DRY, or “don’t repeat yourself.” Once Claude produces a script that works, save it inside the skill’s folder as a reusable file, and update the skill’s instructions (its skill.md file) to point to that saved script instead of regenerating code on future runs.\n\nIn practice, that means telling Claude something like: save the script you just used into the skill’s script folder, update the skill file so future runs execute that file, then rerun the task and verify the result. It’s still worth testing this by running the same type of task twice and confirming the skill is actually calling the saved file rather than improvising again. The surrounding output may still vary slightly, but the core logic no longer has to be reinvented.\n\n## How does Claude know which skill to use for a given task?\n\nThis is where progressive disclosure comes in. Claude doesn’t load every instruction, script, and example from every skill you’ve built at the start of a session. That would waste tokens and clutter its working context. Instead, it starts by reading only the name and description of each skill, stored in a section called YAML front matter. Only when a prompt matches a skill’s description does Claude load the full instructions and any associated scripts or reference files.\n\n## One coffee. One working app.\n\nYou bring the idea. Remy manages the project.\n\nThe tradeoff is that this system depends entirely on how precise those descriptions are. Two skills described vaguely, like “help with content” and “create marketing assets,” overlap enough that Claude has to guess which one applies. A tighter description, such as “this skill creates LinkedIn carousels from a topic, transcript, or outline; use this when the user asks for a carousel, carousel slides, or a LinkedIn document post,” gives Claude an unambiguous trigger.\n\nThe practical fix is to have Claude Code audit your own skill library: ask it to review every skill description, explain what each does, state when it should trigger, and flag any overlap with other skills. Then test each one with three prompts: an obvious request that should trigger it, a differently worded request that should still trigger it, and an unrelated request that should not trigger it at all. A skill Claude can’t reliably find is functionally a skill you don’t have.\n\n## Can Claude actually learn from its own mistakes?\n\nSkills can capture corrections as durable instructions, but they don’t function as a full memory of every conversation. When you tell Claude to “fix it” and move on, the correction typically doesn’t carry forward, only the single output changes, not the underlying process.\n\nThe alternative is treating each correction as a signal about where the skill itself needs updating. If Claude used the wrong tone, skipped a validation step, or formatted something incorrectly, that gets written back into the skill.md file as an instruction, not just patched in the current chat. If Claude is missing brand voice or specific examples, those go into a reference file inside the skill. If the same mistake recurs, a clear rule gets added to explicitly prevent it.\n\nA useful prompt structure here: review what went wrong, decide whether the cause was the process, missing context, a weak rule, or unreliable code, then update the skill in the smallest durable place, rerun the task, and verify the fix. Over time, the skill becomes a record of how a specific job should be done, shaped by actual corrections rather than one-off fixes.\n\nIt’s worth being precise about what this can and can’t do. A skill can’t force a weaker model to match a stronger model’s output, different models still interpret the same instructions differently. But because agent skills are described as an open format, the same skill folder can, in principle, be tested across compatible agent tools. If a skill falls apart on a different agent, that usually points to hidden assumptions or missing examples that need tightening.\n\n## Why does self-verification matter more than the other three practices?\n\nOf the four practices, built-in verification addresses the most common failure mode in AI workflows: an agent hands back a first attempt and calls it finished, leaving the user to catch formatting problems, unsupported claims, or tone mismatches manually. That’s the AI doing roughly 70-80% of a job and the human doing the rest as unpaid quality control.\n\n### Built like a system. Not vibe-coded.\n\nRemy manages the project — every layer architected, not stitched together at the last second.\n\nThe fix is to bake the checks a human would normally do into the skill itself. For a slide deck, that might mean rendering each slide as an image, inspecting it for cropping or readability issues, and re-rendering before returning it. For a research report, it means opening primary sources, matching claims to evidence, and removing anything that can’t be verified. For more subjective work like ad copy or scripts, it can mean running the draft past a few different agent personas, a skeptical buyer, a confused beginner, a member of the target audience, and revising based on issues that show up more than once.\n\nVerification has to rely on evidence outside the model’s own judgment: a screenshot, a test result, a cited source, a reference example, or multiple independent reviews. Simply asking Claude to reread its own draft and confirm it looks fine doesn’t count. A workable prompt pattern: define acceptance criteria before starting, create a first draft, inspect it using a relevant verification method, fix every issue found, run another pass, and only return the output once it meets the criteria, with a note on what was checked and what still can’t be verified.\n\nDone well, this turns the first output a human sees into something closer to a fourth or fifth draft, with the obvious problems already caught. The human still makes the final call on taste, strategy, or judgment calls that AI can’t fully own, but stops spending time catching errors the skill could have caught itself.\n\n## Frequently Asked Questions\n\n### What is the difference between an agent and a skill in Claude’s system?\n\nAn agent is the general-purpose system that can read files, write code, call tools, and reason through tasks. A skill is a packaged set of instructions, scripts, and reference material that tells that same agent how to handle one specific, recurring job, without rebuilding the agent itself each time.\n\n### What is progressive disclosure in Claude agent skills?\n\nProgressive disclosure means Claude only reads a skill’s short name and description at the start, and loads the skill’s full instructions, scripts, and reference files only once a user’s request matches that description. This keeps unrelated instructions out of the active context and reduces token use.\n\n### Can agent skills work with tools other than Claude?\n\nAgent skills are described as an open format, so the same skill folder can potentially be used with other compatible agent runtimes, not just Claude Code. Results can still vary between models, since different models interpret the same instructions differently.\n\n### How do you fix a skill that Claude keeps using incorrectly?\n\nUpdate the skill file directly rather than just correcting the single output. Add a clearer process instruction if the workflow was wrong, add a reference file if Claude is missing context like brand voice, or add an explicit rule if the same mistake keeps recurring, then rerun the task to confirm the fix holds.\n\n### Do agent skills eliminate the need for human review?\n\nNo. Skills are meant to catch obvious problems, formatting errors, unsupported claims, broken structure, before a human sees the output. Judgment calls involving strategy, taste, or business context still require human review; the goal is reducing how much routine error-catching falls on the person using the skill.", "url": "https://wpnews.pro/news/claude-agent-skills-how-anthropic-builds-reusable-ai-workflows", "canonical_source": "https://www.mindstudio.ai/blog/claude-agent-skills-anthropic-engineers/", "published_at": "2026-09-14 00:00:00+00:00", "updated_at": "2026-09-14 21:34:46.678724+00:00", "lang": "en", "topics": ["ai-agents", "ai-products", "ai-tools", "artificial-intelligence", "developer-tools"], "entities": ["Anthropic", "Claude", "Barry Zhang", "Mahesh Murag", "Claude Code"], "alternates": {"html": "https://wpnews.pro/news/claude-agent-skills-how-anthropic-builds-reusable-ai-workflows", "markdown": "https://wpnews.pro/news/claude-agent-skills-how-anthropic-builds-reusable-ai-workflows.md", "text": "https://wpnews.pro/news/claude-agent-skills-how-anthropic-builds-reusable-ai-workflows.txt", "jsonld": "https://wpnews.pro/news/claude-agent-skills-how-anthropic-builds-reusable-ai-workflows.jsonld"}}