| name | write-news-article |
| description | Drafts a Stackable release news article and the matching readme.txt News Article Updates link. Use when the user asks to write a news article, release blog post, News Article Update, or invokes write-news-article. |
| disable-model-invocation | true |
Write News Article
Draft a major.minor feature-release blog post for wpstackable.com, plus the readme.txt News Article Updates bullet. Benjamin edits voice and accuracy before publish.
This is not the changelog. For changelog bullets, use add-changelog.
Project context (do not hardcode)
Do not embed repo URLs, org names, or project board links in assumptions.
Read the current project's Cursor rules (e.g. .cursor/rules/ for repos / release roadmap). Use those for roadmap lookup. If missing, ask before guessing.
When to write
| Write | Skip |
|---|
Meaningful x.y.0 with a user-facing workflow story | Patch releases (x.y.z) |
| Pure maintenance / no headline workflow change |
Goals (priority order)
- Teach — skimmable guided overview (where it lives, happy path)
- Market — make updating feel worthwhile
- Document — durable product-story breadcrumb
Audience: builders and agencies using or evaluating Stackable. Free-first; Premium only when it is part of the story.
Workflow
Copy and track:
Write News Article:
- [ ] 1. Resolve proposed version
- [ ] 2. Confirm version with user (wait for reply / override)
- [ ] 3. Confirm this release deserves an article
- [ ] 4. Gather sources (changelog + roadmap)
- [ ] 5. Pick 1–3 headlines; park the rest
- [ ] 6. Draft article as WP block markup (paste-ready)
- [ ] 7. Draft readme.txt News Article Updates bullet
- [ ] 8. Hand off for Ben edit (do not publish)
1. Resolve proposed version
Same sources as add-changelog:
- Prefer
Version: in root plugin.php
- Else main plugin bootstrap PHP
- Optionally note
Stable tag: in readme.txt
Propose the major.minor feature version (e.g. 3.20.0 → article for 3.20), not a patch.
2. Confirm version with user (required)
Stop and ask before drafting.
Tell the user the proposed version. Wait for confirm or override. That value is VERSION (use MAJOR.MINOR in titles/links, e.g. 3.20).
3. Confirm the release deserves an article
If the changelog/roadmap has no clear user-facing workflow story, say so and ask whether to skip. Do not invent a news post for a maintenance minor.
4. Gather sources
From project Cursor rules, open the Release Roadmap for VERSION. Also read the = VERSION = (and related patch) changelog section in readme.txt.
Pull:
- Candidate headline features (
New: / major Change:)
- User-visible removals, renames, sunsets, BC-relevant items
- Premium-only bits tied to headlines
- Adjacent product payoffs that make a headline better (e.g. an existing UI that now works on the new feature)
Skip internal chores and fix spam unless users would notice or worry.
5. Pick headlines
Cap at 1–3 headline features that share one workflow story.
- Everything else either goes in a short Other Improvements list or is omitted
- Prefer cutting a fourth headline into “Other” over lengthening the article
- Continue the Design System / efficiency arc only when true — one linking sentence if related; never force it
6. Draft the article
Voice: warm founder walkthrough — clear and helpful, lightly first-person where it earns it (“I wanted…”, “tell me…”). Skimmable — aim for a 3–5 minute read. Prefer concrete UI steps over slangy asides.
Required skeleton
- Title (hand-off only — not in body markup) —
Introducing … naming user-facing capabilities (commas / “and” for multiples). WP post title is the H1; do not put an H1 in the body.
- Opening teaser — one short paragraph: version (
vMAJOR.MINOR.0) + gap closed / why it matters + optional one-sentence product-arc link to prior posts
- More block — immediately after the teaser (excerpt cut)
- Rundown — “Here’s what’s new:” + bullet list of the 1–3 headlines
- H2 per headline — what it is → where to click / happy path → why it matters → teaching visual. Include adjacent payoffs when true (how it plays with an existing control), not feature-vs-feature digressions
- Conclusion — update CTA + soft feedback invite (no “— Ben” sign-off)
Optional sections (include only when earned)
| Section | When |
|---|
| Old way vs new way | Real workflow shift only — skip for net-new UI |
| Backward compatibility / enable paths | Upgrader defaults differ, or something is removed/sunset — be specific (settings paths) |
| Other Improvements | User-visible trust items only (removals, renames, sunsets, notable fixes) — not a changelog dump |
| Changelog link | When “Other” exists or the release is large — always href="/changelog/" (site-relative on wpstackable.com) |
| Premium callout | Inline at the moment it appears; separate H2 only if Premium is the headline |
| Product-arc link | One sentence in the teaser when this release continues a prior chapter |
Media
At least one teaching visual per headline. In the paste markup, use empty wp:image figures with a useful alt and a figcaption that starts with What to notice: … Ben drops screenshots in after paste.
CTA rules
- Always: update to the version + soft feedback / community invite
- Premium upsell only if Premium was a real part of the story
Draft output (required form)
Always deliver the article body as Gutenberg block markup ready to paste into the WordPress block editor Code editor. Not markdown. Not a “preview then convert” step.
Use a fenced html code block so Ben can copy once. Match this shape:
<p>…teaser with <strong>vMAJOR.MINOR.0</strong>…</p>
<p>Here’s what’s new:</p>
<ul class="wp-block-list">
<li><strong>Headline</strong> — short benefit</li>
</ul>
<h2 class="wp-block-heading">Headline</h2>
<p>…</p>
<figure class="wp-block-image"><img =/>What to notice: …
Compact list markup (list-item comments inside the ul/ol) is fine — matches what the block editor emits.
Above or beside the paste block, still state title + slug for the hand-off (those are not inside the body).
Do not publish to the blog or commit unless the user asks.
7. Draft the readme.txt bullet
Under ### News Article Updates, newest first:
- [vMAJOR.MINOR Feature Names…](https://wpstackable.com/blog/SLUG/?utm_source=wp-repo&utm_campaign=readme&utm_medium=link)
Rules:
vMAJOR.MINOR only (no patch)- Link text ≈ headline features (can be shorter than the full title)
- Slug usually
introducing-… kebab-case matching the title
- Always append the UTM query string above
- Add when the article goes live / in the same release PR — same day as the plugin release
If editing readme.txt in this session, insert the bullet at the top of the News Article Updates list. If the live URL is not final yet, draft the bullet and ask Ben to confirm the slug before writing.
8. Hand off
Summarize for Ben:
- Proposed title + slug
- Paste-ready body already in Gutenberg markup (with More block)
- The 1–3 headlines chosen (and what was demoted/omitted)
- Whether BC / Other / Premium sections were included and why
- Reminder: he edits voice/accuracy; publish same day as release; then ensure the readme bullet is live
Style quick reference
| Do | Avoid |
|---|
Paste-ready wp:* block markup | Markdown drafts Ben must re-paste |
| Tight teaser → More → rundown | Long excited preamble before the cut |
| Short paragraphs, concrete UI steps | Deep tutorials / exhaustive option lists |
| Workflow + adjacent product payoffs | Feature-vs-feature digressions |
| Warm, clear founder tone | Slangy asides (“yeah. Same.”) |
Changelog link /changelog/ | wordpress.org plugin changelog URL |
| Body without H1 / without “— Ben” | Duplicating the post title or signed sign-off |
| Honest removals and BC | Hiding sunsets |
| Concrete counts when real (e.g. 375 designs) | Invented metrics |
| Free-first, Premium inline | Bolted-on Premium sections |
Quality checklist
