Common foundation
The learning loop: every session improves your skills
Seven end-of-session moves, lessons reread before every run and a separate judge: what worked goes back into your skills, under your control, without letting them grow at random.
The problem
A working session with Claude produces more than a deliverable: a method that works, a pitfall solved, a well-phrased prompt. These gains stay buried in the conversation and, the following week, you start again from scratch. Conversely, when you add an instruction after every incident, the skills grow unchecked and end up contradicting each other.
Step-by-step method
-
The seven end-of-session moves, as soon as a project, a format, a table or an artifact has been created, or a skill has been enriched:
- a dated skill line, filed by domain (“schedule: on-call table exported as a monthly view”);
- the agent card updated, with a “new” badge for 30 days and the status of its loop (active, idle, missing);
- a lesson: active if you asked for it, otherwise only proposed;
- a skill change, never made live: always through a proposal card;
- indexing of the deliverable, leaving out excluded data (patients, health, personal documents);
- a link recorded on both sides to the projects in the same area of expertise;
- an umbrella project proposed when two projects share an area, a deliverable and a deadline.
-
Read the lessons before running: before launching a skill, Claude reads its active lessons and applies them without asking you again. A lesson reread only afterwards prevents nothing.
-
A judge who is not a player: a read-only sentinel checks that the loop has actually closed. It names the gap; another skill repairs it. About a dozen checks, each with its own OK / warning / error thresholds, for example:
- a skill with no lessons file;
- an agent card not checked for more than 8 days;
- a link declared on one side only;
- a proposed lesson left without a decision for more than 14 days;
- a document indexed under a forbidden path.
A missing source gives “not measured”, with the reason, never “OK”. A check that misses its target two runs in a row moves to the top of the list, for a human decision.
-
The loop in both directions (example: this site). Each week, the gains are collected, anonymised, compared with what is already published, then proposed in two tables:
- A, from the work to the site: a proven method that deserves a guide or a step;
- B, from the site to the skills: when the public version is more cautious or better framed than the working version.
You reply “go A1 B2”. The weekly task only collects and proposes; it writes nothing.
-
A rule is born only from something the user said, never from observed behaviour. One line per rule: date, reason, action, the sentence actually said. A contradiction keeps both lines and is flagged. A rule never triggered in three months is a candidate for removal.
Deliverable
A dated log of what was learned, an active lessons file per skill, and a weekly sentinel that says whether the loop has closed. The loop complements the quality loop, which checks each deliverable, and the organisation into hats.
Safeguards
- Nothing is applied without your approval: the loop proposes, you decide.
- A corrected skill is a new version, never a live edit; the old one is archived.
- Private gains (health, finances, identity) stay private: they never go up into a shared log or onto a public page.
Starter prompt
End of session. Go through the seven moves: dated skill line, agent card, proposed lesson, proposal card for the skill concerned, indexing of the deliverable, links to the projects in the same area, umbrella project if needed. Present everything in a table for me to approve and write nothing before my “go”.