The single biggest reason developer blogs go quiet isn't a lack of things to say — it's that publishing means leaving the tools you already have open. A CMS login, a rich-text editor, a manual image upload. Every extra step is a reason the draft sits unfinished. The fix is keeping the entire loop — write, review, publish — inside the terminal and editor you're already using for everything else.
This is what that workflow looks like with the Blogizi CLI, end to end. If you haven't picked a platform yet, best developer blogging platforms covers the broader landscape first.
Set up once
npm install -g blogizi
Then authenticate with the API key from your project settings on blogizi.com:
blogizi auth <api-key>
That's the entire one-time setup. No repo scaffolding, no build tooling, no theme to configure.
Writing a post directly
If you already know what you want to write, write the Markdown file yourself — following the frontmatter template covered in the developer blogging guide — and publish it directly:
blogizi publish ./blogizi-posts/how-i-debugged-a-postgres-deadlock.md
The CLI reads the frontmatter, recalculates word count and reading time from the actual content, and pushes it live. This is the same workflow as writing in any Markdown editor — the CLI is just the publish step, with no CMS in between.
Letting an AI coding agent draft from your own work
The CLI itself is deliberately thin — auth, use, draft <file>, publish <file>. It reads a Markdown file and sends it to Blogizi; it doesn't generate anything on its own. The AI-assisted part of the workflow comes from installing the Blogizi skill into a coding agent you already use:
npx skills add bytemindlab/blogizi-agent
With the skill installed, ask your agent to write a post about something you shipped. It reads the same codebase, commits, and architecture it already has open, and writes a Markdown file with proper frontmatter grounded in what you actually built — not a blank prompt, and not content generated by the CLI itself. The CLI's only job is still draft and publish:
blogizi draft ./posts/how-i-debugged-a-postgres-deadlock.md
That saves it as a draft in your dashboard, reviewable before anything goes live. Edit the file — by hand or by asking the agent to revise it — and re-run blogizi draft on the same file as many times as you want.
Choosing what to write about
There's no built-in "suggest a topic" command — that judgment call is better made by you or the agent looking at what you actually shipped recently than by a fixed heuristic. See how to write technical blog posts for the formats that reliably turn into good posts: a postmortem, a tool comparison, or a build walkthrough. If the Blogizi skill is installed, just asking your agent "what would make a good post from what we did this week" tends to work, since it already has your commit history and codebase in context.
Why this loop holds up over time
Every step above happens in the same terminal and editor you already use for code — no separate login, no context switch to a browser tab, no rich-text editor fighting your formatting. The technical SEO work covered in the technical SEO checklist — sitemap, OG images, canonical URLs — happens automatically on publish, so the only manual work left is deciding what to write and reviewing the draft before it goes live.
That's the actual test of whether a blogging workflow survives past the first few posts: not whether the tooling is impressive, but whether writing the fifth post takes as little friction as the first one did.