Every post we publish on this site gets the same treatment before it goes live. A meta description sized for search, an FAQ block with structured schema, internal links, a WordPress excerpt, and a subheading under the title. At first that meant typing out the same list of instructions into Claude at the end of every draft, the same five things, same wording, every time.
We finally sat down and packaged it into an actual skill, a set of instructions Claude reads automatically the moment it recognizes we’re finishing a blog post. We don’t ask for it anymore. It just runs.
What is an AI skill? An AI skill is a packaged set of instructions an AI assistant reads automatically when it recognizes a matching task, rather than instructions typed out fresh each time. At jamn, we use skills to automate repeatable parts of our own workflow, like the SEO package attached to every blog post.
This connects to something we covered in our post on Google’s query fan-out technique — how search engines break a single query into several to parse intent, the same underlying shift that makes structured, self-contained content worth building in the first place.
What a skill is
Since the two terms get used interchangeably here’s a quick distinction.
An AI skill is a packaged set of instructions Claude reads before doing a specific kind of task. Practically, it’s a folder with a main file — the SKILL.md — plus, sometimes, other material sitting alongside it: reference docs and templates, or a script when the job calls for real computation instead of just following instructions. When a task matches what the skill covers, Claude opens that file first and follows it instead of guessing at conventions from general training.
The trigger itself comes down to one description written into that main file. It tells Claude exactly when to use the skill, so the skill loads itself the moment a matching task shows up. For jamn, that means the skill loads the instant a blog draft for jamncreative.com is finished, without anyone typing “run the SEO package.”
.md just means Markdown, the plain-text format behind headers and bullet points. Links work too. It’s lightweight and easy for both humans and models to read, which is why skills and documentation like READMEs tend to be written that way. It’s how the instructions inside a skill happen to be written, but plenty of markdown files aren’t skills at all. A blog draft is markdown. So is a set of meeting notes. Neither one is a skill.
Every skill has a markdown file inside it, though the reverse isn’t true — a markdown file on its own is a skill only when it’s paired with that trigger description. The skill is the trigger plus the instructions; the markdown file is just the container those instructions are written in.
A skill folder isn’t limited to markdown. It can hold a JSON schema template or a style guide. It can hold data files and reference images too, when the job needs them. The markdown file stays the entry point Claude reads first, and it points to the rest.
A featured image for each post could get generated the same way, as part of this same pass. At jamn, we customize our own images instead, so that piece stays outside the skill.
Do you have to ask for it?
No, that’s the entire point of building one. Once the skill exists, Claude checks the task at hand against its description before doing anything else, and finishing a blog draft matches that description on its own. The package gets built without anyone asking for it.
Why a checklist in your head isn’t the same as a checklist a system follows
A mental checklist drifts. What you remember, and how well, shifts.
Here’s an example of the drift catching up with us: Google retired the FAQ rich result — the dropdown that used to show FAQ answers directly in search results — as of May 7, 2026. We kept describing our FAQ schema as something that would produce that dropdown, well past the date it stopped being true.
That correction now lives in the skill itself. The FAQ schema still gets built into every post — it’s still useful for how search engines and AI systems parse the content — but the package no longer claims a rich-result benefit that doesn’t exist anymore. Fix it once, in the instructions, and it’s fixed everywhere those instructions get used going forward. That’s the entire case for building a skill instead of relying on memory: a correction made once gets applied every time after, rather than resurfacing as the same mistake three posts later.
What’s in the package
Five things, every post, no exceptions:
- A meta description built for search — front-loaded with the topic, sized to the length search engines display in results, never a copy-paste of the title.
- A five-question FAQ, with matching JSON-LD schema, written to answer each question completely on its own — since search engines and AI assistants often parse these independently of the surrounding post.
- Internal links — always at least one to another post on the site, and at least one to the specific service or work page the topic connects to, rather than defaulting to the homepage — the specific page the reader would want next.
- A WordPress excerpt — shorter than the meta description, built for the blog listing page rather than the search snippet.
- A subheading under the title that adds a second piece of information instead of restating the headline.
Where this goes next
The skill also runs a voice check now, a scan for the handful of words and sentence patterns we’ve decided don’t belong in our writing, flagged before the post ever gets read by anyone else. That check used to live in our heads too, applied unevenly depending on how close to the end of the draft we were.
If there’s a piece of your own workflow you find yourself re-explaining the same way each time, to a person, to an assistant, or to yourself, that’s usually the sign it’s ready to become a system instead of a memory.
