My Claude Code Skills

I’ve published a small collection of Claude Code skills as a plugin. There are two so far: one that runs a technical interview against you and then tells you the truth about how it went, and one that walks you through configuring a GitHub repository properly.

Neither of these is technically impressive. Both exist because of the same observation: there are things I know I should do, and things I know would be good for me, and in both cases the friction of getting started is what stops me. Skills turn out to be a nice way of packaging up “the version of me that has already thought about this” so that future me can just invoke it.

tech-interview: a sparring partner that doesn’t flatter you

The first skill runs a technical interview. You tell it the level you want to be assessed at, optionally a stack and a format (coding, architecture, debugging, code review, refactoring), and it poses a question calibrated to that level, then gets out of the way.

You can steer the problem itself, too. Free-form constraints are part of the invocation, so “concurrency-heavy”, “no frontend”, or “something involving a queue” all work, as does a time budget if you only have half an hour. If you’d rather not decide anything, invoke it bare and it runs a short setup wizard, and “surprise me” is an acceptable answer to any of its questions. I tend to use the constraints to aim at whatever I’m avoiding: if I’ve not touched SQL in six months, “Python + Postgres, heavy on the queries” is a much better use of an hour than another problem within my comfort zone.

The getting-out-of-the-way part is the point. It’s easy to get an LLM to ask you an interview question. It’s much harder to stop it helping you answer it. By default these models are relentlessly encouraging: they nudge, they hint, they tell you you’re on the right track. That’s pleasant, and it’s useless for practice, because real interviews don’t do that. This skill is instructed to behave like an actual interviewer: it answers clarifying questions factually, it doesn’t coach, and if you go quiet it waits.

When you say you’re done, it does the thing good interviewers do and mediocre ones skip: it probes. Not “I noticed your error handling is missing, why?”, which hands you the answer, but “walk me through what happens when the network drops mid-request”, which makes you find the hole yourself. If you deferred a decision during the session and never came back to it, that’s the first thing it asks about. Then it writes up an honest evaluation.

It also remembers. Sessions get logged, so it won’t hand you the same shape of problem you saw last week, but it will deliberately bring one back after a month or so, tell you it’s doing it, and let you see whether your approach has improved. Practising interviews is one of those things, like flossing, that everyone agrees is worthwhile and almost nobody does, because setting it up takes more activation energy than the practice itself. Reducing that to typing /stut:tech-interview senior removes the excuse.

I use it when I’m rusty, when I’m curious how I’d do at a level I’ve not interviewed at, and occasionally just to be humbled. It’s reliably good at the last one.

github-repo-config: the settings you always mean to sort out

Every repository I create goes through the same lifecycle. I create it, I push some code, and I tell myself I’ll set up branch protection and sensible merge settings later. Later arrives the first time something annoying happens: a force-push eats history, a merge commit lands where I wanted a squash, or a half-reviewed PR gets merged because nothing said it couldn’t be.

The problem isn’t that any of this is hard. It’s that it’s a pile of small decisions spread across several screens of GitHub settings, each one requiring you to remember what the options mean and which one you actually want. So it gets deferred, indefinitely.

The skill turns that into a conversation. It checks you have the access you need before asking you anything, shows you what the repository is currently set to, and then walks through each decision one at a time with a recommended answer already picked out. If you trust the defaults you can say so once and it applies the lot. If you want to know why a setting matters, you ask, and it explains before re-asking.

My favourite part is that it knows about the traps. If you’re the only person with access to a repository and you ask for required PR approvals, it will point out that you’ve just built a door you can’t open: you can’t approve your own pull requests, so nothing would ever merge without an admin override. It also reads your GitHub Actions workflows before applying anything and warns you if a rule you’re about to enable will break automation that pushes to the branch. That’s the kind of failure that normally surfaces days later, in a workflow run you’re not looking at, and one a checklist in your head never catches.

The result is that repositories get configured properly at creation time, in a couple of minutes, instead of “eventually”, which, as we all know, means never.

Why bother packaging these?

Both skills are, at heart, just carefully written instructions. But that’s what makes them worth sharing: the value is in the accumulated “oh, and watch out for this” details, like the interviewer who won’t hint and the solo-repo approval trap, and those took iterations to get right. Once they’re captured, everyone gets the iterated version for free.

Installation is the standard plugin flow:

/plugin marketplace add stut/skills
/plugin install stut@skills

If you find them useful, or find a trap they don’t yet know about, issues and pull requests are welcome.