When I started building a Claude Code skill that could write blog posts in my voice, I expected the challenge to be technical. How do you capture tone? How do you make an LLM sound like a specific person instead of everyone?
Those problems turned out to be tractable. The harder problem: I didn’t actually know what my voice was until I had to write it down.
You Can’t Package What You Haven’t Named
A Claude Code skill is just a markdown file with instructions. You describe a persona, list vocabulary patterns, provide writing samples, tell the model what to avoid. No magic — just a style guide the AI reads before it does anything.
The catch is that writing a style guide forces you to be explicit. “I write like myself” isn’t a style guide. Neither is “I’m direct and technical.” You have to name the actual patterns: the deadpan understatement you use for emphasis, the way you lead with a specific example instead of a category, the words you reach for and the ones that make you cringe.
Most people have never done this. They’ve been “being themselves” for decades without ever auditing what that means.
Your Tacit Knowledge Has Been Locked Up This Whole Time
Every senior engineer I know carries a mental model for evaluating tradeoffs — when to abstract, when to stay concrete, when a framework earns its dependency, when it doesn’t. Ask them to explain it and you’ll get half of it. The rest only shows up when they’re reviewing a pull request and sighing.
That’s tacit knowledge. You know it, but you can’t easily transfer it. It lives in your judgment calls, your reactions, your habit of wincing when someone suggests a migration at the wrong layer.
Building a skill about yourself forces it out. You have to explain, in writing, what you actually think — not just demonstrate it in context. That’s uncomfortable. It’s also kind of the point.
This Is What Mentorship Should Have Been
The reason senior engineers are hard to replace isn’t their technical skills — those are documented somewhere. It’s the accumulated judgment they carry that never got written down.
A skill encoding your perspective is a weird form of mentorship material. It won’t replace a 1:1. But it can capture the version of you that knows when to push back on a design, what to ask when someone says “it’s too slow,” and which opinions are worth holding and which are just personal taste.
Future you will forget some of this. Your teammates probably never got the full version to begin with. The plugin is a durable copy.
Write It Before You Think You’re Ready
The thing stopping most engineers from doing this isn’t technical skill — it’s the feeling that they haven’t figured it out yet. Their opinions might be wrong. They’re still learning.
That’s fine. Write it down anyway. You can update it. A partially-captured philosophy is infinitely more useful than one that exists only in your head.
Start with what you say repeatedly in code review. Then the opinions you repeat in one-on-ones. Then what you’d tell a junior engineer with fifteen minutes. That’s your skill.
The AI won’t give you the answers. But it’ll show you which ones you’ve already been giving — without realizing you had them.