| name | write-blog |
| description | Write and ship a blog post for the Parler Protocol website (web/) that reads like a human wrote it and pulls SEO traffic to the repo and hub. Use when a contributor wants to draft, edit, or publish a blog post, add a post to the site, write about Parler Protocol for search/traction, or make an existing draft sound less like AI. Enforces the house voice (no em dashes), picks a non-cannibalizing angle, wires the post into Next.js, and runs the humanizer pass before shipping. |
| license | Apache-2.0 |
| compatibility | claude-code |
| allowed-tools | ["Read","Write","Edit","Grep","Glob","Bash","AskUserQuestion"] |
Write a Parler Protocol blog post
You are helping a contributor write a blog post for the Parler Protocol website. The bar: it
reads like a person wrote it, it ranks for a search cluster no other post already owns,
and it ships wired correctly into the Next.js site with the build green.
This skill exists so every contributor writes in the same voice, picks non-overlapping
topics, and passes the same anti-AI-slop gate, whether or not they already know the house
rules.
The one rule that gets a post rejected
No em dashes (—) or en dashes (–). Ever. This repo is hand-styled and the house
voice bans them. Use a period, a comma, or "so"/"because"/parentheses instead. A single
dash in a draft is a hard fail. There is a scanner: run bash check.sh <file> (in this
skill's folder) on any draft before you call it done.
Workflow
Do these in order. Don't skip the angle check or the humanizer pass.
1. Read the ground truth first
Before writing a word, read what already exists so you match voice and don't cannibalize
keywords:
web/lib/blog.ts, the POSTS array. This is the live registry of every published
post and the angle it owns. Read every slug, title, dek, and tags.- One or two full posts in
docs/blog/*.md (the prose sources) to absorb the voice.
reference/angles.md (in this skill folder) for how to pick an angle that doesn't
collide, plus the topics still untapped.reference/voice.md for the house voice and the anti-AI checklist, self-contained.reference/craft.md for the writing craft: leads that win the click, spine structure,
and which creative-writing skill to reach for at each stage.reference/seo.md for on-page keyword placement, internal linking, verifying the
machine-readable SEO, and the post-ship distribution loop that earns the first backlinks.
2. Pick and pitch the angle
Every post must own a distinct search cluster. Two posts fighting for the same
keywords cannibalize each other. From POSTS and reference/angles.md, pick an angle no
shipped post already owns, then pitch it back to the contributor in one line before
drafting: the working title, the one-sentence thesis, and the 3-5 keyword phrases it
targets. Confirm before you write the body. If they gave you a topic that collides with an
existing post, say so and propose the adjacent-but-distinct angle instead.
3. Outline
A Parler Protocol post has a spine, not a listicle. Read reference/craft.md before you
outline; the lead and the H2-spine are 80% of whether the post gets finished and ranked.
Structure:
- A lead (dek + opening) that names a concrete, specific problem the reader has. Not
"AI agents are transforming collaboration." Something like "Two agents can talk about a
change all day. Handing over the change itself, byte for byte, is a different problem."
- 4-7 sections, each with a claim and real code, real commands, or a real number from
this repo backing it. Read the actual source (
crates/, web/, docs/) and quote it
accurately. Made-up APIs are worse than no code.
- A "what this is NOT" or honest-limitations beat. The voice is a little contrarian and
admits what's deferred. That honesty is what makes it not read like marketing.
- A close that lands the thesis without a generic "in conclusion, the future is bright"
wrap-up. End on a concrete thing the reader can do or check.
4. Draft
Write the prose in docs/blog/<slug>.md first (plain markdown, the repo's source of
truth). Follow reference/voice.md and reference/craft.md as you write, so there's less
to fix later. Keep it honest, concrete, and grounded in repo code. Vary sentence length.
Have an opinion. Run /direct-response-copy on the title, dek, and closing CTA (only those
three surfaces, not the body).
5. Humanize (mandatory)
Run the repo's humanizer on the draft: invoke /humanizer (committed at
.claude/commands/humanizer.md) on docs/blog/<slug>.md. If it isn't available, apply
the checklist in reference/voice.md yourself. Strip: significance inflation, promotional
adjectives, the rule of three, "-ing" tail analyses, negative parallelisms ("it's not X,
it's Y"), synonym cycling, hedging, and every dash. For headline/dek/CTA polish you may
also pull in /direct-response-copy.
Then run bash check.sh docs/blog/<slug>.md and fix anything it flags.
6. Wire it into the site
Follow reference/wiring.md exactly. In short: add the POSTS entry in web/lib/blog.ts,
create the body component web/components/blog/<slug>.tsx using the prose primitives from
components/blog/prose.tsx, and register slug to <Component /> in
web/app/blog/[slug]/page.tsx's BODIES map. Sitemap, RSS, OG/Twitter cards, and
JSON-LD auto-derive from POSTS, so there's no extra wiring. For keyword placement
(title/dek/first-H2/tags), internal-link count, and anchor-text rules, follow
reference/seo.md. Add a reciprocal inbound link from the most related existing post.
7. Verify before done
From web/:
npm run build # must be green
Then smoke it: next start and confirm the post page, the cover image, the /blog index,
/sitemap.xml, and /rss.xml all return 200 and the new slug appears. View source on the
post and confirm the meta description, OG/Twitter tags, and BlogPosting JSON-LD actually
emitted with the right values (reference/seo.md lists what to check). Re-run bash check.sh on the final markdown. Only then is the post itself done.
8. Distribute (this is what earns the traction)
A correct post with no inbound links does not rank. After it ships, seed the first signal:
run /x-tweet on the post's core insight for a thread that teaches the idea and links the
post, cross-link the post from the relevant docs/*.md, and answer the real question it
solves where people are already asking it. See the distribution loop in reference/seo.md.
Always link the production URL (www.parlerprotocol.com/blog/), never the fly.dev host.
Guardrails
- Never invent Parler Protocol APIs, flags, or numbers. Read the source and quote it.
- Never weaken the house voice to sound "professional." Concrete and a little contrarian
beats polished and generic every time.
- Don't ship a post whose angle overlaps a published one. Adjust the angle instead.
- Covers can be SVG served via a plain
<img>. On-brand palette: black #000,
electric-blue #3b9eff, violet #9281f7, green #3ecf8e, graphite hairlines. If you
can't make a good cover, reuse an existing one rather than shipping something ugly.
Note on this skill's own files
The scanner will flag SKILL.md and the reference/ files because they name the banned
characters (—) (–) and use → as teaching notation. That's expected. The scanner is
for blog drafts in docs/blog/ and the .tsx bodies, not for this skill's documentation.
