The Skills I Actually Kept: My Claude Code Skills, and What I Use vs Build

I was mid-sentence, again. Typing the same block of instructions into Claude Code for the third time that week — the tone rules, the frontmatter shape, the “don’t smooth my English” reminder — and I stopped halfway through and thought: I’ve typed this exact paragraph before. Word for word, basically.

So I asked it. Straight up: “what am I repeating that I should turn into a skill?”

It told me. Not in a clever way — it just looked at what I’d been asking for, over and over, and named the pattern back to me.

That’s the whole discovery, honestly. If you catch yourself re-typing the same instructions, the AI can often spot the repetition before you do — ask it.

I wrapped that first one into a skill file and never typed the block again. Then I did it again for the next repeated thing. And the next. A while later I’ve got a shelf of these things, and figuring out which ones are worth keeping taught me more about how I actually work than the skills themselves did.

(If you’re wondering what a skill even is mechanically — I wrote the theory piece already. This one is the collection, and the judgment behind it.)

Use what exists, build what’s mine

Here’s the line I’ve landed on, and it took a while to get there: a skill you write yourself is easier to write, and far easier to maintain, than one you bend to fit your process.

There are skills out there for almost everything now, most of them free and open. Some are genuinely good — general-purpose, well maintained by people who do that one thing better than I would. I use those, gladly. But the moment a skill needs to know my frontmatter schema, my deploy sequence, my voice — forking someone else’s becomes archaeology. Every time their version updates, I have to re-diff my hacks against it. Writing my own from scratch is maybe an hour. Maintaining a fork of someone else’s forever is a slow leak.

So: generic → reuse it. Mine → build it, even if it’s rough.

A skill, mechanically, is nothing fancy. It’s a markdown file with a name, a description of when to fire, and instructions:

---
name: my-thing
description: Use this when the user asks to do X in Y context.
---
Do the following steps when triggered...

That’s it. The bar to write one is almost embarrassingly low. Which is kind of the point.

The shelves

Content & writing

This is the shelf that started it all — the loop that gets a raw thought out of my head and onto the site without me re-explaining myself every time.

• write-article takes an idea, a bullet list, or a rough note and turns it into a publish-ready draft in my voice. I still type /write-article more than any other command I own.
• alessio-pocket reaches into my voice-note recordings directly and drafts them straight onto the blog. I talk while running. It writes while I keep running.
• alessio-cover generates the watercolor cover for each article, locked to one house style, so I never have to explain “no, not that blue” again.

Design system & UI

This is the shelf that keeps the AI from reinventing my own components every single time it touches a screen.

I’ve got a whole family of design-system skills — one per UI surface. Filters, checkout, the admin header, the footer, tooltips, each its own “read this before you touch this screen” contract. So when the AI goes to change the filters, it reads the filters skill first and uses the components that already exist instead of inventing a fourth button style.

• A master one fires before any UI change, so nothing gets edited blind.
• And a mobile-QA gate loads every route at phone width and desktop width and checks the layout didn’t quietly break. (You know the bug. Looks perfect on your laptop, falls apart in a thumb.)

Ship it (deploy & CI/CD)

The one I’ve replicated in every single repo I own, because typing the same eight-step deploy dance by hand is how mistakes happen.

commit-push-deploy does the whole thing: test → build → auto-fix what it can → commit → push → open a PR → watch CI → merge → verify the deploy actually landed. Color-coded gates the whole way — 🟢 keep going, 🟡 look at this, 🔴 stop. There’s also server-restart, a tiny sibling that just restarts my local dev server, because apparently even that was worth automating once I noticed how often I typed kill then npm run dev by hand.

SEO

My SEO skills are fully generic on purpose — nothing about them knows Astika exists — because search fundamentals don’t change per project.

On-page + schema checks, an editorial-calendar system, a skill that only submits the pages worth indexing instead of everything, and one that pulls click/impression numbers straight out of Search Console so I stop tab-switching to check.

Here’s the honest exception, though: for broad SEO auditing I don’t reinvent the wheel — I lean on the public claude-seo plugin. It’s generic by design, somebody else maintains it, and my problem there isn’t personal enough to justify owning it. Use what’s already there.

Brain-dump to plan

just-do-it — I ramble a voice brain-dump at it and it turns the mess into a structured task list, then executes it.

No format, no ordering, no thinking about what comes first. I just talk. It sorts. Then it goes and does the list. Half the time the value is the sorting alone — hearing my own chaos come back as three clean steps.

Let the robot test its own work

A pair of skills, uat-define and uat-execute — one writes the acceptance test, the other drives an actual browser to run it and mark each check pass or fail. I don’t touch either step.

I wrote a whole separate piece on this because it deserves the space. Short version here on purpose.

Run every repo like its own team

A shared handover / issue-work protocol I copy into every repo, so separate codebases pass work to each other the way separate teams would — a ticket, not a vibe.

Same format everywhere: what changed, what’s expected next, what to check before picking it up. It sounds small. It’s saved me from “wait, what was I doing here” more times than I’d like to admit.

Housekeeping

The unglamorous shelf — the stuff that keeps sessions from quietly falling apart.

worktree-open, worktree-commit, worktree-push, worktree-close, so I can run parallel work without stepping on my own branch. And a small task-memory skill that stops Claude from forgetting its own task list mid-session — also its own article, also worth reading if that’s ever bitten you.

Beyond code

The inspiring part, kept short on purpose: this stops being about repos pretty fast. I’ve got a tiny skill acting as a co-pilot for my own job-hunt admin. One that checks whether an Italian traffic fine is actually valid before I pay it. One that classifies my personal finances. One that turns family memories into chapters of a book for my kids.

None of that is code. All of it repeats. If it repeats, it can be a skill.

When I reach for someone else’s

The rule, plainly: I reuse the frameworks that solve a problem everyone has — the GSD framework for structured execution, claude-seo for broad audits, Figma and other MCP servers for design context I could never replicate myself. I build the parts that are unmistakably mine — voice, deploy shape, review process, the small annoying repeated things nobody else has a reason to solve for me.

The deciding factor is never “can I build it.” It’s always “who’s going to maintain it in six months.” If the answer is a maintainer with more users than me and more reason to keep it current, I use theirs. If the answer is just me, bending someone else’s assumptions to fit mine forever, I build.

The shelf, roughly

Skill area	What it does for me	Use or build
write-article	Idea/voice note → publish-ready draft	Build
alessio-pocket	Pulls voice recordings and drafts them onto the blog	Build
alessio-cover	Watercolor cover in one locked house style	Build
Design-system skills (one per surface)	“Read before you touch this screen” component contracts	Build
Mobile-QA gate	Loads every route at phone + desktop widths	Build
commit-push-deploy	Test → build → PR → CI → merge → verify, gated	Build
server-restart	Kills and relaunches local dev server	Build
just-do-it	Voice brain-dump → structured task list → executes it	Build
uat-define + uat-execute	Writes and runs acceptance tests via real browser	Build
handover / issue-work	Ticket-style handoff between my own repos	Build
worktree-*	Open/commit/push/close isolated sessions	Build
Task memory	Stops mid-session task list amnesia	Build
SEO on-page/schema	Checks specific to how I publish	Build
SEO auditing	Broad site/page audit	Use (claude-seo)
Execution framework	Structured discuss→plan→execute loop	Use (GSD)
Design context	Pulls real design system data into a build	Use (Figma MCP)

Not exhaustive. Just the shape of it.

What are you retyping

I still ask the same question every few weeks: what am I repeating that I haven’t turned into a skill yet. It’s rarely the big obvious thing. It’s usually some small paragraph I’ve typed four times without noticing, the kind of thing that only shows up when someone — or something — points it out.

If you sat down and asked your AI the same question about your own week, what do you think it would say back?