agentleFS
michalstrnadelmichalstrnadel/source-to-skill/skills/skill-eval/SKILL.md

skill-eval

Skill8 starsChanged 39 days agoMITView on GitHub

Measure how well a generated knowledge skill answers questions about its source - grounded questions drafted from the original source, answered using only the skill, graded expectation by expectation, with a score, the facts the skill is missing, and an optional fix. Writes evals/evals.json in the skill-creator format. Use when the user runs /skill-eval, or asks "is this skill any good", "test / evaluate / benchmark my skill", "what did the skill miss", or wants to check a skill made by source-to-skill before relying on it.

21 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use mutation-test, postmortem and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • squall-chuaSkill

    mutation-test

    Break the source on purpose, find the mutants the tests fail to catch, and report each survivor with the behaviour nobody is checking.

    Also in 3 projects that use this

  • Hongyu-yuSkill

    postmortem

    Use when analyzing failures, outages, incidents, or negative outcomes, conducting blameless postmortems, documenting root causes with 5 Whys or fishbone diagrams, identifying corrective actions with owners and timelines, learning from near-misses, establishing prevention strategies, or when user mentions postmortem, incident review, failure analysis, RCA, lessons learned, or after-action review.

    Also in 3 projects that use this

  • nicolasestremSkill

    brainstorm

    Structured idea generation and solution exploration with systematic analysis.

    Also in 3 projects that use this

  • MicrosoftSkill

    handoff

    Compact the current conversation into a handoff document for another agent to pick up.

    Also in 5 projects that use this

  • NVIDIASkill

    research

    Before designing a feature, research how comparable libraries solve the problem, check best practices, known pitfalls, and upstream changes. Use when starting a new feature, investigating an unfamiliar area, or the user asks to research something.

    Also in 3 projects that use this

  • SentrySkill

    review

    Fixture review skill.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

4 rules. 0 are common, 2 are distinctive, and 2 are very specific to this project.

  • 0

    Common

    Most of the 19 edited versions we read keep these.

  • 2

    Distinctive

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Check a skill against the source it was made from.

    line 8
  2. Very specific:

    If <skill-dir>/evals/evals.json exists (source-to-skill writes one while the source is still in context), use it.

    line 18
  3. Very specific:

    Read <skill-dir>/source.json (topic skills: sources/*.source.json).

    line 21
  4. Distinctive:

    Write it in the skill-creator format so the same file works there:

    line 35

“Common” is measured: kept by at least 6 in 10 of the 19 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

skill-eval

Check a skill against the source it was made from. The question is not "does the skill read well" but "can an agent holding only this skill answer what the source answers, and cite it correctly".

Usage: /skill-eval <skill-dir> (a path, or a skill name found under ~/.claude/skills/, ~/.agents/skills/, ~/.copilot/skills/ or the project's .claude/skills/, .agents/skills/, .github/skills/).

Step 1 — Get the questions

If <skill-dir>/evals/evals.json exists (source-to-skill writes one while the source is still in context), use it. Otherwise draft one:

  1. Read <skill-dir>/source.json (topic skills: sources/*.source.json). Missing → say the skill was not made by source-to-skill and ask for the original source.
  2. Re-extract the source with the source-to-skill extractor into a fresh work dir (python3 scripts/extract.py "<source>" [options from the manifest] --work-dir <tmp>/skill_eval, run from the source-to-skill skill folder). Tell the user the est_tokens and ask before reading it.
  3. Draft 8 questions from full_text.txt, never from the skill, spread across the source's segments: 3 concrete facts or numbers, 2 decision rules or "when should I", 2 that need two segments combined, and for video or audio 1 "where in the source is X" that needs a timestamp. Each gets 1 to 3 expectations: short statements a grader can check against an answer, each naming its segment.

Write it in the skill-creator format so the same file works there:

{
  "skill_name": "<slug>",
  "evals": [
    {"id": 1, "prompt": "What learning-rate schedule did the paper use?",
     "expected_output": "Linear warmup for 4000 steps, then inverse square root decay",
     "files": [],
     "expectations": ["States warmup_steps = 4000 (segment 5.3 Optimizer)",
                      "Says the rate then decays proportionally to step^-0.5"]}
  ]
}

Step 2 — Answer with only the skill

The answers must come from someone who has not read the source. If your host can run subagents, give one subagent the skill directory path and the eight prompts, and tell it to answer from those files only, citing file names and deep links. Without subagents, answer them yourself, reading only the skill's files, and say in the report that grading was not blind.

Step 3 — Grade

For each expectation: pass or fail, with one line of evidence quoted from the answer. Also fail an answer whose citation points at the wrong file or whose timestamp is more than 60 seconds off the moment the source covers it. Score = passed expectations / all expectations.

Save <skill-dir>/evals/last-run.json: {"date": "...", "score": 0.83, "results": [{"id": 1, "passed": [true, false], "evidence": ["...", "..."]}]}.

Step 4 — Report and fix

Report the score, then each failure as one line: what the source says, which skill file should have carried it. Separate two causes: the fact is missing from the skill, or it is there but the index in SKILL.md did not lead to it. Offer to fix both — add the missing facts to the right support file, sharpen the index line or the description — then re-run only the failed questions. Change nothing without the user's yes, and run python3 tools/validate_skill.py <skill-dir> (from the source-to-skill folder) after any edit.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.