RonanCodes/write-blog-post

Write Blog Post

Write a blog post or article quickly, grounded in real code, in the author's own voice rather than the generic AI voice everyone can now smell. The method is Nicolas Torres's: have a conversation about what you want to say, pass the actual repos so the claims are real, draft and iterate, read it back with the eyes of "is this bullshit or do I actually understand what I'm conveying", tweak, add pictures, ship. Optionally clone the author's voice in ElevenLabs for an audio version.

This is faster than writing by hand. The whole point is that it stays fast without sounding like a machine wrote it.

The workflow

1. Conversational intake (not a one-shot prompt)

Open a real back-and-forth. Do not ask the author for a finished brief and then run. Ask, listen, ask again. Pull out:

• What they want to talk about — the actual topic and the angle. The thing they keep wanting to say to people.
• Context of the codebase / repos — which repo(s), which parts, what they built, what's interesting about it. Get paths or URLs.
• Their ideas and what they've been thinking about — the half-formed takes, the opinion underneath, the thing that made them want to write this at all. This is the spine of the piece.
• Audience and where it's going — dev.to, LinkedIn, personal blog, X thread. The voice holds but the shape shifts per platform.
• Length and depth — a quick 600-word note, or a 2000-word deep-dive.

Ask 3 to 6 clarifying questions before drafting. If the author is vague on the angle, that's the most important thing to nail down: a post with a clear opinion writes itself; a post that just "covers a topic" reads like AI filler. Use AskUserQuestion for the decisions (angle, audience, length).

2. Ground it in reality ("pass a few repos")

Before drafting, go read. Claims must be real, not invented.

• Read the actual repo(s): README, CLAUDE.md/CONTEXT.md, the relevant source files, recent git log, design docs. If the author named a directory, read it.
• Pull real numbers, real file names, real function names, the real bug they hit. Specifics are what separate a grounded post from a generic one.
• If the post makes a claim about a tool, framework, or fact the author can't vouch for from memory, do a quick web search to confirm it rather than asserting it. Cite where it matters.
• Note anything you can't verify. You'll flag it in the draft so the author decides, rather than inventing a detail to make a sentence flow.

3. Draft in the AUTHOR's voice

This is the heart of it. A draft in generic AI voice has failed even if every fact is right.

• Load /ro:write-copy first and obey it. It's the anti-AI-tell bible (see the dedicated section below).
• If a voice profile exists for the author, load it. Check vaults/llm-wiki-voice/scratchpad/voice-profile-state.json and the compiled voice-profile.md (run /ro:voice-profile path to get the canonical paths, /ro:voice-profile show to read it). The profile captures the author's refusals and habits: openers they'd never use, words they overuse or ban, sentence rhythm, contrarian takes. Draft to it.
• If no profile exists, mirror the author's voice from how they talked in the intake conversation (step 1) and from any of their existing posts you can read. Match sentence length, how blunt they are, whether they swear, whether they use first person.
• Write the draft top to bottom. Then iterate over it with the author in chat, the same way Nicolas did: draft, react, tweak, draft again. Two or three passes beats one long prompt.

4. Generate images / graphics

A post with one real diagram or image lands harder than a wall of text.

• Use the generate-image skill (the plugin's skills/generate-image/SKILL.md) for hero images, illustrations, and social cards.
• For anything that's a flow, an architecture, or a before/after, prefer a mermaid diagram drawn from the real structure you read in step 2 over a decorative stock image.
• Place images where they earn their spot: next to the thing they explain, not as filler at the top.

5. Tweak + the BS-check pass (do not skip)

Read the whole thing back with one question in your head, the way Nicolas does it:

Is this bullshit, or do I actually understand and convey what I mean?

Go line by line:

• Cut anything you can't stand behind. If a sentence sounds good but you couldn't defend it to a smart reader, delete it.
• Cut anything that's true but adds nothing. Padding reads as AI even when it's accurate.
• Run the anti-AI-voice sweep from the section below. Every hit is a candidate for deletion.
• Check every claim traces to step 2. If it doesn't, either verify it or cut it.

This pass is where the post stops sounding generated. It's the most important step. Treat it as mandatory, not optional polish.

6. ElevenLabs voice-clone audio version (optional, built-in)

An audio version of the finished post in the author's own cloned voice.

• The text-to-speech call is documented in the plugin's skills/tts-elevenlabs/SKILL.md (text → mp3 via the ElevenLabs API). Reads ELEVENLABS_API_KEY from ~/.claude/.env.
• A voice clone needs the author's own voice samples uploaded to ElevenLabs first. Once cloned, ElevenLabs gives you a voice ID. Store it as ELEVENLABS_VOICE_ID_RONAN (per author) in ~/.claude/.env and pass it as --voice "$ELEVENLABS_VOICE_ID_RONAN".
• If no clone exists yet: tell the author to create one at https://elevenlabs.io/app/voice-lab (Instant Voice Clone needs ~1 minute of clean audio; Professional Voice Clone wants ~30 minutes for higher fidelity). Then save the returned voice ID to the env var. Until then, fall back to a stock voice so the step still runs.
• Strip markdown before sending so the audio reads clean (the tts-elevenlabs skill already does this with --file).

/ro:tts-elevenlabs --file path/to/post.md --voice "$ELEVENLABS_VOICE_ID_RONAN" --output path/to/post.mp3
open path/to/post.mp3

Anti-AI-voice rules (load-bearing)

The single thing that makes this skill worth using is that the output does not sound AI-generated. /ro:write-copy is a hard dependency. The bans, applied here:

• No em-dashes or en-dashes. Ever. Not —, not –. Use a comma, a colon, a full stop, or parentheses for the real intent. Do not substitute a plain hyphen as punctuation.
• No AI-tell vocabulary: delve, leverage, robust, seamless, tapestry, landscape, elevate, empower, unlock, streamline (as filler), crucial, essential, testament, game-changer, paradigm.
• No rhetorical reversals: "not only X but also Y", "it's not just X, it's Y", "more than just a tool, it's a...". State Y directly.
• No gratuitous tricolons. Three parallel items when one or two would do is a tell.

Nicolas's specific tells to kill

Beyond the general bans, watch for the punchy-fragment-listicle voice that screams AI blog post:

• The "Here's the thing…" opener. Also "Here's the kicker", "Here's what nobody tells you", "Let me explain". Delete the throat-clear, start with the actual point.
• The "N people, M ideas, 1 weekend" cadence. The staccato number-fragment line ("10 people. 5 ideas. 1 weekend.", "No meetings. No managers. Just code."). It's the most overused punchy-listicle rhythm in AI prose. Write the real sentence instead.
• One-line paragraphs stacked for fake drama. A real argument has connected sentences, not a column of dramatic single lines.
• The rhetorical question into a one-word answer. "Does it scale? Yes." as a paragraph. Cut.

The sweep

Run this over the draft (part of the step 5 BS-check). Every hit is a candidate for the knife:

rg -niE '—|–|\bdelve\b|\bleverage\b|\brobust\b|\bseamless\b|\btapestry\b|\blandscape\b|\belevate\b|\bempower\b|\bunlock\b|\bstreamline\b|here'\''s the thing|here'\''s the kicker|here'\''s what nobody|not only .* but also|it'\''s not just' path/to/post.md

Dependencies and further reading

• /ro:write-copy (the plugin's skills/write-copy/SKILL.md) — the anti-AI-tell rules. Hard dependency; load it before drafting.
• /ro:voice-profile (the plugin's skills/voice-profile/SKILL.md) — the portable voice profile. Load the author's compiled voice-profile.md to draft in their voice. State lives at vaults/llm-wiki-voice/scratchpad/voice-profile-state.json.
• generate-image (the plugin's skills/generate-image/SKILL.md) — images and graphics for the post.
• /ro:tts-elevenlabs (the plugin's skills/tts-elevenlabs/SKILL.md) — text → mp3 for the audio version. Voice clone created at elevenlabs.io/app/voice-lab; voice ID stored as ELEVENLABS_VOICE_ID_RONAN.
• Source of the method: Nicolas Torres's blog-writing workflow. Research, pass a few repos, draft, iterate, read with the "is this bullshit?" eyes, tweak, add pictures, send. Voice cloned in ElevenLabs.

Pre-publish checklist

Walk this before the author hits send.

• [ ] Grounded in real code — every technical claim traces to a repo, a file, a commit, or a verified source you read in step 2. Nothing invented.
• [ ] Voice-matched — drafted against the author's voice profile (or their real voice from the intake), not generic AI voice. Reads like the author wrote it.
• [ ] No AI-tells — the rg sweep is clean: no em/en-dashes, no AI vocabulary, no "Here's the thing", no "N people, M ideas, 1 weekend" cadence, no rhetorical reversals.
• [ ] BS-check done — read back line by line; everything that couldn't be defended to a smart reader is cut.
• [ ] Images added — at least one real image or mermaid diagram, placed where it explains something, not as filler.
• [ ] Audio (optional) — ElevenLabs voice-clone mp3 generated if the author wants it; voice ID set, markdown stripped.
• [ ] Shaped for its destination — length and structure fit the platform (dev.to / LinkedIn / personal blog / X).