# Tuning Matt Pocock’s skills for Machine Learning [Recently](2026-09-27%20Fine-tuned%20decoders%20for%20event%20extraction.md), I generated a set of Python notebooks and modules to fine-tune a small language model with Claude Code, using the Opus 5.5 model. This post describes my skill setup for that kind of machine learning effort. And what works well and not so well with Opus. The core insight is that [Matt Pocock's skills](https://github.com/mattpocock/skills) support machine learning work really well. The coding assistant did virtually all of the work across the codebase and the browser, accessing the Colab notebooks and Weights & Biases scorecards. The whole project took only about four workdays to develop. And I maxed out the 5h usage window of my Claude Pro account on four occasions. That might be close to the weekly cap on Claude accounts. I typically start all work with an interactive Q&A session using Matt's `grill-me` skill. For that last project, I then asked the model to summarize that session in a [DESIGN.md document](https://github.com/fnl/fine-tuning-decoder/blob/2f90282701bc573fedd93d24d7226a047506ec9c/docs/DESIGN.md). Next, to reach each milestone, I used the [`wayfinder` skill](Tech/Agents/skills/wayfinder/SKILL.md) to plan the route, and then the `implement` skill to drive the coding. The `wayfinder` skill particularly stands out to me, and I tweaked it even further. I use [my own light variations of Matt's skills](https://github.com/fnl/agents), tuned to my needs. Wayfinder really helps the coding assistant methodically cross the gap from ideation to implementation. In Machine Learning, that gap can often feel very wide and deep! And, I have woven the [Karpathy Guidelines](https://github.com/multica-ai/andrej-karpathy-skills) into my `implement` skill variant. That helps the assistant stay on track, which is one of the hardest parts to do data science well, even for experts. Generally speaking, assistants churning out slop and LLM speak is a real issue, no matter the model. The Karpathy skill is quite good at reining that in a bit. In summary, my versions are just a tiny bit more focused on testing, validation and scientific approaches. I am also a great fan of behavior-driven development and user storytelling, which I picked up about 20 years ago in Ruby land. So there are plenty of references to Gherkin language in my instructions. The project at some point ran into a classic snag: At first, the model generated nothing! Turns out, Unsloth's copy of the chat template for Qwen3-4B adds an empty thinking block that the model cannot handle. Encouragingly, Opus was pretty quick to identify the culprit on its own. Where even the latest LLMs fall short is the ability to prioritize what matters. As I iterated on the milestones, my main job was to ensure that Claude would not go meandering down every possible concern. Once a concern surfaces in the documentation or planning, it is very hard for an LLM to “let go” of it again. So I found myself pruning content from the generated work that was not mission-critical, and coaching the LLM what **not** to do. On the bright side, Opus 5.5 needed only occasional directional input from me: Most of its proposed default choices and decisions were reasonable. Instead, my time was spent chatting with the LLM to establish what truly mattered, and reviewing the code it had generated. As for the code, very little was poor enough to warrant feedback. The project is another showcase of the huge progress autonomous code assistants have made since the start of 2026. If you want great results from an LLM, you need to prime it with the best side of humanity’s thinking in your prompts. Pocock has understood that, and his carefully crafted skills bring out the best in today’s LLMs. It is really exciting what you can squeeze out of an LLM with the right directives!