Most people who build a "write like me" Claude skill start with their voice. I started with a punishment. In spring 2026 Google cut this site's indexed pages from about 7,000 to 1,700, and a meaningful share of the damage traced back to AI-assisted content that read fine and performed terribly: templated intros, interchangeable conclusions, and a few pages with fabricated claims that should never have shipped. The SEO content-writing skill I use today came out of that wreckage, and its core is not a style guide. It is a list of refusals, things the model must not do, each one traceable to a page that died.
Why custom instructions were never enough
Before skills, I tried the obvious things: a Claude Project with instructions, pasted style samples, ever-longer prompts. The output was competent and consistent in exactly the wrong way. Every post opened with the same rhythm, hit the same H2 pattern, and closed with the same CTA paragraph wearing a different hat. When I later audited 84 of my own published posts for a rewrite project, I could spot the generation batches by their shared skeletons. Google evidently could too.
The structural problem: instructions are one flat blob competing for attention with everything else in context, re-pasted imperfectly across sessions. A skill is different in kind. It is a folder in ~/.claude/skills with a SKILL.md that loads when relevant, versioned in git, edited every time reality teaches me something. My skill files literally carry an Updated: date comment at the top because I revise them the way I revise code.
What is actually in the skill
My seo-content skill has three layers. I will describe the real ones, not an idealized architecture.
1. An E-E-A-T framework with teeth. The skill encodes what first-hand experience signals look like concretely: original numbers, before-and-after results, process documentation, the mistakes section. When the skill is active and I ask for a draft, Claude asks me for the experience inputs it cannot invent: what did you measure, what broke, what would you skip next time. If I have nothing, that is the signal the post should not exist yet. This single behavior is the difference between AI content that survives quality updates and AI content that fills the crawled-not-indexed bucket.
2. Metrics as floors, not targets. The skill carries word-count minimums per page type (1,500 for a blog post, 800 for a service page), and immediately undercuts them with a note I wrote after watching padded posts underperform: these are topical coverage floors, and a 500-word page that fully answers the query beats a 2,000-word page that does not. Same with readability: the skill targets a Flesch range but explicitly records that readability scores are not a ranking factor, so the model never sacrifices precision to game a metric. Encoding the caveats alongside the metrics matters, because a model given a bare number will optimize it into the ground.
3. The refusals. This is the layer that came from the deindexation, and each rule has a body attached:
- Never invent statistics, studies, or citations. (An earlier version of this very post opened with a McKinsey stat I could not verify. It is gone.)
- Never fabricate testimonials, case studies, or review schema. Fake aggregate ratings were the single clearest cause of my deindex.
- Never open the body with a heading that repeats the title, a template bug that infected 87% of my old posts.
- Never reuse a CTA paragraph across posts. De-templating identical CTAs and H2s was a full workstream in my rewrite project.
- Verify load-bearing third-party facts (model names, versions, prices, dates) against the web before publishing, and cut what cannot be verified.
The skill at work: an 84-post surgical rewrite
The best evidence the system works is the project it powered. Over one stretch in mid-2026 I rewrote 84 recent posts in seven batches, using Claude Code with this skill active plus a pipeline around it: a resume manifest (REWRITE-STATUS.json) tracking every post as done or pending, per-batch apply scripts with range guards so a wrong ID could not clobber the wrong row, row-level backups before every write, and hard checks after (no H1 in body, no broken internal links, facts spot-verified). The skill handled judgment, the pipeline handled safety. That division is the whole trick: what a skill should and should not try to do is a lesson I learned by getting it wrong first.
The tangible fixes that pass produced: roughly 30 broken or bare-slug links repaired, invented benchmark numbers cut, timeline claims corrected against sources, and every templated closing paragraph replaced with one specific to its post. Scores I tracked per-post went from low-70s to mid-80s on my own rubric across the batches.
What the output honestly looks like
With the skill active, a first draft lands at maybe 80% of publishable. It gets the structure right, respects the refusals, asks for experience inputs, and writes in something recognizably close to my register. The remaining 20% is still human: the opinion sharpened, the anecdote only I know, the call on what to cut. I treat that as the correct equilibrium rather than a limitation. The moment I let the skill push to 100% unattended, I would be back to manufacturing the exact uniform content that got me deindexed. For scaled surfaces where full automation is the point, the constraint set is different, and I run a separate programmatic SEO skill with hard quality gates for those.
Mistakes to skip if you build your own
- Do not start with voice. Voice files produce fluent imitations of your phrasing wrapped around generic substance. Start with your refusals and your experience-input checklist; add voice last.
- Do not encode rules you cannot trace to an outcome. Every rule in my skill maps to a page that failed or a fix that worked. Untraceable rules accumulate into superstition, and the model follows superstition as faithfully as truth. My broader SEO automation setup stays lean for the same reason.
- Date-stamp and revise. SEO guidance rots. A skill that still encodes 2023-era keyword-density thinking is actively harmful in 2026. Mine gets edited after every Search Console surprise.
- Keep the skill in the loop, not at the wheel. Drafting with the skill inside a normal Claude Code workflow means every draft passes through your judgment. That review step is load-bearing.
Steal mine instead of starting blank
The refusal list, the E-E-A-T input checklist, and the metric-with-caveats pattern transfer to any site, and you will still need to earn your own version of the rules with your own Search Console data eventually. Start from a copy rather than a blank file: the skills I ship publicly, including the SEO family this post describes, are on my Agent Skills Marketplace. Take the SEO content skill, delete my scars, and let your own Search Console failures write the replacements.
