AI Skills Are the New Source Code, Whether We Like It Or Not

Kenny Liao calls skills "the new basic unit of knowledge work," and if he's right, we're watching a larger shift than most people realize. Not because skills are particularly clever—they're folders with markdown files and some Python scripts—but because they represent knowledge workers finally accepting what programmers figured out decades ago: standardization beats improvisation.

Liao runs a detailed walkthrough of Claude's skill system in a recent video, covering everything from basic structure to evaluation frameworks. The technical specifics matter, but the underlying pattern matters more. We've seen this movie before.

What Skills Actually Are

A skill is a folder. Inside that folder sits a file called skill.md containing instructions for how Claude should handle a particular task. That's the minimum. Most skills include additional folders—references for documentation, scripts for executable code, assets for templates or images.

The critical piece is what Liao calls the "front matter"—metadata that sits at the top of the skill.md file. At minimum, you need a name and description. The description determines when Claude activates the skill, making it the most important component. "The description is by far the most critical component of the front matter," Liao explains. "It's the only way that Claude understands what the skill is and when to use it."

Beyond that, you can specify which AI model to use for the skill, set computational effort levels, and configure "hooks"—automated checks that trigger when certain conditions are met. A writing skill might check word count automatically. A security-focused skill might scan bash commands before execution.

The architecture isn't revolutionary. It's sensible, which might be more important.

Progressive Disclosure and Context Economics

Liao spends considerable time on "progressive disclosure," which sounds fancier than it is. The principle: only load information into Claude's context window when it's actually needed.

Here's how it works: Claude always sees skill metadata—names and descriptions of every available skill. That's loaded by default. When Claude decides a skill is relevant, it reads the full instructions. Within those instructions, the skill might reference additional documentation or code, which Claude reads only if necessary.

"If Claude doesn't need it every time it needs to run the skill, then you should probably move it out of the skill.md," Liao notes. His YouTube Data skill, for example, keeps API documentation in a separate reference folder. Claude only reads it when debugging errors, not during normal operation.

This matters because context windows, while larger than they used to be, remain finite. More importantly, filling them with irrelevant information degrades AI performance. Research confirms what common sense suggests: more noise means worse results.

The parallel to software development is obvious. Good programmers don't load entire libraries into memory when they need one function. They import what's necessary. Skills apply the same logic to AI interactions. It's not novel. It's necessary.

The Skill Triggering Problem

The most common failure mode, according to Liao, is Claude not using a skill when you want it to. The solution is specificity. Don't just describe what the skill does—explicitly state when Claude should trigger it.

A weak description: "Generates data dashboards." A better description: "Generates data dashboards. Use whenever the user mentions dashboards, data visualization, or internal metrics."

The second version eliminates ambiguity. When users mention those specific terms, Claude knows which skill to activate. Without explicit triggers, Claude guesses, and guesses wrong.

Liao also emphasizes single-purpose skills. "Create skills that do one specific thing and ideally have no overlap with anything else," he advises. Multiple tools with similar functions compete for Claude's attention, creating confusion.

Anyone who's debugged namespace collisions in code will recognize this problem. Same principle, different domain.

Evaluation: Closing the Loop

Skills need testing, and Liao walks through Anthropic's evaluation framework. The process is straightforward: generate test prompts, run them through Claude with and without the skill active, compare outputs, iterate on the skill based on results.

Anthropic provides a "skill creator" skill specifically for building and evaluating other skills. It's recursive in a way that feels either clever or concerning, depending on your tolerance for AI systems improving AI systems.

Evaluations split into quantitative measures—word count, number of failed function calls, hashtag usage—and qualitative assessments requiring human judgment. For the quantitative stuff, Claude handles testing automatically. For qualitative evaluation, humans review outputs and provide feedback that refines the skill.

Liao demonstrates with a hook-writing skill for YouTube videos. Claude generates test prompts, produces hooks with and without the skill active, displays them for human review. The human grades the outputs. Claude incorporates that feedback. The loop closes.

In one example, the skill-enhanced version achieved a 100% pass rate against evaluation criteria, while the non-skilled version hit 63%. That's a meaningful difference, assuming the criteria were well-designed.

What This Actually Means

Liao describes skills as "the mechanism for transferring your knowledge and expertise directly to AI." That's accurate but incomplete. Skills are also the mechanism for standardizing how knowledge gets transferred.

This matters because standardization precedes industrialization. When processes become repeatable and portable, they scale. When they scale, they transform markets.

Skills are now an open standard. What works in Claude works in Gemini, in Codex, across platforms. That portability accelerates adoption. It also means knowledge workers face the same choice software developers faced with open source: participate in standardization or get standardized out of relevance.

The engineers who thrived weren't necessarily the best coders. They were the ones who understood that contributing to shared frameworks beat maintaining proprietary approaches. The knowledge workers who thrive with AI probably won't be the ones with the most expertise—they'll be the ones who package that expertise most effectively.

Liao frames this as empowerment: "The best engineers don't write code anymore, right? They spend most of their time in planning mode drafting specs that the agent then implements." That's optimistic. The pessimistic reading is that expertise becomes commoditized the moment it's codified into a transferable skill.

Both interpretations are probably true. History suggests new tools simultaneously empower their users and devalue their previous advantages. The printing press made knowledge accessible and destroyed the scribal class. Skills will do something similar.

The question isn't whether skills matter. They do, because Anthropic and others have decided they do, and enough infrastructure is already built around them to make that decision sticky. The question is what happens when packaging expertise matters more than having expertise. We're about to find out.

—Bob Reynolds