My Skills
Table of Contents
Seven Claude Code skills that I use, or that I had to build in order to use them. They are public in bjs-claude-skills. The thoughts behind them are in Towards a Meta Design of LLM Skills.
In short: the model can probably already do everything listed here. A skill gives it direction, enforces completeness and makes its result checkable. Whether that brings anything in a given case is a conjecture, and each line below says how well it is supported.
Used
bug-layer-analysis
What it does: A bug becomes the starting point. First all the places where it shows up. Then the siblings with the same mechanism. Then upward: which assumption was wrong, which gap in the process let it through. On every level it says what we did wrong, and a countermeasure.
What it brings: The model does not stay at the one line where it hurts. It is steered to the design, and every level has to be backed by a search. A level that finds nothing new is dropped.
How well supported: It has run in several sessions, and two analyses exist as files, for example the case with the wall clock in the date expression. Whether the model would have reached the same depth without the skill, I have not tested.
decision-matrix
What it does: After Rich Hickey's Design in Practice. Criteria as rows, approaches as columns, the status quo first. The cells hold facts, not grades. The judgment stands separately next to it.
What it brings: Every approach has to answer every criterion. Gaps and hidden costs show up before the decision.
How well supported: used, not measured against an alternative.
review-verify-loop
What it does: A reviewer proposes findings. For each finding a separate verifier tries to refute it. What survives gets fixed. This repeats until a round leaves nothing.
What it brings: A single review pass delivers confident findings, many of them wrong. The refutation attempt filters them, and the verifier is more independent than a self-critique in the same context.
How well supported: used. The claim about independence is plausible but my interpretation. The research on self-correction supports it only cautiously.
Written, not tested
pre-mortem
The layer analysis with the time arrow flipped. The change is assumed to have failed, the causes are listed, generalized, and each gets a check that can run now. The gain would be that risks stand there as causes with a check and not as worries. Whether that holds only a real case will show.
assumption-stress-test
An assumption becomes "for all X in S, P holds". Then cases are generated that should break it, they run, and the assumption is reformulated. It is meant to attack the L2 assumption of an analysis systematically. "Holds" only means: holds under these cases.
operator-neighborhood
An operator is broken into axes, the neighbors are searched, each axis is flipped on its own. This is the skill that produced the last four, and it has exactly the flaw of construction at the desk: everything fits into the structure because it came from it. That is why it contains the rule that an operator is only built once an observed instance supports it.
operator-router
Before applying, it chooses which operator fits the problem, and names the reason. Schoenfeld showed in empirical studies that Pólya's heuristics alone are not enough and that control (selection, monitoring, abandoning paths) is decisive. 1 So far the router only chooses among skills from the same space.
What is missing
- An ablation: the same case with and without the skill, compared by siblings found, verified instances and levels that bring something new.
- Analysis of real debugging conversations: where does the model stop without the skill, and which moves are still missing?
- A section "evidence" in every skill with a deletion rule. A skill without findings after several calls gets thrown out.
Footnotes:
Schoenfeld, Mathematical Problem Solving (1985), according to secondary sources: https://tecfa.unige.ch/themes/sa2/act-app-dos2-fic-mathemat2.htm.
Generated by Claude on Benjamin Schwerdtner's behalf.