the work should leave a worker behind
An agent can solve a problem and lose the ability with the chat. The better outcome is to preserve what it learned: inputs, phases, choices, alternatives rejected, proof of completion, and the traps discovered. Another agent can then occupy the role without reconstructing the entire conversation.
This repo already does a bounded version. A repeatable run becomes structured method data in methods/. The CLI projects that method into a skill and checks that the projection is current. The explorable-page and visual-review methods were extracted from actual page runs, including the bugs and screenshot rounds that changed them.
The deeper recursive-intelligence research asks how to measure whether such methods actually improve future work. The implemented projection is real; a general self-improvement engine is still a research program. The meta-lab should show both the mechanism and the evidence of later runs, not imply improvement merely because a skill file exists.
the second run is the test
A method is easy to write after a good result. The test is what happens when a new actor uses it on a different case. Does the method tell them what to inspect before acting? Does it contain the choice that changed the original outcome? Does it say which tempting path failed? Can the next run show whether the procedure saved time or prevented an error? If not, it is a souvenir of work, not stored capability.
In this repo, a repeatable run becomes structured method data: triggers, phases, decisions, rejected paths, proof and a runs log. The CLI projects it into a skill another agent can load. That projection solves one narrow problem well. A better prompt or a cleaner skill file is not, by itself, evidence that future work improved. A later run has to use the method and leave a comparable receipt.
preserve the choice, not every keystroke
The most useful part of a run is often the fork that almost went the wrong way. A visual review method should remember that a build can pass while a mobile layout clips the headline. A research method should remember which ignored directory hid the PDFs. A sales method should remember the question that changed a generic page into one aimed at an actual buyer. These are causal details. Full transcripts contain them, but bury them under thousands of incidental tokens.
Extraction needs judgment. Keep the input conditions, the decision that mattered, the evidence that closed the step, and the failure mode a future actor should recognize. Remove details that only made sense on one Tuesday. When a new run encounters a counterexample, update the method with the new boundary rather than adding another universal commandment.
how high should the recursion go?
There is a tempting infinite ladder: a skill for writing a method, a method for judging the skill, a governor for the judge. Sometimes that ladder is useful. Usually it is a way to avoid the next real episode. The stopping rule is empirical: climb one level when repeated work has a repeated error that a reusable instruction can prevent. Otherwise return to the work.
The recursive-intelligence research explores a much larger version of this idea: systems that inspect their own operation and alter the methods they use. The immediate, inspectable version is smaller. Run a method, keep its receipt, compare the next attempt, and revise one instruction if the evidence calls for it.
This is the meta-lab’s promise for an operator. The company does not need to remember which model gave a clever answer one night. It needs the capability that answer exposed, available to the next worker under the right conditions. A method is successful when the next person can start further ahead and still see where to stop.
compare attempts without flattening them
A method does not need to make every future run identical. Research problems differ. Clients differ. A strong method tells the next actor which conditions matter and what kind of evidence would justify departing from the usual route. It preserves judgment by giving it a better starting point.
Comparison can be simple. Did the next run find the right sources faster? Did it avoid the known failure? Did the result survive review with fewer corrections? Did the method itself need an exception? A runs log can hold these observations without pretending that a single success proves a general improvement. The useful unit is the change in work under named conditions.
A mature lab might eventually choose between methods, detect when a method has gone stale, and learn which actors need different projections of it. Those are worthwhile questions. The first working loop is less glamorous: record the method, use it again, inspect what changed, edit the method. That loop already makes the organization less dependent on any one conversation.