// Writes blog posts for simple-history.com matching the author's voice and style. Use when drafting posts, announcements, or marketing copy.
| name | writing-blog-posts |
| description | Writes blog posts for simple-history.com matching the author's voice and style. Use when drafting posts, announcements, or marketing copy. |
| allowed-tools | Read, WebFetch |
Create blog posts for simple-history.com that match the author's established voice.
Voice: Conversational, knowledgeable, friendly expert — must sound human, not AI-generated Structure: Short paragraphs (2-4 sentences), clear headings, bullets for lists Pronouns: Address readers as "you" Avoid: "dive into", "let's explore", "in today's digital landscape", excessive exclamation marks
Blog posts must read like a real person wrote them. Watch for these AI tells:
Instead: have an opinion, acknowledge criticism honestly, use casual phrasing, and let some sentences be short or incomplete. Read it back and ask "would a person actually write this?"
Release posts have a narrower audience than general blog posts: existing users of the plugin, not new visitors. They already know what Simple History does. They want to know what's new for them, quickly.
For an incremental release, the narrative section above the Full changelog block should be ~3,000–4,000 characters (roughly 90 seconds of reading). A marquee feature release (like 5.27.0 — AI agent attribution) can run longer; an incremental release (like 5.28.0) should be tighter. If the body just restates what the Full changelog lists, cut it. The changelog is the complete reference; the narrative is the "what's important and why you care" version.
3–4 H2 sections is plenty for an incremental release. One per headline feature, optionally one "Other highlights" bullet list pointing into the changelog, then "Upgrading". Don't write a section per feature when several can share a heading.
The is-style-info opening paragraph is for the headline benefit, not a full feature spec list. A returning user just needs the punchline. If the body section right below it enumerates the same things, the lead enumeration is redundant — cut the duplicate from the lead.
Also: don't re-explain the product. "Simple History is a plugin that…" never belongs in a release post lead. Start at the news.
The audience is mostly site owners, agencies, and freelancers. A minority are developers. For each technical reference, ask: does a non-developer user need this phrasing to understand the value?
Keep the technical version in the Full changelog block where developers go for the complete reference. The narrative is the user-friendly version.
For an incremental release, ~3 screenshots is right. More creates visual noise relative to the prose. Aim for: one for each headline feature (showing what it looks like in the activity log), plus one for any meaningful UI change. Skip screenshots of micro-interactions (button states, tooltips) — they don't carry as stills.
Keep it brief: one paragraph. Installation instructions (it's an auto-update via the WordPress dashboard), an "open an issue if something looks off" link, and a "five-star review genuinely helps" ask. No upgrade-to-premium push in release posts — release posts are for current users on the version that just shipped.
Acknowledging honesty earns trust. Lines like "This one has bothered us for a while" or "We had a handful of triage reports that tracked back to exactly this" are the most human moments — keep them. Marketing-brochure language ("game-changing", "seamlessly integrated", "across the board") is the opposite — cut it.
# [Title - Promise a Benefit]
[Hook: 1-2 sentences on problem/opportunity]
## [Section Headings]
[Content with examples]
## Conclusion
[Summary + call-to-action]
Never set Claude as the post author. The author must be Pär (user ID 1).
"author": 1 in the request."author": 1. If the author is anyone other than Claude or Pär, leave it unchanged.How to design and regenerate marketing screenshots for the wordpress.org plugin page (banner-1544x500.png, screenshot-1.png, etc). Covers the event mix that converts, the reproducible WordPress Playground pipeline that bakes it, and every non-obvious gotcha from previous shoots. Use when refreshing screenshot-1.png, banners, or any image showing the Simple History event log.
Query Google Analytics (GA4) for simple-history.com traffic, top pages, referrers, and the premium_* UTM campaigns that tag admin links. Use when the user asks about visits, traffic sources, which admin links lead to the site, upsell click-through, or campaign performance.
Adds changelog entries to readme.txt following keepachangelog format. Use when updating the Unreleased section or documenting changes for a release.
Guidance for writing and running tests in Simple History. Covers which framework to use, how to run existing tests, and how to create new ones (including the codegen recording workflow).
Surface and triage local issues that are safe and quick for an AI to implement and easy for a human to verify. Use when the user wants to "knock out issues", asks for "quick wins", "low-hanging fruit", "what's easy to do right now", or wants a batch of small tasks to work through in one session.
Guides implementation of structured action links on log events. Use when adding get_action_links() to a logger or migrating from get_log_row_details_output().