How to publish on the Btab blog

Every post on this blog lives in one place: our content CMS at content.btab.app. The blog page you are reading is rendered straight from it — publish a post there and it is live on btab.app/blog within a minute. This guide is for Btab staff: it walks through the two ways to get a post published, the writing rules of the house, and how to fix things when you change your mind.

The fast lane: publish from your phone

The quickest way to publish doesn't involve opening an editor at all. Our internal Command dashboard runs a content loop that does the heavy lifting:

1. Capture the idea. Write a short note in the Command dashboard — a paragraph about what the post should say, who it's for, and any links or facts that must be in it. Rough is fine; the point is the substance, not the polish.
2. Tag it for writing. Mark the note with the write action for the blog (#do/write/blog). That routes it to our writing agent, which drafts a full post grounded in your note and saves it to the CMS as a draft — nothing public yet.
3. Review from the card. A review card comes back to you with the draft attached and a private preview link. The preview renders exactly like the live blog, works without logging in, and expires after 7 days — safe to forward to a colleague for a second pair of eyes.
4. Approve it. Answer the publish question on the card. That's the whole gate: one affirmative answer flips the draft to published, and the post is live on btab.app/blog in under 60 seconds.

The same loop also runs in reverse order sometimes: when we ship a notable improvement, a draft post about it may be proposed automatically and arrive as a review card. Nothing auto-publishes — a human always approves.

The manual lane: write it yourself

Prefer to write directly? Log in to the CMS admin at content.btab.app and create a document in the Posts collection. The fields that matter:

• Title — the headline. Make it say what the reader gets, not what we did internally.
• Slug — the URL (btab.app/blog/your-slug). Lowercase, hyphenated, permanent — don't change it after publishing.
• Summary — one or two sentences. This is what shows on the blog index card and in link previews, so write it as the hook, not a description of the document.
• Content — the body, in plain Markdown. Headings, lists, links, bold, code blocks all work. Paste from a doc and clean up the formatting; don't paste HTML.
• Author — "The BTAB Team" unless there's a reason to byline an individual.
• Category and tags — optional, used for grouping on the index.
• Hero image — every post gets one, and ours follow a house recipe so the index reads as one brand: a 2:1 panel, one flat lime tint from the Btab palette, one hand-drawn black line drawing — one idea per post — and no text baked into the image. Upload the rendered cover to the media library, fill in its alt text (that's what screen readers and search engines get), and link it. The recipe, the tint rotation, and the drawing masters live in the platform repo under docs/operations/blog-cover-art.md — start from an existing cover rather than freestyling a new style.

Save as draft first, preview, then hit Publish when it reads right. The CMS keeps versions of every save and locks a document while someone else is editing it, so you can't trample a colleague's work.

House rules

• Draft first, always. Nothing goes from blank page to public in one step. Drafts are invisible to the outside world — take your time in them.
• Write for the reader on the other side. Our readers are vendors, suppliers, and partners. Lead with what changes for them; keep internal system names and process trivia out of the body.
• Summaries are not optional. A post with a weak summary gets skipped on the index no matter how good the body is.
• Product descriptions don't belong here. Store and product content has its own workflow — the blog is for announcements, guides, and stories.
• Facts get checked. If a post states a number, a price, or a behaviour, verify it against the live product before publishing, not after.
• No post ships without its cover. Cover art is part of drafting, not a decoration added later — a draft isn't ready for review until its cover and the cover's alt text are attached.

When you change your mind

Publishing is not a one-way door. Any post can be flipped back to draft from the admin — it disappears from the blog on the next refresh, history intact, no deletion needed. Fix it, republish, done. If a published post has a real error, unpublish first and edit second; a wrong post that's live is worse than a gap on the index.

That's the whole system: one store, two lanes in, one gate, and a painless undo. Write something.