Cortex · measured skills and rules for Claude Code

Skills that earn their place.

Cortex treats every skill or rule as a hypothesis and tests it. It turns your real sessions into pass/fail tasks, proposes one skill or rule from the corrections you keep making, runs Claude with and without it in throwaway clones of your repository, and keeps it only if it wins something and breaks nothing.

Collect what keeps going wrong  →  measure one fix against the real jobs  →  remove whatever stopped pulling its weight.

scroll to explore↓

Six words this page uses

Everything below is built from these.

task
A bug you fixed, frozen so it can be replayed: the broken commit, your prompt, and a check.sh that answers pass or fail.
lesson
One line in lessons.md for each time you had to correct Claude.
rollout
One headless claude -p run of a task, in a throwaway clone of your repository. Rollouts are the only thing that costs money.
sweep
The batch of rollouts that tests one change: the tasks, several runs each, in both arms.
base / cand
The two arms. base is your skills and rules as they are. cand is the same set with the one change under test.
tier
When an item enters Claude's context: on every turn, or only when Claude touches matching files.

Three commands, three jobs

Each runs on its own rhythm. Together they form one closed loop.

/harvest Save what just happened end of every session · 0 rollouts

You just fixed a bug. The environment is still warm and you remember exactly what broke. Harvest freezes that moment into a reusable test before you close the session, because rebuilding it later is far more work. It takes about a minute, and it never writes a skill.

InputYour session Two questions. Did something go from broken to working? Did you correct Claude? Once is enough.
if yes
What it capturesOne task A small folder that lets the bug be replayed forever:
  • task.yaml the broken commit, as base_sha
  • prompt.txt what you asked, word for word
  • check.sh exits 0 only when solved, your corrections included
  • fix.patch proof it can be solved
  • notes.md what was wrong, and which area it is in
saved to
OutputThe ruler grows .evolve/tasks/ gains a test, and cortex preflight proves it: the check must fail before the fix and pass after. Each correction becomes one line in lessons.md. No skill is written yet.
the filter Most sessions produce nothing, and that is correct. No bug fixed and no correction made means nothing to harvest. A task that cannot tell broken from fixed is quarantined with its reason, because a bad test silently corrupts every later score.
▼ Once you have at least 3 valid tasks and a lesson that has come back three times, there is something to measure.
/evolve Propose one change, then measure it weekly · 0, 8 or 38 rollouts with 5 tasks

Evolve looks for one problem that keeps recurring. If nothing recurs it stops, and that costs nothing. Otherwise it writes one skill or rule for it, in the tier the evidence points to, then runs your tasks both ways, without it and with it, several times each, in throwaway clones of your repository (several at once, sized to your free RAM and CPUs). A script reads the results and decides. No opinion is involved.

InputTasks + lessons Counts what recurs, picks one theme and writes a candidate in .evolve/candidate/. It is not live yet. A free check confirms that a task can load it.
scope
Advisory · not a gatecortex scope How many tasks will this candidate be injected into? A rule fires in every task it reaches, and each unrelated one is a chance to break something. It warns, you decide, and the sweep runs either way. Dashed = advice only. With the optional Jev judge it also estimates how many of those tasks are really about the candidate.
run twice
The experimentbase vs cand Same code, same tasks, one difference:
  • base: all your current skills & rules
  • cand: the same + the new one
Screen first: the theme's own tasks, 2 runs each. Only a candidate that helps there pays for the confirm: every task, 3 runs each.
score
VerdictKeep or kill cortex score applies the gates below. It contains no model of any kind.
KEEP → live KILL → graveyard RECHECK → re-test a drop RERUN → untrusted data

What the scorer reads: one row per task

An example confirm with five tasks, three runs per task in each arm. A filled dot is a run that passed. The verdict is read task by task, never as an average.

taskbasecandwhat the scorer sees
task 01passed every run before, so it is protected. It held.
task 02+2 runs
task 03protected. It held.
task 04+2 runs
task 05unchanged
gained on 2 tasks · no task dropped · net +4 runs · the candidate loaded → KEEP
the gates
Win something and break nothing. A candidate is kept only when all of these hold:
  1. it gained something: at least one task passes more often;
  2. no single task dropped by more than one run in three;
  3. every task that passed every run without it still does (the protected set);
  4. the net win is at least two runs, so one lucky run is not enough;
  5. the candidate actually loaded in at least one rollout, or the win was not its doing.
Not "better on average". Tasks where the candidate never entered Claude's context are left out of the gates: both arms ran the same thing there.
▼ Kept items accumulate. Every always-on skill costs attention on every turn, so each one must keep proving it is worth it, or move to a tier that loads only where it applies.
/prune Delete what stopped earning its place monthly · and after every model upgrade

Every always-on skill's description sits in Claude's context on every turn. Prune measures what removing a skill or rule would really cost, on a snapshot that never touches your live files, and deletes only what costs nothing. It also narrows: a skill used in one area only moves to a path-gated skill or a rule that loads only there. A newer model may already do what an old skill teaches, which is why this runs again after every upgrade. Nothing runs until you approve the plan: it shows the rollouts, time, tokens and cost first.

InputA plan you approve After a model change, every item. Otherwise the few items there is most reason to doubt (at most prune.max_items, 3 by default): overlaps, narrow wins, the largest always-on descriptions. Items no task can measure are skipped. You see the cost and say yes first.
measure without
The experimentbase vs cand One item of difference, only on the tasks where it can load:
  • base: your skills & rules as they are now
  • cand: the same, without that one
Every run records what actually loaded, and what it cost.
decide
VerdictDelete or keep It fired, and removing it cost nothing?
ACCEPT → graveyard REJECT → stays UNMEASURED → stays RERUN → untrusted data
the one rule Deleted only on evidence. An item goes only when it fired during the tests and removing it cost nothing measurable. How recently you used it never decides a deletion: it only helps choose what gets tested. An item no task exercises is unmeasured, and it stays. A deleted item moves to the graveyard with its reason: buried, not lost.

Where a kept item lives

Not everything should sit in context on every turn. Evolve picks the narrowest tier that still loads before the mistake happens.

Rule .claude/rules/<name>.md, with paths

Injected in full when Claude reads a matching file. Claude has no choice, and it costs nothing until then.

For a short, hard "never do this" about existing files in one area.

Path-gated skill .claude/skills/<name>/SKILL.md, with paths

Offered when Claude reads or writes a matching file. Claude sees its name and one-line description, and must choose to open it.

For a procedure in one area, including creating new files there.

Always-on skill SKILL.md, without paths

Its description is in context on every turn, and Claude must choose it. This is the only tier with a permanent cost.

For a moment with no area, such as "before reporting done".

Some problems are not a skill at all. A fact Claude breaks during unrelated work belongs in CLAUDE.md, and a check that must always run is a hook. For those, Evolve makes the change, records it in the journal and runs no sweep: there is nothing to compare.

measured A rule that is in context always fires. A skill fires only when Claude picks it. Over 486 recorded lab rollouts on Claude Haiku 4.5, a visible rule fired 100% of the time, a visible path-gated skill 27%, and an always-on skill 0 times in 10. A skill gets picked when its description names the task at hand, and rarely when it names a side duty. See it in the lab →

the thinking behind it

Three simple ideas

The overview showed the workflow. These are the ideas that make it trustworthy. Each one is something you already know from everyday life.

1

A test is a bug you can replay

Like a checkpoint in a video game. When you fix something, Cortex saves the "before", so it can drop Claude back into that exact broken moment and see how it copes, with or without a given skill, as many times as it likes.

something breaks ✗ the test is red you fix it it works ✓ the test is green saved a checkpoint ↺ replay anytime
A saved test is trusted only if it is red before the fix and green after, which proves it actually catches the bug. Anything else is quarantined, with the reason written beside it.
why it matters These saved checkpoints become the ruler everything else is measured against. With no ruler there is no way to tell a good skill from a bad one, which is why collecting comes first.
Why the tests rewind to the broken commit, while the skills stay at today →
2

Judge a skill like a fair taste test

Two identical plates. One has the new spice, one doesn't, and everything else is the same. If the spiced plate wins, it was the spice. A new skill is judged the same way: the same jobs, run with it and without it, side by side.

the same jobs your saved tests without the new skill your skills as they are today with the new skill added the only difference compare scores did it help?
Only one thing differs between the two worlds, so a difference in the score comes from the new skill or from plain luck. To rule out luck, every job runs several times, and a win of a single run does not count.
the one rule that matters A skill is kept only if it helps at least one job and makes none of the already-working jobs worse. Not "better on average": nothing you rely on is allowed to break. That is what stops a skills folder from quietly rotting.
3

Keep only what would be missed

Take an ingredient out of the recipe. If the dish tastes exactly the same, it wasn't doing anything, so drop it. Skills get the same treatment, because every always-on one you keep costs the agent a little attention on every single turn.

take one skill out on a throwaway copy run the jobs again anyone miss it? compare the score used, nothing lost → drop it it ran, but was dead weight score dropped → keep it it was pulling its weight
A newer model may already know what an old skill teaches, so this runs again after every upgrade, to find the skills that have quietly become redundant.
never used ≠ useless A skill the agent never reaches for during the tests is not deleted: the tests simply cannot see it, so it stays and is marked unmeasured. How long ago a skill was last used never decides a deletion. It only helps choose what is worth testing.

It's a loop, not a line

Harvest feeds evolve, evolve feeds prune, and the loop keeps turning. Each turn adds one measured item, removes one, or changes nothing, and all three are fine outcomes.

harvest collect evolve measure prune remove

What ties it together

Each command is a fresh session with no memory of the last one. These files on disk are the memory: written by one command, read by the next. Commit .evolve/ with your repository.

.evolve/tasks/
The ruler. Real bugs, replayable forever. Grown by harvest, used by evolve and prune.
.evolve/lessons.md
One line per correction. Written by harvest, counted by evolve to find what recurs.
.evolve/config.yaml
The one file you edit: the rollout model, the runs per task, the gate thresholds, your build-cache folders.
.evolve/candidate/
The one skill or rule under test right now. It is not live, and it is never loaded into your own session.
.evolve/runs/
One results file per sweep: every rollout's pass or fail, what loaded, and its tokens, cost and time. Read by cortex score.
.evolve/journal.md
Every verdict, kept or killed, with its numbers. The record of why your skills folder looks the way it does.
.evolve/graveyard/
Every killed or deleted item, with its reason. Nothing in it loads. A buried name cannot be swept again, so a dead idea is not retried by accident.
.evolve/prune-plan.json
The prune pass you approved: which items, on which tasks, the estimate, and each decision. It lets a pass resume across turns.
.claude/skills/ & rules/
The live set, in tiers. Grown by evolve, trimmed and narrowed by prune, checked by cortex skills.