A blog post checklist before publishing works best as a file Claude reads, not a list you try to remember. You save one markdown file, ask for a check, and get back a numbered pass-or-fix list. My real one runs 20 separate checks. The version below is around 40 lines, it works as written, and you can save it and run it on your next draft today.
*Part 2 of Claude Code for Bloggers.*
For a long time my checking process was me, going off memory, at the end of a long writing session. Which is the worst possible moment to ask someone to be thorough.
It went about how you’d expect. I’d publish, feel good about it, and then notice three days later that the post had no FAQ on it at all. Not a weak FAQ. None. Same with tables, same with a Related section at the bottom. The stuff at the end of the process is the stuff you skip, because by then you want to be done.
A skill that shapes, and a skill that checks
In the first post in this series I saved my writing style as a skill so I’d stop pasting it into every new chat. That one shapes the draft while it’s being written. It’s about taste, it runs the whole time, and there’s no moment where it’s finished.
This is the other kind. It runs once, at the end, on work that’s already done. It isn’t about taste at all. Every line in it is a yes or no question a machine can answer better than I can at 11pm.
| A voice skill | A checking skill | |
|---|---|---|
| When it runs | The whole time you write | Once, when the draft is done |
| What it does | Shapes the wording | Reports what’s missing or broken |
| Judgment involved | Subjective, it’s your taste | Objective, each line is yes or no |
| What you get back | Better sentences | A numbered fix list |
| Who acts on it | Claude, as it writes | You, after you read the findings |
Both are markdown files in the same folder. They do completely different jobs.
What it catches that you won’t
Four things, and the first one is the reason to bother.
A missing section counts as a finding. This is the rule that changed my checklist from decorative to useful. An early version only looked at what was on the page and told me it looked fine. A post with no FAQ passed, because there was no bad FAQ to complain about. Now the absence is the finding. “No comparison table on this post” is a result, not a clean bill of health, and it’s exactly the failure a human reread never catches because nothing on the page looks wrong.
Banned words and phrasing tics. I keep a running list of words I refuse to publish, and I still type them. Greps don’t get tired.
Dead links. They rot months after you publish. Nothing on the page changes, so rereading finds nothing.
A missing answer capsule or no real numbers. The bits that decide whether an AI assistant can quote you. Easy to skip, invisible when absent.
The skill you can copy
Save this to ~/.claude/skills/post-audit/SKILL.md and restart Claude Code. It works as written. Swap the banned words for your own and delete any check you don’t care about.
---
name: post-audit
description: Audit a finished blog post before publishing. Use whenever I say a post is done, ready to publish, or ask for a pre-publish check.
---
# Pre-Publish Post Audit
Run every check below. Report findings as a numbered list, worst first, with PASS or FIX on each.
Report only. Never edit the post. Never remove a link.
## Structure
- One H1, and it matches the page title
- H2s read like things a person would search, not clever labels
- An FAQ section exists, 4 to 6 questions, each phrased how someone types it
- A comparison table exists if the post compares anything
- A Related links list at the end
A missing section IS a finding. Never report PASS for a section that isn't there.
## The opening
- The first paragraph answers the title question in under 80 words
- It still makes sense if you quote it on its own
- The main keyword appears in the title, the first 100 words, and one H2
## Substance
- At least 3 specific numbers
- At least 2 internal links, with descriptive anchor text
- Flag any claim I have not backed up
## Voice
- Banned words: [put your own list here]
- Contractions throughout
- No em dashes
## Links
- List every external link with its status
- Flag anything that looks dead, but do NOT remove it.
Some sites return errors to bots while working fine in a browser.
## Output
Numbered findings, worst first. Finish with one line: ready, or not ready and why.Two lines in there are doing most of the work. “A missing section IS a finding” is the one that makes it catch real problems. “Report only, never edit” is the one that keeps it safe, and it’s the next section.
Make it report, never fix
My checker told me a batch of my affiliate links were dead.
They weren’t. Amazon serves 404s to bots on live product pages, seemingly at random, and it does it to a headless browser too. The pages loaded fine in an actual browser the whole time. If I’d wired the skill to act on its own findings, it would have stripped working links out of my posts, and I’d have found out from the missing income rather than from the check.
So the rule I’d hand anyone building one of these: a checking skill reports, a human fixes. Put it in the file, in plain language, near the top. The temptation to let it clean up after itself is strong and it’s the first thing you’ll get wrong.
It generalizes past links, too. A checker that rewrites your sentences is a voice skill wearing the wrong hat, and you lose the thing that made an audit useful, which is that it hands you a list and lets you disagree with it.
Frequently asked questions
What should be on a blog post checklist before publishing?
At minimum: one H1, searchable H2s, an FAQ, a comparison table if the post compares anything, a quotable opening under 80 words, a few specific numbers, two internal links, and a link check. Add your own banned words. The list matters less than having it run every time instead of when you remember.
How is this different from a writing style skill?
A style skill shapes wording while you draft and never finishes. A checking skill runs once on a finished draft and gives back a pass or fix list. One is subjective and continuous, the other is objective and final. They live in the same folder and do unrelated jobs.
Should the skill fix problems automatically?
No. Make it report and let a person act. Automated fixing sounds efficient until a false positive deletes something real, which happened to me with links that were working fine. A list you can argue with beats a change you didn’t approve.
How long should a checking skill be?
Around 40 lines is plenty to start. Mine grew to 20 separate checks over months of catching real misses, and it only got that long because each addition came from something I actually shipped wrong. Do not write 20 checks on day one.
Do I need to know how to code to use this?
No. It’s a markdown file in a folder. You save it, restart Claude Code, and ask for a check in plain English. Nothing in the file is code and nothing runs.
Where do I put the file?
~/.claude/skills/post-audit/SKILL.md. The folder name and the name in the file should match. Restart Claude Code after you add it so the new folder gets picked up.
Try it yourself
Save the file, then run it against a post you already published rather than one you’re about to. A blog post checklist before publishing is most convincing when it finds something on work you thought was finished, and it almost always does.
If you haven’t made a skill before, the voice skill in part 1 is the gentler place to start, since a style guide is easier to write than an audit standard.
Next in Claude Code for Bloggers I’m getting into what all of this costs to run per month, with real numbers. Subscribe if you want it, and the workflow blueprints are still coming.
