Why I started thinking seriously about skill evaluation

Last year, in my organization, we had some pretty heated discussions around prompt-based skills, agents and whether these could become an organization-wide offering for clients.

I was actually quite positive about the idea. If we can capture our engineering knowledge in reusable skills and agents, we can potentially make teams much more productive and package that capability for multiple clients.

But I had two concerns:

quality and security.

My question was quite simple:

How do we know that these skills actually make the agent better?

A Markdown file can contain excellent instructions. But writing a good instruction and proving that the instruction improves an AI system are two completely different things.

That became much more real for me this year.

I started working with a regulatory client where a prompting layer was already established. There was quite a lot of value in it. Developers were using skills, AGENTS.md files and other prompting mechanisms to guide their workflows.

But when I started asking questions around quality and security, things became uncomfortable.

I faced a few escalations around the behaviour of the system.

And then I found something particularly interesting.

They had deployed a Cursor instance on GCP, and the developer experience was already dependent on these skills and agent instruction files.

But there was no systematic evaluation or observability around them.

That means we had effectively put a new layer of software into the development process without really measuring the behaviour of that layer.

And that got me thinking:

If a skill changes how an AI agent behaves, shouldn't we be able to measure that change?

Let's turn that into a mathematical problem

Suppose we have an agent:

y=fθ​(x)

where:

• $x$ is the task given to the agent
• $\theta$ represents the model and agent configuration
• $y$ is the resulting behaviour/output

Now we introduce a skill $s$.

Our system becomes:

ys​=fθ​(x,s)

The important question is not:

"Is $s$ a well-written skill?"

The question is:

Does fθ​(x,s) perform better than fθ​(x)?​

That's a very different question.

We need a definition of "better"

Let's say we have an evaluation dataset:

D={(x1​,y1∗​),…,(xn​,yn∗​)}

where:

• xi​ = an actual task
• yi∗​ = what we consider a correct/acceptable outcome

We define an evaluation metric:

M(fθ​,D)

For example, this could measure:

• task correctness
• code quality
• security
• tool selection
• faithfulness
• latency
• token consumption

Then we can compare:

Mbase​=M(fθ​,D)

against:

Mskill​=M(fθ​(⋅,s),D)

And now we have something measurable:

SkillLift=Mskill​−Mbase​​

This is the basic mathematical intuition behind the whole problem.

Let's use a simple example

Suppose I have an agent that helps developers build RAG applications.

I evaluate it on 100 tasks.

Without my RAG skill:

Mbase​=62

Then I add rag-engineering.md.

Same model.

Same tasks.

Same tools.

Same evaluation criteria.

Now:

Mskill​=84

So:

$$SkillLift=84-62=22$$

Now I have evidence that my skill is useful for this evaluation set.

That's much stronger than saying:

"The agent seems better after I added the skill."

But here's where it gets interesting

What if correctness improves, but token usage doubles?

Suppose:

$$Correctness:62\to 84$$

but:

$$Tokens:2,000\to 5,000$$

Should we deploy it?

Maybe.

Maybe not.

We need to think about the AI system as a multi-objective optimization problem.

For example:

J=wq​Q−wc​C−wl​L−wr​R

where:

• $Q$ = quality
• $C$ = cost
• $L$ = latency
• $R$ = risk
• wq​,wc​,wl​,wr​ = how important each factor is

Now the question changes from:

"Did the skill improve the score?"

to:

"Did the skill improve the overall utility of the system?"

This matters enormously in enterprise environments.

And security makes the equation even more interesting

Imagine:

If we looked only at quality:

$$72\to 91$$

we'd probably celebrate.

But in a regulated environment, the security regression might make the skill completely unacceptable.

So we could think of deployment as a constrained optimization problem:

$$\max Q$$

subject to:

SecurityRisk≤Rmax​ Cost≤Cmax​ Latency≤Lmax​

This is the kind of mathematical framing I think is useful for engineers.

We're not trying to maximize an LLM score. We're trying to optimize a production system under constraints.

There is another problem: the agent isn't deterministic

This is where evaluating AI becomes different from testing normal software.

Suppose I run the same task twice:

Run 1 → Correct
Run 2 → Incorrect
Run 3 → Correct
Run 4 → Correct
Run 5 → Incorrect

So instead of one score, we have a distribution:

S1​,S2​,…,Sn​

The average performance is:

Sˉ=n1​i=1∑n​Si​

And the variance tells us how unstable the behaviour is:

σ2=n−11​i=1∑n​(Si​−Sˉ)2

This is important.

Suppose two skills both have:

Sˉ=85

but:

Skill A → very consistent
Skill B → sometimes excellent, sometimes terrible

I would much rather deploy Skill A, especially for a regulatory client.

So average quality isn't enough.

We also care about reliability and variance.

Now we can see why controlled evaluation matters

If I want to know whether a skill caused an improvement, I need to keep the other variables as constant as possible.

Think of this like a scientific experiment.

                    Same task
                       │
          ┌────────────┴────────────┐
          ↓                         ↓
    Without skill              With skill
          │                         │
       Agent A                    Agent B
          │                         │
          └────────────┬────────────┘
                       ↓
                   Evaluate
                       ↓
                 Compare ΔM

Ideally:

ModelA​=ModelB​ ToolsA​=ToolsB​ EnvironmentA​=EnvironmentB​ DatasetA​=DatasetB​

and the only meaningful difference is:

SkillA​=SkillB​

Then:

ΔM=Mskill​−Mbase​

becomes much more informative.

This is essentially A/B testing for agent behaviour.

And this is why I found NVIDIA's SkillEvaluator interesting

NVIDIA's recent SkillEvaluator work formalizes exactly this kind of thinking.

It evaluates skills at multiple levels:

1. Safety and structure
2. Whether the skill contains useful/non-duplicated information
3. Whether the skill actually improves agent performance

For the behavioural evaluation, the same tasks are run with and without the skill in isolated environments. NVIDIA reports an average 41-point improvement in correctness across its benchmark—from 46 to 87—although the exact benchmark setup and run-to-run variability should always be considered when interpreting such numbers.

And this last point is important.

Evaluation itself needs engineering discipline.

A benchmark number without knowing:

• what dataset was used,
• how many trials were run,
• what model was used,
• how the grader works,
• what environment was used,
• and what metrics were measured

doesn't tell us very much.

This gives us a much better development loop

Instead of:

Create skill
     ↓
Looks good
     ↓
Deploy

I'd want:

Create skill
     ↓
Define expected behaviour
     ↓
Create evaluation dataset
     ↓
Run baseline
     ↓
Run with skill
     ↓
Measure quality + cost + latency + security
     ↓
Analyse failures
     ↓
Improve skill
     ↓
Regression test
     ↓
Deploy
     ↓
Observe production

Now the skill becomes a proper engineering artifact.

And we can do the same thing for:

• AGENTS.md
• system prompts
• tools
• RAG configurations
• memory
• model selection
• agent workflows

For any component $c$:

$$\Delta (c)=Performance(c)-Performance(base)$$

That's a very powerful way to think about AI engineering.

What I want you to remember

My concern last year wasn't:

"Skills and agents don't work."

It was:

"If we're going to make skills and agents an organization-wide or client-facing capability, we need to know how well they work."

A skills.md file is easy to create.

A skill that has been evaluated, observed, security-tested, versioned and shown to improve the system under defined conditions is something very different.

That's the transition I think we need to make in AI engineering:

Prompt Engineering→Evaluation Engineering​

We're getting very good at telling AI systems what to do.

The next step is becoming equally good at proving whether they actually did it well.