What I Keep Asking For
Table of Contents
"Did you push?"
I typed some version of that a lot this month. So I counted.
In My Skills the "what is missing" list said: analysis of real conversations. Here it is. I took my last 100 Claude Code sessions and asked two things: which skills actually ran, and what did I have to say again and again? Then I put my own requests through the layer analysis from Towards a Meta Design of LLM Skills, the same one I use on bugs.
The idea: a request I type for the fifth time is a bug report. It reports that some step did not happen unless I asked for it. So every level of the analysis asks the same question as for a bug: what had to be true for me to have to say this?
The request that started this post is itself such a pattern. "Look at what I keep doing and make it a skill" is a skill too. More on that below.
The data
100 sessions, from 7 to 26 October 2026. 66 of them are in one work repository. The rest are research code, games, dotfiles, machine setup and this blog.1
A script pulls out only my own messages and drops the machine chatter. Four agents each read a quarter of the sessions and report patterns, with verbatim quotes. The agents' counts are estimates, so I recounted with grep, and then a verifier agent recounted mine. It found a quote that did not exist and a row made mostly of false matches. Both are fixed below. The analysis needed its own review loop.
Which skills ran
| Skill | Calls | |
|---|---|---|
review-verify-loop |
19 calls; typed as slash command 20 times | the default quality gate, also on prose |
bug-layer-analysis |
7 calls; typed 4 times | on real bugs |
| deploy, nREPL, merge, start-issue (work infrastructure) | 5–6 calls each | start-issue also typed 8 times |
decision-matrix |
2 | |
pre-mortem, assumption-stress-test, operator-neighborhood, operator-router |
0 |
A typed slash command may also show up as a call, so the two columns can overlap.
Look at the last row. The four operators from "written, not tested" in the last post ran zero times as skills in 100 sessions. I typed "pre-mortem" once, in the session where I wrote them.
My own deletion rule says: a skill without findings gets thrown out. These do not even have calls. So either they go, or their trigger descriptions are bad and the model never thinks of them. This data cannot tell the two apart. That is uncomfortable, and worth keeping in mind for everything below. Skills built at the desk, from a nice symmetric idea, did not get used.
L0: what I actually typed
| What I typed | How often | Example |
|---|---|---|
| push / commit / deploy | 56× in 27 sessions (47 distinct) | "push, update the PR body and post the reply" |
| open it (PR, editor, browser) | 46× in 30 sessions | "open the pr" |
| a write-up for someone else | 15× in 10 sessions | "short write up of this for my collegues" |
| status ping | 17× in 14 sessions | "state?", "stuck?", "progress?" |
| review-verify loop | 21× in 20 sessions | "implement, run review verify loop and make pr" |
| "did we / did you …?" | 10× in 8 sessions | "did we run review verify loop?", "did you push" |
| run it | 19× in 12 sessions | "run it" |
| make a skill or memory of this | 8× in 7 sessions | "is there a skill for this" |
| step back, other angles, simpler | 18× in 11 sessions | "take a step back, alternative designs" |
| benchmark against a baseline | 25× in 8 sessions | "I am fine with small scope benchmarks" |
| check claims, errata, novelty | 9× in 6 sessions | "make a list of claims it makes. do they hold" |
The patterns are regular expressions, and repeated messages count each time. Read the numbers as orders of magnitude, not as measurements.
Then there are the corrections, the moments where I had to stop the model:
- It estimated effort as if code were expensive. "eher 5 - 20 min". "just coding something is cheap".
- It found unlikely risks alarming. "die sind teilweise sehr unwahrscheinlich".
- Its designs were more complicated than needed. "sounds complicated".
- It said a feature was done, and the button was not there. "I don't see 'show in designer'".
- The path I gave to a tester broke on the second click. "after using it once it is also a 404".
- It rounded numbers up. "7.7 is not 10-20x".
- It wrote the story of how we got there instead of where we are. "die brauchen keine implementations histories, sondern den stand".
Funny thing: the most common message is not a hard question. It is "push" and "open the pr". The model can do the hard part. I spend my words on the last meter.
Up the layers
| Kind of error | Our mistake | Countermeasure |
|---|---|---|
| L1: The same follow-ups after every task: push, post, open, "did we …?" | each skill covers one step (deploy, merge, REPL); nothing owns the end of a task | done-check |
| L1: Multi-step routines explained again by hand: answer a review, open a PR, update a branch, hand over to testers, benchmark | done often enough to be skills, never written down | address-review, ship-pr, cad-handoff, perf-bench, an update mode for merge-into-release |
| L1: Text written for the session, not for the reader: history, letter codes, IDs, local paths | the reader was never named | reader-rewrite |
| L1: Claims in prose believed without a check | the review loop only covered code | claim-check |
| L2: The model's "done" is "it compiles and the tests pass". Mine is "seen working, reviewed, pushed, posted, tracked, handed over" | the definition of done lived in my head, so I was the one checking it | write it down, attach it to the end of every task |
| L2: The model's priors come from before cheap code: effort too high, risk too loud, designs too careful | corrected in conversation, never in memory | memory rules: estimate in agent time, rank risks by likelihood |
| L3: I am the glue: I carry state between the model, GitHub, the issue board, the test server and my colleagues, and I repeat the same setups | skills were shaped like infrastructure (one tool each), not like a lifecycle (one work item, start to handed over); nothing turns repeated requests into skills except me, noticing | lifecycle skills, and this analysis run regularly |
L2 is the interesting one. The model and I had different words for "done". Neither was wrong. Mine just was not written anywhere.
L4 I tried: "the human is the bottleneck". It sounds deep. It suggests no new search and no new countermeasure, so it is a platitude and out it goes.
The new skills
Generic, in bjs-claude-skills:
done-check- walks the definition of done before anything is called "done", and does or lists each open step.
claim-check- one verifier agent per claim in a text, against the primary source. The review-verify loop, for prose.
reader-rewrite- name the reader and their question, then apply fixed rules: the current state, written-out names, links, no local references.
skill-mining- this post as a procedure. Extract, layer, choose a countermeasure per class, recount, write. It is its own L3 countermeasure: the loop that turns "I keep saying X" into a skill no longer depends on me noticing.
Specific to my work repository: address-review, ship-pr, cad-handoff, perf-bench, and the cycle that ties them together.
The analysis also gave a rule for which form a countermeasure takes:
- a single preference goes into memory;
- a missing step goes into an existing skill;
- a new skill only when a multi-step routine shows up in at least three sessions.
The cycle as one skill
The L1 skills are still single steps. L3 says the gap is the lifecycle. So the last move was to write the lifecycle down: dev-cycle, once abstract and once mapped onto my work repository.
Nine stages: intake, branch, implement, seen working, review, ship, feedback, merge-ready, close. "Do that" runs them all. No questions in between. A question with an obvious answer gets that answer, written down as an assumption. It stops only at fixed gates:
- merging, which I always do myself;
- a deploy to an environment that is not mine;
- an outward post I did not ask for;
- an open product decision.
Each work item gets a state file that records every stage with its evidence. "State?" is answered from the file, and a new session can pick up where the last one stopped.
Think of a kitchen where the cook asks after every dish "should I plate it?", "should I bring it out?", "should I wash the pan?". You do not need a better cook. You need the cook to know what a finished dish means in this restaurant.
How well supported
Each new skill carries its counts and quotes as an evidence line, plus a deletion rule. None of them has run yet.
The four unused operators are the warning. They came from a clean structure at the desk, and nobody used them. These ones come from requests I actually made, which is a better start. It is not proof.
The test is the same analysis in a month. If "did we …?" and "state?" are still near the top, the cycle does not work.
Open questions:
- Were the four operators unused because they are useless, or because they are never triggered? An ablation could tell: the same case with and without the skill.
- Does "do that" over nine stages save my attention, or just move it to the gates?
- How much of the L0 table is my style, and how much is the tool? Someone else's 100 sessions would tell.
- Is "the model's priors come from before cheap code" true, or just my reading of three corrections?
Footnotes:
My own Claude Code session logs (~/.claude/projects), the most recent 100 sessions with at least one typed message, as of 26 October 2026. Extraction script and method: skill-mining. The request classes were counted with case-insensitive regular expressions over my own messages. Message counts include repeats. A verifier agent recounted every row and checked every quote against the extract.
Generated by Claude on Benjamin Schwerdtner's behalf.