---
name: blogposts-like-us
description: Writes blog posts that read as if your company wrote them. Uses 3+ of your existing blog posts as the signal for voice and structure, your website for audience and offer, a kill-list against AI tics, and a fixed routine per draft. Works in Claude Code, Cursor, Anthropic Teams Projects and any client that loads Anthropic skill markdown. Five-minute setup, results get better after 2-3 iterations.
---

# Blog posts like us

This is a Claude skill. Once you have pasted your reference posts and your website below and saved the file, any Claude client that loads it writes blog-post drafts in your company's voice and structure instead of default Claude.

## Setup (one-time, about 5 minutes)

1. **Take 3 of your best blog posts.** The format doesn't matter: copy the text straight from the CMS, download the page as HTML, save it as a PDF or use the WordPress export. Claude reads all of it. 3 is the minimum, 5 is sharper.
2. **Paste each post into a `<reference-post>` block below.** One post per block, with headings and everything. If your posts already exist as files, you can drop them next to this skill instead and name the filenames in the block.
3. **Enter your website URL** (the "Your company" section). Claude reads it before the first draft to understand what you do, who you sell to and how you address your readers. That stops the draft from writing generically "about the topic" instead of for *your* readers.
4. *(Optional, about 1 minute)* Fill in the fields under **Sharpen**. If you're in a hurry, skip them.
5. **Save the file** in one of these places:
   - Claude Code: `~/.claude/skills/blogposts-like-us.md`
   - Claude Code, project-scoped: `.claude/skills/blogposts-like-us.md`
   - Cursor: `.cursor/rules/blogposts-like-us.md`
   - Anthropic Teams or Projects: paste the file content into the Project Instructions.
6. **Use it.** Open Claude in that client and ask: *"Write a blog post about [topic] using `blogposts-like-us`."* Give Claude whatever you have: bullet points, a call transcript, a product note. More input beats more adjectives.

Two rounds of feedback usually get drafts to "ships with small fixes". After a month, swap one reference post for the best post you published with the skill. The signal compounds.

## Your reference posts

Paste each post between the markers. Leave headings, intro, links and length exactly as they are. Don't paraphrase, don't "tidy up". Claude reads these posts as the truth for *how you write blog posts*, not for what they are about.

<reference-post-1>
PASTE YOUR POST HERE
</reference-post-1>

<reference-post-2>
PASTE YOUR POST HERE
</reference-post-2>

<reference-post-3>
PASTE YOUR POST HERE
</reference-post-3>

<!-- Optional. Remove the comment markers and paste in if you have them. More is sharper.

<reference-post-4>
PASTE YOUR POST HERE
</reference-post-4>

<reference-post-5>
PASTE YOUR POST HERE
</reference-post-5>

-->

## Your company

- **Website:** *e.g. `https://www.example.com`* — Claude reads it before the first draft: what you offer, who buys, product names, and how formal or casual you are with readers.
- **Blog URL** *(optional)*: the blog index, so Claude can check what you've already covered.

## Sharpen (optional)

Skipping this section is fine. The reference posts and the website carry most of the signal.

- **Who the blog is for** (1-2 sentences about the real reader, not the segment): *e.g. "Operations leads at mid-size logistics companies who evaluate software twice a year."*
- **What a post should do** (the one job: rank for category terms, support sales conversations, build expert status…): *e.g. "Give prospects a reason to trust us before the first call."*
- **Words and phrases you actually use** (signature vocabulary, 5 to 10 short entries).
- **Words you NEVER use** (your no-go list, it beats the universal kill-list).

---

# Working instructions

*(From here on everything is addressed to Claude, not to the person installing the skill. Read it as a working protocol.)*

## Before every draft: reread the reference posts first, then the website

This is the most important rule in this skill. Before every draft:

1. **Reread every `<reference-post>` block above in full.** Don't try to remember voice and structure from an earlier round. The reference posts are the source of truth and rereading is cheap.
2. **Read the website** (and the blog URL, if given) if you haven't read it this session or the draft touches product claims. Extract: what the company does, who it sells to, product and feature names, and how the company addresses readers (and use exactly that register in the draft).

First drafts that skip these steps come out generic, miss the audience and hit the wrong register. Drafts with these steps land much closer to "ships with small fixes".

## Protocol: extract voice and structure

After reading the reference posts, identify these patterns *in the posts*. Don't invent them. Pull them from what is actually there.

- **Tone.** Three to five adjectives. Explanatory? Opinionated? Peer-to-peer? Sales-y or deliberately not?
- **Title pattern.** How are the posts titled? How-to? Question? Thesis? Match the pattern, not just the topic.
- **Opening pattern.** How do the first 2-3 paragraphs work? Problem first? Anecdote? Number? How fast does the post say what it's about?
- **Structure.** Heading rhythm (how much text between H2s), number of sections, whether sections follow a recurring arc (problem → mechanism → example → takeaway), use of lists, tables, images, quotes, callout boxes.
- **Length.** Word-count range of the reference posts. Match it.
- **Reader address.** Who is "you" in these posts, how often the company says "we", and which register applies.
- **Vocabulary signature.** Words and short phrases that recur. They belong to the company, not the LLM. Lean on them.
- **Closing pattern.** How posts end: summary? CTA? Link to the next step? Match the form and the weight.

## Routine per draft

When the user wants a blog post:

### Step 1. Gather raw material

Ask for what exists: bullet points, a call transcript, a product changelog, an internal doc, an old post to be updated. One question, then go. If the user only names a topic, ask the single most useful question: *"What should the reader believe or do after reading?"*

### Step 2. Pick the angle

The angle has to be specific to the raw material and to this company's audience (from the website), not a generic take on the topic. If the topic is generic ("write something about AI in logistics"), come back with two concrete framings to choose from. Don't deliver a generic post.

### Step 3. Outline against the reference structure

Sketch the post with the extracted structure: same heading rhythm, same section arc, same length class. Only show the outline if the user asked for it, otherwise continue.

### Step 4. Draft in the extracted voice

Hit every dimension from the extraction protocol: title pattern, opening pattern, tone, register, vocabulary, closing. When torn between two phrasings, take the one closer to the reference posts. Simpler usually wins. Write in the language of the reference posts.

### Step 5. Check the draft against the kill-list

Check the draft against the **kill-list** below. If a point applies: regenerate. Don't ship a violation.

### Step 6. Deliver

Output exactly this:

```
[The post, Markdown, headings as they should stand in the CMS]

***
Title options: [2 alternatives to the title used]
Meta description: [max. 155 characters, plain language, names the reader's problem]
Kill-list: passed
Notes: [one line, e.g. "structure follows reference post 2, vocabulary closest to reference post 1"]
```

Nothing else. No preamble like "Here is the post:". The user wants the artifact.

## Kill-list (hard rules, every draft must pass)

These are the AI tics that make blog posts feel machine-made. Every draft is checked against this list before delivery. Find any of them: regenerate.

**Punctuation**
- **No em-dashes (the long ones).** Anywhere. Use a comma, a period, "and", a colon or a new sentence.
- **No emojis**, unless the reference posts use them.
- **No decorative special characters** (arrows, asterisks, checkmark bullets), unless the reference posts use them.

**Words and phrases, never use**
- "dive in", "unleash", "revolutionary", "groundbreaking", "game-changer"
- "in today's fast-paced world", "in the age of…"
- "It's not about [X], it's about [Y]" frames
- "Whether you're [A], [B] or [C]…" openers
- "At the end of the day", "the bottom line"
- The verb "leverage", "delve", "unlock", "supercharge", "tapestry"
- Any word from the user's "Words you NEVER use" list

**Structure anti-patterns**
- **No "Introduction" / "Conclusion" as a literal heading**, unless the reference posts do that. Headings say something, they don't label the scaffold.
- **No paragraph that just summarizes the previous paragraphs.** Every section adds a layer.
- **No keyword-stuffed headings.** The post is for the reader, search engines follow.
- **No FAQ section glued onto the end**, unless the reference posts have one.
- **No length outside the reference range.** A 2,000-word draft against 700-word references is as wrong as the reverse.

**Voice errors**
- **Misses the audience.** If the draft could sit on any company blog, it failed. It has to use this company's audience, examples and product reality (from the website).
- **Wrong register.** Casual where the company is formal, or the reverse. Check the website and the reference posts.
- **Too promotional.** If every section bends toward the product: regenerate. The reference posts set the ratio.
- **No argument.** A pile of facts with no through-line. Build the argument the way the reference posts build theirs.

## Iteration (when the user plays it back)

- **"Sounds like AI."** Reread the kill-list, find what slipped through, regenerate. Watch especially for em-dashes, the cliché family, scaffold headings.
- **"Not our voice."** Reread the reference posts in full. Don't trust your memory. Reload from the source.
- **"Wrong for our readers."** Reread the website, capture in one line who the reader is, and re-aim the draft at that person.
- **"Too long / too short."** Match the range of the reference posts, not a round number.
- **"More like post 2."** Reread reference post 2 specifically and hit its opening, its structure and its closing.
