Project — 06
A small collection of skills I wrote for Claude Code. Each one is a single SKILL.md file that teaches Claude how I want a recurring job done — writing a commit, reading a website, designing an interface — so I stop explaining it from scratch every session. No dependencies, no build step: just markdown Claude picks up on its own.
01 — What's inside
Every skill here starts the same way: a task I keep redoing, and a set of corrections I keep repeating out loud. Once the corrections stop changing, they belong in a file rather than in a chat — so the folder grows a little each time that happens.
commit-message/SKILL.md
Reads the diff and writes the message: one-line title, the why, then bullets for what actually moved.
web-analysis/SKILL.md
Takes a link and reads the site back — layout, palette, type, and the details a visitor actually came for.
web-design/SKILL.md
The long one. How to derive a design direction from the subject instead of defaulting into one.
web-research/SKILL.md
Searches, then reports back: every claim linked where it's made, the disagreements left visible, the gaps named.
One folder, one markdown file, no dependencies
02 — Anatomy of a skill
However long a skill runs, it does the same three things: say when it applies, say how the work is done, and show what should come back. One slice from a different file for each, in that order.
01 — The header
Every skill opens with frontmatter: a name and a description. That description is the entire trigger — Claude reads it, decides whether the task in front of it matches, and only then loads the rest of the file. Which makes these the highest-leverage sentences in the project: too vague and the skill never fires, too greedy and it fires on everything. This one names the artefacts it covers, so it answers to the actual job rather than to the word design.
02 — The body
Below the frontmatter it is plain markdown, and its shape matters more than its length. Headings break the job into passes — look at the design, then pull out the facts, then compress it into a summary — and each pass is a short list of concrete things to find rather than an instruction to be thorough. Nouns survive a long conversation; adjectives quietly evaporate somewhere around the third message.
03 — The output
Most skills end with a template — the literal form the reply should come back in. commit-message closes on a heading skeleton: a one-sentence title, a short why, then bullets for what moved, renames and deletions included. Described in prose you get an approximation of that; written out as the markdown itself you get it back verbatim, every time. Every commit in this portfolio's history came out of this file.
03 — Closing
What I like about skills is that they make prompting durable. The instructions live in a file, in git, next to the work, and they get edited when the output is wrong — the same loop as code. Writing them is the interesting part: the reader takes everything literally and forgets nothing, so a woolly sentence quietly does nothing at all, while a precise one keeps paying out for months.