The meta-learnings skill

This is the skill behind the "Behind this post" note at the end of Why I stopped writing, and why I started again. A skill is a set of instructions for Claude Code, kept in a file called SKILL.md. When I ask for the meta-learnings at the end of a session, Claude reads back through the conversation, sorts every correction by cause, notes who caught it, and adds the result to a log.

It is written for this site, so it mentions me, this website and my notes file. Replace those with your own. To use it, save the text below as .claude/skills/meta-learnings/SKILL.md in your project.

---
name: meta-learnings
description: Capture and present the meta-learnings of a working session on ernst-bolle.com, meaning why drafts and changes needed another round (dictation mishearings, invented or unverified details, not sounding like Ernst, visual claims made without checking, jargon, process mistakes, tooling limits, model switches). Appends an honest, categorised entry to notes/meta-learnings.md and shows a short summary in chat. Use it whenever Ernst asks for meta-learnings, a retrospective, lessons learned, "what went wrong", or why something took so many iterations, and offer it at the end of any session that shipped a post or site change, even if he does not ask.
---

# Meta-learnings

Ernst writes with an LLM in the loop: he dictates through Wispr Flow, Claude
drafts and builds, he reviews. This skill records **why iterations happened**,
so that he can see where the process leaks and, later, show a technical
audience what still needs human validation. It is not a complaint log and
not a sales pitch. The value is in honest, specific evidence.

`CLAUDE.md` holds the *rules* that come out of feedback ("never use em
dashes"). This log holds the *evidence* ("on 2026-09-20 a draft said X, Ernst
caught it, the fix was Y"). Keep them separate: rules go in `CLAUDE.md` as
the standing instruction there says, incidents go here.

## Categories

Classify every correction by its root cause, not by its symptom:

| Category | What it covers |
|---|---|
| Transcription | Wispr Flow misheard a word or name ("clampdown" for Calmcode). |
| Invented or unverified | Claude stated something Ernst did not give, or did not check: an invented number, a wrong link, a commit message describing a change not yet made. |
| Voice | Correct content that does not sound like Ernst: drama, hype, em dashes, appraisals. |
| Unverified visual | Claude said something looked right without checking it, or a rendering bug went unnoticed. |
| Audience | Jargon or examples that do not land with his readers. |
| Structure | Flow problems: a paragraph that comes out of nowhere, an abrupt transition. |
| Diagram | A generated diagram or visual that was wrong. |
| Process | How the work was done or shipped, rather than what it said: drafting before agreeing on the direction, building on an idea without questioning it, recording a one-off choice as a general rule, merging or publishing without asking, pushing to a pull request that was already merged. |
| Tooling limit | Something Claude could not do in this environment and had to route around. |
| Model | Ernst switched model; record what he said about why, do not guess. |
| New inspiration | Not an error. Ernst added an idea on a later pass. Count these separately: they show the process is nonlinear, not that something failed. |

## How to gather

Read back through the session and find every point where output was revised.
For each, work out:

- **What happened**, concretely, with the actual phrase or value.
- **Who caught it**: Ernst, Claude on self-review, or a check (screenshot,
  computed style, DNS lookup, build). This is the most useful column for a
  technical audience, because it shows which errors only a human catches and
  which only a systematic check catches.
- **The fix**, and the lesson if there is one.

Be honest in both directions. Do not inflate Claude's mistakes into drama and
do not deflect them onto tools; if the model invented something, say so. Do
not count a new idea from Ernst as an error. Only record what actually
happened in the conversation; if something is unclear, leave it out rather
than guess. The log follows the site's style rules too: no em dashes.

## Writing the log

Append a section to `notes/meta-learnings.md` (create it if missing) with this
shape:

```markdown
## YYYY-MM-DD: <what the session was about>

Model(s): <models used, and Ernst's reason for switching if he gave one>

| Category | What happened | Caught by | Fix / lesson |
|---|---|---|---|
| ... | ... | ... | ... |

**Tally:** <count per category>. Caught by Ernst: N. Caught by checks or
self-review: N.

**Takeaways:** two or three sentences on what this session shows about
working with an LLM.
```

`notes/` is outside `src/` and `public/`, so it is not published. Commit it on
a branch and open a pull request, like any other change.

## Presenting in chat

After writing the log, show Ernst a short summary in chat: the tally, who
caught what, and the takeaways. Keep it to what he can read on a phone. Link
to the log file rather than pasting the whole table.