Author, test, and run skills

Skills are self-contained abilities: a manifest, a Rhai script (fn run(input)), and a bundled test (fn test()). This guide covers the everyday operations.

Ask the assistant to build one

In the Skills tab, type a request in the authoring box and click Author. The model writes the code and test; the engine proves it. See Author your first skill for the full walkthrough.

Write one by hand

Click + new and fill in the two editors:

skill.rhai

fn run(input) {
  input.to_upper()
}

test.rhai

fn test() {
  run("hi") == "HI"
}

Click Save & test. The bundled test runs immediately; a passing skill is usable, a failing one is flagged.

Re-test after changes

Select a skill and click Re-run test. Status is re-evaluated and persisted — useful after editing, or to confirm a flagged skill now works.

Run a skill

Select a passing skill, enter an input, and press Run. Flagged skills refuse to run until their test passes.

Roll a skill back

Updating a skill bumps its version and archives the previous source. From the event log you can undo a skill change: the previous version is restored as a new version (a revert, never a rewrite), preserving history. A first version with nothing to revert to is deleted.

What’s guaranteed

• Skills run in a sandbox — no filesystem, no network, only language built-ins — under a hard operation cap, so a runaway loop terminates.
• A skill is never used unless its test passes.

Contract details: Skill manifest reference.

Retirement: a passing test isn’t proof a skill helps

Every skill ships a test, and a skill whose test fails is refused. That catches code which doesn’t run. It cannot catch code that runs and does the wrong thing.

So the library also watches outcomes. Every run is recorded — successes and failures, because a failure is exactly the evidence that matters. A skill can be retired for one of two reasons, and the reason is always stated:

• It fails more than it works. Below a 50% success rate.
• It has faded. It worked, but nothing has renewed that in long enough that whatever it was for has probably passed.

There’s also a cap on how many skills stay active, because an unbounded library dilutes retrieval until the useful entries stop being found.

Three things protect a skill

None of these is caution for its own sake:

1. New skills are never retired. No chance to earn a record yet.
2. Fewer than ten runs is not a record. This one matters most: the research this came from found that retiring without an evidence minimum scored worse than never retiring at all — below the no-skill baseline (arXiv:2605.19576).
3. Capacity pressure only removes skills that have a record. Otherwise library size, rather than evidence, would decide what survives.

Retired means deactivated, not deleted

A skill is your code. The library forming an opinion about it does not entitle it to throw the code away.

A retired skill stays in the list, marked, with its reason and its record. Running it fails loudly and tells you how to get it back — so anything that referenced it breaks visibly rather than silently doing nothing. One click restores it.

Saving a new version also un-retires it, with a clean record. Fixing a skill is you overruling the retirement, and the fix shouldn’t inherit the failures that retired the old version.

Auto mode runs this pass within its caps. You can see what it would do before it does anything: the skills view shows the plan, with a reason per skill.