· Ben · launch · 4 min

Introducing Contentcron

An AI writer that lives in your repo. It learns your voice from your site, writes an article a day, ships each one as a PR, and illustrates them with real screenshots of your product and figures that cite their sources.

If you're running a startup, you already know the blog problem. Everyone agrees content compounds. Nobody on the team actually owns it. The last post is from four months ago and it's the one announcing your seed round.

Contentcron is my answer to that. It's an AI writer for blogs that live in a git repo. It learns your voice from your website, researches topics with real web search, writes about an article a day, and opens every one as a pull request. You comment on the PR, it revises. The articles come with real screenshots of your product and charts that cite their sources, because a wall of text convinces nobody.

That's the pitch. Here's what it actually means in practice.

It reads your site, not a brand questionnaire

You know those onboarding forms that ask you to describe your "brand personality" in three adjectives? We don't do that. You connect a repo and give us your URL. Contentcron crawls your marketing pages for company facts and your existing posts for style, then writes a brand profile: how you sound, what you can claim, which words you'd never use. It's a document you can read and edit, not a black box, and every article gets prompted with it.

Same deal on the repo side. It reads a few of your posts and picks up your frontmatter conventions, your date format, how you slug titles. If your posts have description and tags, its posts will too. Your linter shouldn't be able to tell who wrote the commit.

Topics come with receipts

Once a week, or whenever you ask, it researches your niche with live web search. What competitors cover, what your archive already says, where the gaps are. It proposes about ten topics, each with a rationale, not just a headline. You approve the good ones, kill the rest, add your own. Only approved topics become articles, on whatever cadence you set.

There is no "generate 50 posts" button and there never will be. One decent article a day, compounding, is the whole bet.

The PR is the workspace

When a topic is due, the pipeline runs: deep research, an outline with internal links to your existing posts, then the full MDX. It commits to a branch named contentcron/<slug> and opens a PR that explains what the article covers and why the topic was worth writing.

This is the part I care most about. The PR isn't a notification, it's where the work happens. Leave a comment, general or on a specific line, and Contentcron reads the whole thread, rewrites the article, pushes to the same branch, and replies with what changed. A few comments landing at once get batched into one coherent revision instead of three fighting each other. If a comment is meant for humans only, prefix it with !cc-ignore and the bot stays out of it.

And because nobody sane turns on autopilot day one, publishing mode is per project. Draft-first means articles wait in the app until you approve them. Auto-PR is the default: everything arrives as a PR and waits for review. Direct push is there once the drafts have earned it. Most teams start cautious and dial up.

Real screenshots of your actual product

Every AI content tool I've tried illustrates posts with stock photos or AI art, and you can smell it instantly. So we built the thing I actually wanted: screenshots of your real product, kept fresh automatically.

You give it demo credentials once (stored encrypted, only the capture worker touches them). It logs into your app, walks the nav, and proposes a library of pages worth showing, named and tagged by feature. From then on the library maintains itself. Shots get re-captured on a schedule and pixel-diffed against the previous version, so a shot only updates when the UI actually changed. Each one lives at a stable URL, which means when you ship a redesign, every article you've ever published shows the new UI without anyone touching a thing.

The writer sees the whole library when it drafts and drops in whatever fits the topic. If an article needs a page that isn't in the library yet, it files a request mid-draft, the worker captures it, and the article gets revised to include it. You never take a screenshot by hand.

Figures that cite their sources, or don't exist

Charts are where AI content goes to lie. Our fix is blunt: a figure that can't cite a source gets rejected. Not flagged, rejected.

There are three kinds. Charts, clean SVG bars and lines with the source printed inside the image. Diagrams, rendered from Mermaid, for architecture and flows. And stat callouts, which are just a sourced number quoted as text, because a single stat doesn't need to be a picture. Each one comes from a research pass with real web search, and the researcher is allowed to come back empty-handed. It returns nothing before it returns a made-up number.

Figures render in your palette, pulled from your site, so they look like yours and not like a template. You can seed the library with suggested figures for your niche and approve the ones worth researching, create your own, or let the writer request them the same way it requests screenshots.

Editing is a conversation

Besides PR comments, every article has a chat in the app, and it's not a chatbot bolted on for the demo. It has actual tools: it revises the article, checks the revision history, requests a new screenshot or figure and embeds it once it's ready, and suggests internal links to your other posts. The recurring asks are one-click chips: remove AI tells, tighten, simplify, vary the rhythm. The tenth "make this sound less like an LLM" shouldn't cost you a paragraph of instructions.

What it's not

Topic and figure research is Claude with live web search, not a keyword-volume database. I think that trade favors substance, but if your content strategy runs on search-volume spreadsheets, we're not your tool. There's no AI image generation on purpose: if a visual can't be a real screenshot, a sourced chart, or a diagram, the article does without. And it writes MDX or Markdown for blogs in git repos. If your blog lives in a CMS, we're not there yet.

Under the hood it's a GitHub App with narrow permissions, repo contents and pull requests, nothing else. The same setup I'd want from any vendor touching my repos.

If your blog is a folder of markdown and publishing has quietly become the thing nobody owns, this is for you. Your first article is free, no card required. Connect a repo and see what tomorrow's PR looks like.