Skill Evaluation

SkillAI & models

Evaluate any agent skill against a merged framework — Anthropic's Claude Code best practices plus Matt Pocock's writing-great-skills methodology — across 4 axes (Trigger, Structure, Steering, Pruning). Produces an evidence-cited scorecard (0–100), a weighted overall score, and diagnosed failure modes with prioritized fixes. Use when the user asks to evaluate, rate, or audit a skill ("evaluate this skill", "skill scorecard", "review SKILL.md"), or to compare two skills.

Available today. Use it from your connected AI after setup.

Connect ahel once, and every AI you use reads what you have installed.

Then ask your AI: use the Skill Evaluation skill

What this skill tells your AI

The instructions your AI receives, as published by fabricioctelles/skills in skills/skill-evaluation/SKILL.md and read by ahel’s review.

If you need the vocabulary and tests behind Axes 1, 3, and 4 (leading words, completion criteria, context pointers, the deletion test, failure-mode definitions), read references/mechanics.md before scoring those axes.

Source

Parameters

ParameterDescriptionDefault
targetPath to skill directory or SKILL.md to evaluateAsk user
outputPath to write the scorecard<target>/EVALUATION.md
compareOptional second skill to compare side-by-sideNone

Also runs unattended: in CI, point target at skills changed in a PR and gate with scripts/score.py --fail-below 60 ... — non-zero exit below the threshold fails the check.

Criteria

18 criteria: 14 core, scored on every skill, plus 4 conditional criteria scored only when the skill's category makes them apply — otherwise mark N/A and exclude the criterion from both the numerator and denominator of the weighted average. Every score is 0–100 with evidence citing file, section, or line.

Axis 1 — Trigger (invocation)

#CriterionWeightKey question
1Invocation design2xIs model-invoked vs. user-invoked deliberate and fitting? Model-invoked pays context load (the description loads every turn); user-invoked pays cognitive load (the human is the index). A skill that only ever fires by hand should be user-invoked.
2Description quality2xModel-invoked: leading word up front, one trigger per branch (synonyms renaming the same branch are duplication), no identity that's redundant with the body. User-invoked (disable-model-invocation: true): a human-facing one-liner, no trigger list. Score against the mode the skill actually uses — never penalize a user-invoked skill for lacking trigger phrases.

Axis 2 — Structure

#CriterionWeightKey question
3Steps vs. reference clarity1xDoes the skill distinguish ordered steps from on-demand reference? All-reference and all-steps skills are both valid — score clarity, not the mix. Is related material co-located (definition, rules, caveats under one heading)?
4Branch-aware disclosure & pointers2xIs material every branch needs inline, and material only some branches need behind a context pointer? Does each pointer's wording say when to follow it ("if you need X, read Y")? A weakly worded pointer to must-have material is a variance bug.
5Conciseness (no sprawl)2xIs SKILL.md lean — under 500 lines as a ceiling, smaller is better — with every line earning its context cost?
6Coherent scope1xDoes the skill do one thing and compose with others, rather than covering too much?

Axis 3 — Steering

#CriterionWeightKey question
7Leading words2xDoes the skill use compact, high-prior terms ("vertical slice", "tight", "red") to anchor behavior, repeated consistently? Could any verbose passage collapse into one?
8Completion criteria & legwork2xSkills with steps: does each step end on a checkable, exhaustive completion criterion? A vague one invites premature completion. Skills that are pure reference: is there an exhaustiveness bar over the reference itself ("every rule applied")? If neither applies, mark N/A.
9Gotchas section2xIs there explicit capture of failure points, edge cases, footguns?
10Grounded in expertise2xDoes content come from observed failures and real project facts, or generic "best practices"?
11Avoids railroading1xDoes the skill leave room to adapt — procedures over declarations, defaults over menus — without over-prescribing?

Axis 4 — Pruning

#CriterionWeightKey question
12No-ops (deletion test)2xRunning the deletion test sentence by sentence: if removing a sentence leaves behavior unchanged, it's a no-op — including restatements of what the model already does by default. Cite line numbers for candidates.
13Single source of truth1xDoes each meaning live in exactly one place? Duplication between SKILL.md and references/ counts too.
14Relevance & sediment1xAre there stale lines, accumulated layers, or material that no longer influences what the skill does?

Conditional criteria

Score only when the skill's category (from references/categories.md) makes the criterion apply; otherwise mark N/A and drop it from the weighted average entirely.

#CriterionWeightApplies to category
15Setup flow1xlibrary-and-api-reference, data-fetching-and-analysis, ci-cd-and-deployment, infrastructure-operations
16Memory mechanism1xbusiness-process-automation, data-fetching-and-analysis, runbooks
17Scripts & libraries1xproduct-verification, code-scaffolding-and-templates, code-quality-and-review, data-fetching-and-analysis, infrastructure-operations
18On-demand hooks1xcode-quality-and-review, ci-cd-and-deployment

Override this table with judgment, in either direction: score a criterion for a skill outside these categories when it would clearly benefit (e.g., a non-product-verification skill that obviously needs a helper script), and mark it N/A even within an applicable category when the pattern doesn't fit the skill's shape (e.g., a pure-reference vocabulary skill filed under code-quality-and-review has nothing for a hook to enforce). Explain the override in the scorecard either way.

Overall score

overall = sum(score × weight) / sum(weight)

N/A criteria are excluded from both sums — never scored as 0, never counted as weight.

Scoring Guide

ScoreMeaning
0Not present at all
1–25Minimal/token effort, barely addresses the criterion
26–50Partially addressed but with significant gaps
51–75Solid implementation with room for improvement
76–90Strong implementation, minor gaps only
91–100Exemplary — would use as a reference for others

Grade Scale

GradeRangeMeaning
A80–100Production-quality, reference skill
B60–79Good skill, minor improvements needed
C40–59Functional but significant gaps
D20–39Needs substantial rework
F0–19Skeleton only, not production-ready

Workflow

  1. Read the target skill — SKILL.md, its frontmatter (check for disable-model-invocation), and every file in the skill directory.

  2. Read references/mechanics.md — the vocabulary and tests Axes 1, 3, and 4 depend on, including what makes a context pointer's wording effective.

  3. Classify — use references/categories.md and its decision tree to assign a category. The category determines which conditional criteria apply.

  4. Score all applicable criteriacite-or-cut: a criterion is only scored once its justification cites specific evidence (file, section, or line); no citation, no score. Mark N/A wherever the conditional table, or your own judgment, says a criterion doesn't apply. Done when every applicable criterion carries a score and a citation, and every N/A a reason.

  5. Trigger eval — empirical test of whether the skill's description actually causes invocation. See the Trigger Eval section below for the full mechanic. Skip this step for user-invoked skills (disable-model-invocation: true) — they have no description to test.

  6. Diagnose failure modes — done when every mode in the table below has been checked against the skill and either cited (file:line) or dismissed.

  7. Assess bonus patterns — the 4 carried over from v1, plus a fifth:

    BonusApplies whenWhat to look for
    Validation loopsSkill produces output or modifies stateInstructs the agent to self-check before finalizing
    Output templatesSkill generates structured outputIncludes a concrete template/example of expected format
    Procedures over declarationsSkill teaches a methodTeaches how to approach problems, not what to produce for one case
    Defaults over menusSkill offers tool/approach choicesPicks a clear default, mentions alternatives briefly
    Trace-checkable steeringSkill uses leading wordsThe leading words are distinctive enough that a user could grep the agent's reasoning traces to confirm the skill actually fired

    Report each as Present / Absent / N/A.

  8. Compute the weighted score — run scripts/score.py with one criterion:score:weight triple per criterion (score NA to exclude); it prints both sums, the overall, and the grade. Don't do this arithmetic by hand.

  9. Write the scorecard to the output path — read references/output-template.md first (it also holds the comparison-mode template used when compare is set) and emit exactly that structure.

Trigger Eval

Empirical test of whether the skill's description causes a model to invoke it when it should — and ignore it when it shouldn't. This is not a pass/fail gate; it produces observational data that feeds the scorecard and informs the failure-mode diagnosis.

When to run

  • Model-invoked skills only. User-invoked skills (disable-model-invocation: true) have no description to test — skip and mark the section N/A.

Prompt generation

Generate 10 prompts from the skill's description, scope, and gotchas:

  • 5 should-trigger — realistic user requests that fall squarely within the skill's stated scope. Vary phrasing: some use the skill's vocabulary, others describe the same need in naive/indirect language.
  • 5 should-not-trigger — requests that are adjacent but clearly outside scope (e.g., a sibling skill's territory, a task the description explicitly excludes, or a generic request a model handles without any skill).

Each prompt should read like something a real user would type — no meta-language about skills, no hints.

Sub-agent execution

Run each prompt in an independent sub-agent session with the target skill available. The sub-agent receives a single additional instruction appended to its system context:

At the end of your response, output exactly one line in this format:
SKILLS_USED: <comma-separated list of skill names you loaded during this task, or "none">

This instruction is generic — it does not name the skill under test or hint at what should be triggered. The sub-agent operates normally; it either loads the skill or doesn't based on the prompt alone.

Detection

Parse the SKILLS_USED: line from each sub-agent's response. Record per prompt:

FieldValue
PromptThe test prompt text
Expectedshould-trigger / should-not-trigger
Triggeredyes / no (was the target skill name in the list?)
Other skillsAny other skills that fired

What to report

Report raw counts — no pass/fail judgment:

  • Should-trigger hit rate — X/5 triggered
  • Should-not-trigger leak rate — X/5 triggered (lower is better)
  • Other skills observed — which siblings fired on the same prompts

These numbers feed criterion #1 (invocation design) and #2 (description quality) with empirical evidence, and may reveal failure modes like over-triggering or description weakness.

Practical notes

  • If the evaluation environment cannot spawn sub-agents (e.g., CI without agent access), skip the trigger eval and note "trigger eval: skipped (no agent access)" in the scorecard.
  • A single trial per prompt is acceptable given the observational (non-gating) nature. Run multiple trials only if results are ambiguous.
  • Keep prompts in the scorecard output so the skill author can reuse them as a regression set.

Failure-mode diagnosis

Name the failure mode, cite evidence, prescribe the defense. Each mode's defense is defined once in references/mechanics.md §5 — prescribe from there. This replaces a generic "top improvements" list.

ModeEvidence to look for
Premature completionVague completion criteria with future steps still visible
Weak steeringInstruction present but the agent doesn't reliably follow it
DuplicationSame meaning in 2+ places, including SKILL.md vs. references/
SedimentStale layers, outdated references, dead instructions
SprawlLong even with no duplication or sediment
No-opsLines that don't change behavior versus the model's default
Buried stepsInline reference so heavy it soaks the steps

After the table, write a Prioritized Actions section: 3–5 highest-impact actions derived directly from the detected failure modes, each citing its evidence.

Note: context overload — too many model-invoked skills competing for attention in one environment — is a portfolio-level problem, out of scope for evaluating a single skill. Record the description's context-load cost when it's notable; don't score the portfolio.

Gotchas

  • Tiny skills (under ~50 lines) flood the scorecard with N/A — score what's there; a small, sharp skill can reach grade A on few criteria.
  • Self-evaluation bias: when the skill under review is one you (or this session) wrote, apply the deletion test with extra skepticism — you will want your own lines to matter.
  • Fresh rewrites still carry duplication: sediment needs time to settle, but duplication can ship on day one. Run the pruning axis even on brand-new skills.

Quality Checklist

Final gate before delivering — each item names the step whose completion it re-checks, nothing new:

  • cite-or-cut held everywhere (step 4)
  • every N/A justified (step 4)
  • trigger eval run or skipped with reason (step 5)
  • every failure mode cited or dismissed (step 6)
  • 5 bonus patterns assessed (step 7)
  • score computed by scripts/score.py, not by hand (step 8)

Signals

GitHub stars
77
Forks
7
Last commit
Sep 2026
Advanced
Catalog kind
skill
Gateway key
skill-evaluation
Source
github.com/fabricioctelles/skills