Something I keep turning over: what is a skill actually for, now that each new model does more of the job on its own. Where I land is that the stronger the model gets, the fewer and thinner my skills should be. Fewer is not weaker. What I cut is the count and the thickness, never what a skill is allowed to do. Every skill you write is a bet that the model cannot do something on its own, and that bet expires. The next one ships already knowing how to verify its own work and split its own tasks, and the patch you wrote for the last one now only makes it search more, detour more and burn tokens it did not need to burn. The more obedient the model, the more an old instruction costs you. My own usage says it plainly. I have explored 141 skills. Out of 10,100 runs, four of them carry 4,500, about 45 percent, and all four are Waza's. Everything else I ever installed barely moves. That is how I have kept Waza. Eight skills since April, none added since, and the part that sits in context permanently keeps getting smaller: those eight SKILL.md files were 164KB in mid July and are 128KB now, 22 percent off in two months. Duplicated gotchas went. Summaries that fought each other for routing went. Branches that almost never fired went. The detail moved into references that load only when the task needs them, so what you do not use never costs you anything, and not one skill can do less than before. The last two changes I made follow the same rule. think has to beat the one-line brute force version on risk, rollback or latency before it may add a file, an abstraction or a config knob, because winning on elegance does not count. check has to say keep, adjust or replace about the approach before it is allowed to list a single patch. A skill is worth what it lets the model do, not what it saves the model from doing. Install less, hold looser, keep the judgment with the model, and put the parts that must not move into code and tests. http://github.com/tw93/Waza