In the previous article we talked about the basics of how to customize your instructions, skills and hooks, and what they are useful for.
If you followed my guidance and did set up the Lessons instruction and worked on the project, you probably have some amount of Lessons as well next to the Memories.
This is great, the content loaded directly into your context is a short listed format, however this can still grow big.
I personally easily did create 1.4 entries per day, which can overly fill your context.
Your Lessons Are Costing You Context
Now let’s see how to tackle this situation and improve the cost-value ratio.
These building blocks determine and likely improve your experience while interacting with and churning anything out of Claude or any other agent through the harness.
You may have your project based memories directed into the project itself. Now you can track and observe them more easily, and they live together with the project.
As it was mentioned, if you do work, your Lessons will grow. The issue: repetitive or at least similar lessons appear, and some lessons may never be used again. Then you only have noise and context overhead.
You need curation, and this will be done both on the native Memories and on Lessons.
Please review the Claude instruction from the previous article, as it had some updates (restricted lesson recording, trigger extension as first action, capped the index line description).
The new feature is a companion Skill, named curate-learnings.
- If 3 or more Learnings say the same rule, we merge them into one themed file
- If a Learning is mature and its index line got too long, we compact on it
- If a Learning is mature and has good enough usage, we promote: it can go into CLAUDE.md/AGENTS.md
- If a Learning is mature, but no coverage/usage, evict/archive it from the index
Two of these are worth a closer look, because they are not the same kind of decision.
Compaction only rewrites the index line, the one that gets loaded on every request. The file body stays untouched, so nothing is lost and you pay less for the same knowledge. Eviction is the opposite, it takes an entry out of the index entirely, so it needs much stronger evidence.
The curation never deletes, just retires Learning files into archive and creates a tracking log, what happened during the run.
Compaction waits 30 days and eviction 60, but these are not calendar days, they are observed days. If you do not run the curation for a while, the session transcripts get pruned in the meantime, and there is a period where reads did happen and nobody counted them. So it only counts the periods the skill actually watched, and keeps a record of them so the next run knows where it stopped.
What counts as usage
Usage is measured from the session transcripts, so it is real evidence and not a guess. Two things are deliberately not counted, and a third one cannot be counted at all.
A session that wrote or edited the file gets no credit for reading it, because the harness makes you read a file before you may edit it. Maintenance would look exactly like usage otherwise. The curation runs themselves are excluded too, for the same reason: reviewing your Lessons should not make your Lessons look popular.
The third one is the limit you have to know about before you trust any of these numbers. The transcripts belong to Claude Code, so if you open the same repository in CoPilot, in another agent, or just in your editor, those reads leave no trace.
The count is not a measure of your use. It is a measure of your Claude Code share of it.
The consequence goes only one way: the number is always lower than reality. Zero reads means “no evidence of use”, never “proven useless”. Which makes it harmless in one place and dangerous in the other.
- For promotion it means under promoting. You may miss a good rule, but nothing bad happens.
- For eviction it is the real hazard. A Learning you lean on daily in CoPilot shows up here as zero reads and comes due on schedule.
This is why eviction is the most defensive verdict of the four, and why it archives instead of deleting. It keeps the 60 day clock, proposes at most 5 files per run so you can actually read them, opens the file before proposing it, and the archive move costs you one command to undo.
Promotion is measured differently, a raw read count has no time in it. Two reads while a topic is hot are one episode, the file was open because you happened to be working on that subject. Two reads a week apart are recurrence, and only recurrence supports what promotion claims: not “this was useful once” but “this keeps coming up, so load it on every single request from now on”.
So the gate does not look at the count alone. It wants at least 2 reads, from at least 2 different sessions, with at least 7 days between the first and the last, and 30 days of observation behind them so that a 7 day gap means something.
Promotion is decided by you
The promotion to instructions rules are manually gated and decided by the user.
The numbers above only rank a shortlist, they do not decide anything. Promotion is the only action that writes into CLAUDE.md or AGENTS.md, files loaded on every request in every session, and the only one with no way back: once a rule leaves the Lessons, nothing tracks it anymore, so no later run will ever tell you that it went cold. And the evidence behind the shortlist is the one harness evidence from above.
So every candidate is handled one by one, routed first, project specific rules to AGENTS.md, general harness rules to your global CLAUDE.md.
You can also nominate any Learning yourself, no matter what the counts say. Do use this, it is the only way a rule you only ever used in CoPilot gets promoted at all.
How a run goes
You call the skill, optionally with lessons-only or memories-only if you want to look at one store at a time.
It scans the transcripts first, before reading a single Learning, so its own reading does not pollute the next run. Then it merges the result into the tracking ledger next to your Lessons, which is the durable part: transcripts are pruned after 30 days, so without the ledger you could never prove that something was unused for 60.
Then it writes the report into a curate-notes folder, with the verdicts, the evidence behind each row, and the periods it actually observed. It stops there and asks for approval per group, and one by one for the promotions. Only after that it moves anything.
It never touches git, it just lists the paths at the end so you can review the diff and commit it yourself. Which is the point really, you stay the one who decides what your harness is going to read tomorrow.