The Essence of a Skill: Making Decision Processes Explicit

Skills as expert decision processes made explicit: deriving their design principles, boundaries, teaching uses, and business model from one signal-to-noise axiom.

Agent SkillsClaudeContext EngineeringFirst Principles

This essay began as a genuine confusion of mine and was sharpened through multiple rounds of debate with an AI. The AI restructured my framework twice, and I overturned one "first principle" it proposed. I've kept those traces of the contest in the text — because the process of a person and an AI correcting each other, forcing a fuzzy intuition into a clear definition, happens to demonstrate this essay's own claim: what matters is never the answer, but judgment made explicit.

Starting from an uncomfortable status quo

Open any agent system and skills are growing wild: scattered across platforms and frameworks, official unified management arriving late, local management left to everyone for themselves. This status quo has long given me a vague unease: does the skill as a form have any coherent underlying logic at all?

To answer that, we first have to answer a more fundamental question: what is a skill, exactly?

My original definition, and the two dead ends it created

My original definition was: "a knowledge base that packages the experience of domain experts in natural language."

It sounds right, but it immediately raises two unsolvable problems:

  1. A knowledge base is static. It cannot address the details of anyone's concrete situation.
  2. A knowledge base holds a finite set of cases. For anything more complex, if it contains no "meta-knowledge" (the ideas and methods for solving a problem from zero to one), the user ends up going back to ask the author in person.

These two problems bothered me for a long time. Only in debating them with an AI did I realize: their root is not in skills themselves, but in the definition "knowledge base."

The flip: from knowing-what to knowing-how

If a skill is a knowledge base, what it packages is the expert's declarative knowledge (knowing-what) — a collection of cases, a collection of answers. But declarative knowledge is precisely the least valuable thing in the AI era: retrieval tools do that job far better.

The real incremental value of a skill lies in packaging procedural knowledge (knowing-how):

skill = an expert's decision process, judgment criteria, and heuristics, made explicit.

"Made explicit" means taking the tacit, intuition-driven judgment inside an expert's head and expressing it in words, so it becomes checkable, reusable, and transferable. This understanding, it's worth noting, matches the official framing exactly — Anthropic's Agent Skills announcement opens by saying that real work requires procedural knowledge, and describes the purpose of skills as "capturing and sharing procedural knowledge."

One example: the same teaching scenario, two kinds of skill

Rather than compare abstractions, look at the artifacts. Both of the following claim to "package a math teacher's experience coaching students through word problems":

A case-library skill looks like this:

- Distance-rate problems: distance gap ÷ speed gap = time
- Work problems: set the total work to 1
- Concentration problems: the amount of solute stays constant
…(47 problem-type → formula entries in total)

A methodology skill looks like this:

Coaching process:
1. Ask the student to restate, in their own words, what the problem is asking.
   If they can't, ask: "Which quantities in the problem are known? How are they related?"
2. Have the student draw a diagram or build a table, translating words into structure.
   If they can't draw it, demonstrate the first row and let them fill in the second.
3. Only after the student lists at least two approaches do you discuss trade-offs —
   the criterion: which path has fewer unknowns and more direct relations?
4. After solving, follow up: "What does this problem have in common with the last one?"

The first fails the moment it meets a problem type it hasn't catalogued. The second generalizes, because it teaches a process for diagnosing and moving forward; the problem types are only illustrations. Their ceilings are entirely different: one is bounded by the number of cases, the other by the author's actual competence.

A necessary self-correction: this is not a binary opposition

In discussion with the AI, I pushed this contrast too far at one point. In reality the two forms are a spectrum with many hybrids in between: a brand-guideline skill or an API-manual skill is essentially declarative knowledge, and still perfectly valuable. The operable criterion is this:

The higher the variance of a domain (the more diverse its situations), the larger the methodology share should be; the closer a domain is to a standardized procedure (compliance, protocols, formats), the more the checklist itself is the value.

Looking back at the two dead ends with this criterion, their nature changes: "finite cases" dissolves outright — methodology naturally covers cases never seen before; "meta-knowledge" shouldn't be a patch, it should be the main body. "Cannot adapt to individual situations" partially dissolves — a good skill teaches the agent to diagnose the user's situation first, then choose a path, skipping the "standard answer" step entirely. The problems felt unsolvable because the "knowledge base" metaphor had locked them in place; switch the definition and they loosen on their own.

Why skills should be designed this way: protecting the signal-to-noise ratio of reasoning

Next comes the part of the debate I won — and the most important correction in this essay.

The AI's first proposed design axiom was "the context window is a scarce resource." I pushed back: models now have million-token contexts, so where is the scarcity? The binding constraint is obviously the mode of reasoning and the quality of the answer.

The conclusion of the debate: we were each half right, and the halves compose into the full picture —

Nominal capacity ≠ effective capacity. "Fits in the window" and "works well in the window" are two different things. The classic paper Lost in the Middle (Liu et al., TACL 2024) found that models perform best when relevant information sits at the beginning or end of the context, and that performance collapses significantly once it is buried in the middle — even for models built specifically for long context. Anthropic's own context engineering essay puts it more bluntly: like humans, models lose focus once the amount of information passes a certain point (they call it context rot: the more tokens in the context, the worse the model's ability to accurately attend to any of them).

And the mechanism of that decay is exactly what I had called "reasoning architecture." Under the attention mechanism, every token competes for weight; irrelevant content does not sit quietly in its seat — it actively dilutes signal and induces spurious associations. So what is scarce was never "space"; it is a signal-to-noise budget. This explains why, as windows grew from 100K to 1M, the "less is more" design principle did not become obsolete — it became more important, because bigger windows invite more stuffing, which makes the signal-to-noise problem worse.

So the axiom upgrades to:

The essence of skill design is protecting the model's signal-to-noise ratio during reasoning — the right information, only at the right moment.

Anthropic's official definition of context engineering is nearly a mirror image of that sentence: "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome."

From this axiom, the three-layer design of Anthropic's Agent Skills can be derived, not merely listed:

  1. Trigger conditions — the YAML frontmatter of SKILL.md (name + description) lives permanently in the system prompt. Official wording: the metadata "provides just enough information for Claude to know when each skill should be used." Corollary: write the description as "when to use me," not "what I am," because its only job is the trigger decision;
  2. Progressive disclosure — the body of SKILL.md loads only after the skill is judged relevant, and bundled reference files are read on demand. Anthropic says this makes the total packageable context "effectively unlimited";
  3. Just-in-time lookup — the body holds pointers; details live in separate files, read only when needed.

One easily missed point: a skill can bundle executable scripts. Anthropic's PDF skill ships a Python script that extracts form fields; Claude simply runs it, and neither the script nor the PDF enters the context. Code is both deterministic and token-cheap — the same signal-to-noise principle.

Boundaries: when not to use a skill

The most valuable part of a first-principles essay is often its negative judgments. Skills have clear boundaries, and three situations have better-suited alternatives:

  • Pure factual lookup ("what is the default value of this parameter") → use RAG; declarative knowledge is its home turf;
  • User preferences and habits → leave them to memory; not worth writing into a skill;
  • Real-time data and operations (checking inventory, sending requests) → use tool interfaces like MCP; a skill governs "how to do it," not "what the data is."

In one line: skills package judgment, RAG supplies facts, memory stores preferences, tools provide data. The four-way division deserves its own essay; I will leave it there.

The teaching scenario: package the "questioning process," not the "answering process"

My interest in skills began precisely because they looked like the perfect vessel for a teacher's knowledge. The imagined experiment: for the same problem, let students first learn with a bare AI, then with a version equipped with a skill that packages a teacher's experience, and compare the two.

The experiment is meaningful — it is essentially externalizing an expert's cognitive path, cognitive apprenticeship in a new medium. But there is a trap inside:

  • Package the teacher's answer-producing process → what students learn is still answers;
  • Package the teacher's questioning and diagnosing process → what students learn is the thinking itself.

A good teacher's value lies not in giving answers, but in knowing what question to ask at every point where a student gets stuck (the methodology skill above packages exactly this).

The design can go one level deeper: have students solve the same new problem under both versions, then run a three-way comparison against the teacher's own real solution path. The observation metric is clear too — whether the student can solve a new problem independently after the support is removed, not merely how the experience felt in the moment.

At the same time, I have to be honest about a risk (my conjecture, and an old problem in pedagogy): scaffolding dependency. The skill carries the student past every stuck point — but once the skill is removed, will they get stuck again? A good teaching skill must design the gradual removal of the scaffolding into itself — which is itself another piece of knowing-how.

The structure of a business: funnel, ceiling, and the water seller

Can skills make money? Yes — but you have to see clearly what can be charged for, and where the traffic comes from.

A skill is natural-language text, so it inherently cannot be copy-protected — a seemingly fatal flaw that looks different once dissected:

  • The copyable parts (static knowledge, methodology text) were never chargeable anyway — publish them openly in exchange for traffic and reputation;
  • The truly chargeable part (the author's live judgment when facing novel, vertical, high-difficulty problems) is precisely what cannot be written down, and cannot be copied.

The moat of the business model and the technical flaw of the medium complement each other perfectly — the most elegant part of the whole model.

But "publish openly for traffic" has an easily missed link: traffic never comes from inside the skill ecosystem. The prompt ecosystem had no "prompt store traffic" either; the traffic lives on content platforms. So the full funnel is:

Content platforms as the entry point (writing, sharing, public retrospectives) → the skill as a trust converter (a verifiable artifact: "don't believe me? take it and use it yourself") → a private domain as the landing zone (paid consulting or coaching for high-difficulty problems).

The open-source analogy makes it clearer: GitHub itself does not distribute, and Red Hat's traffic never came from software repositories — it came from conferences, blogs, and enterprise brand. A skill is the middle of the funnel, never the entry — anyone expecting "list it and traffic will come" will turn their skill packs into inventory.

The ceiling deserves honesty too: private-domain consulting does not scale. This is an expert's business (pricing power plus lifestyle), not a venture business. A scaling path exists, but at the back end: once reputation compounds, productize the judgment into courses, coaching cohorts, or tools.

One last flip: this ecosystem's biggest risk — users cannot verify a skill's quality before using it — is also its biggest opportunity. Until evaluation infrastructure exists, a creator's "verifiable artifacts plus public writing" is the provisional trust infrastructure; and whoever first builds a credible evaluation system for skills becomes the ecosystem's water seller (my conjecture — falsification welcome).

The ecosystem: closer to the prompt ecosystem, far from npm

Back to the fragmentation from the opening. The official side has not been idle: in December 2025, Anthropic formally released Agent Skills as a cross-platform open standard, and community registries (such as skills.sh) have appeared. But fragmentation has a deeper cause:

A skill's effectiveness is coupled to the host agent's loop. The same skill performs very differently in agents with different context-management strategies — a direct corollary of the signal-to-noise axiom: since effectiveness depends on how context is arranged at inference time, and every host arranges context differently, effectiveness cannot be guaranteed across platforms. A unified registry solves "distribution," not "efficacy."

So my judgment (conjecture — the reader decides): in the near term, the skill ecosystem will look more like the prompt ecosystem — loose, reputation-driven, environment-dependent — and will struggle to become the npm ecosystem, with strong standards, composability, and predictable behavior. The corollary for creators is direct: your personal reputation and standing in vertical communities matter more than which platform you list on.

Conclusion: one derivation diagram

The whole essay rests on two axioms; everything else is corollary:

Axiom A: skill = an expert's decision process and judgment criteria, made explicit
Axiom B: the model's attention budget is finite; signal-to-noise determines reasoning quality

A          → pain points dissolve: generalization is free, situational fit via "diagnose first"
A + B      → design principle: the right information, only at the right moment
             (triggers / progressive disclosure / just-in-time lookup / executable scripts)
A + B      → boundaries: skills for judgment, RAG for facts, memory for preferences, tools for data
A          → teaching: packaging "questioning & diagnosing" > packaging "answer-producing"
A          → business: publish the copyable for traffic, charge for the uncopyable judgment;
             traffic comes from content platforms; the skill is a trust converter
B          → ecosystem: effectiveness couples to host mechanics → near-prompt ecosystem, reputation > platform

One sentence: stop trying to pack answers into a skill — pack the expert's way of thinking when facing a problem. Answers get copied, expire, and break; judgment cannot be copied — which is both the design standard of a good skill and the only thing it can charge for.

Appendix: how this essay was human-AI co-authored (for the record)

  1. I wrote the original thinking notes (pain points, the teaching-experiment idea, business-model intuitions, and three unfinished lines of design principles);
  2. The AI proposed a framework correction: flipping the definition from "knowledge base" to "explicit decision process," and pointing out that my first two pain points were artifacts of that locked definition;
  3. I challenged its "context window scarcity" axiom (scarcity cannot hold in the million-token era); the AI accepted the challenge, checked the literature, and the axiom upgraded to "signal-to-noise scarcity" — this upgrade came from my challenge, as noted in the text;
  4. Every official statement and paper citation was checked against the primary source before publication (see below).

Sources (all verified)

(Verified on 2026-08-28)