Claude Code Skills

The Jump From Scaffolding to Personalization

My Claude code experience has changed dramatically in the last few weeks and I was trying to understand what felt so different.

I’ve spent the last month or two stopping my usual impulse of hopping from one AI tool to the next and instead have pushed myself to go deep into all the functionality Claude Code provides.

A lot of the markdown based prompt engineering and context hacking work I did in the past felt like I was working to make up for the limitations in the model or the tool. Spec driven development still can feel a lot like 2005 era waterfall even if I’m not spending weeks before I start coding writing and negotiating a spec with stakeholders.

For those of you hiding under a rock Anthropic introduced Skills a couple of weeks ago. Where MCP lets you expose an API directly to the model as a tool, skills lets you expose a tool to the model and tell you how you expect it to use the tool. Its hard to explain how big of a difference this little nuance makes unless you start using Skills.

I’m a firm believer that to understand something thoroughly you have to use it in anger. I’d been meaning to try out Steve Yegg’s beads which creates a JSON based project management and task framework for agents and sub-agents to use, so I decided I’d try to create a skill to go along with it.

The nicest part about skills and other markdown-based Claude config is that Claude Code itself is really good at helping you create and update them. I was able to quickly throw together a skill for beads but realized I was frustrated with some of the assumptions about how to use beads that got baked into the skill.

Introducing Beads Skill

In true Vibe Coding spirit after I iterated a few times on that initial skill and developed some strong opinions about how I wanted beads to work, then threw out the entire skill and started over, leading with my opinions and preferences about how I thought my instance of Claude and my local agents should be using the software.

I’ve made my second iteration available on Github and this skill has turned a frustrating experience with the very-alpha beads software into an enjoyable one. I use the features that work, and ignore the ones that don’t. I bolt on new features with a little config and a little bash. Instead of changing the underlying software or waiting for it to change I change the way I interact with it, sometimes multiple times a day.

Agents and Skills and Slash Commands

Prior to skills most of my fun experimentation diving deep into Claude features was focused on sub-agents and slash commands.

I’ve created a whole stable of agents, each one representing archetypes of coworkers I’ve worked with in the past and some representing people that I wish I’d worked with.

For beads I created a project manager, focused on the drudgery of making sure the code didn’t diverge too much from the planned scope and making sure we captured all the work we were doing in beads.

Previously I had created a software architect, a QE engineer, a CTO to bring me back to business value, and then tried to wrap all of these in a slash command that described how the group should work together. I was hoping that they would have entertaining and spirited discussions. The actual result was more Claude with a QE flavor, or Claude with a CTO flavor, all working more or less sequentially and in isolation each wanting to write their own markdown file to save their opinions for posterity. The discussions between me and these personas were interesting and helpful for stretching my own perspective but lacking the friendly chaos, spirited disagreement, and eventual compromise I was hoping for.

I introduced a Linux greybeard who loved to tell stories about how much harder Linux was in the 90s, and a hotshot dev, who made up for his lack of experience with confidence recommending modern tools and rewrites as the solution to all problems. Despite my attempts at introducing personality defects each agent still felt like its Claude persona took control in its typical pragmatic and practical way, strong opinions loosely held being one of its first principals.

Going forward I’ll likely replace my team dynamic slash command with a skill that captures more of the nuance about how and when my agents should interact I’m hoping that this layer might give me a bit higher precedence in the model’s context and influence the outcomes a little more.

The Future

All of this sounds like silly fun, but the reality has made me really revisit what quality means in a post-AI world. What if every 100 word design document produced by an engineer could get 5 passes of a CTO review? What if the most junior engineer on the team could have unlimited time to discuss how their 15 line Javascript change fits into the project architecture with a member of the gang of four?

Skills and agents give you a way to bake your own ideas of whats important in software development into your AI-coding workflow. I’m having my assumptions checked, my personal biases questioned, and getting more than a few laugh out loud moments along the way.