PatchPitch：程式碼完成後，四則公告仍待撰寫

You finish the update. Then you open Telegram, X, DEV and GitHub, and discover that you have four more things to write.

The facts haven't changed. The readers have. Telegram wants the update without a long introduction. X gives you one small patch of screen. DEV needs a reason to keep reading. GitHub needs the concrete details someone will look for later.

That's the gap I'm building PatchPitch for: keep the facts in one place, then prepare drafts for each audience. For 0.3.0, currently in development, I wanted the whole job to run from the command line. A writing tool that needs someone to babysit a browser leaves a rather large hole in the automation.

The result: four local drafts in 123.258 seconds, using five requests to a local Ollama model. Here's a 42-second recording of the saved results being reviewed in the studio:

Watch the 42-second demo with sound and subtitles

Direct MP4 download

I made PatchPitch write about PatchPitch

The test material was its own development update. I supplied selected facts, asked for four formats, and ran the CLI with stdin closed. No browser, no PatchPitch web server, no clicking Generate four times. Ollama was already running locally with gemma4:12b installed.

The successful campaign produced this:

X used two requests: one to plan the post, another to write it after tag selection. Each other format used one. The 123.258 seconds includes the CLI's overhead; these are timings from this run on this Windows machine.

Here's the reusable example command, run from a prepared checkout containing the 0.3.0 development code:

python -m patchpitch run --job examples/headless/all-four.toml --out-root artifacts/campaigns --json

About two minutes later, I had four drafts to read instead of four blank editors.

The first X draft missed by seventeen characters

Before that successful run, PatchPitch rejected an X response with X_LENGTH_EXCEEDED. The app estimated the complete post at 297 characters against its 280-character budget. Telegram, DEV and GitHub still finished, and the rejected X response stayed on disk.

I had given the model a general 150–200-character prose target alongside a smaller allowance that reserved space for six hashtags and a link. The wider instruction was an invitation to overflow. I removed it and added a prose ceiling to the output schema, keeping the final check on the assembled post.

I also revised the tag catalog between runs. A generic mention of Python had helped select #PythonDevelopment; I narrowed that match to actual Python development topics. The revised selection included #Automation, a closer description of this announcement.

The lesson was pleasantly concrete: reserve the tags and link first, give the model the remaining prose budget, then check the whole message. The saved responses made it possible to see where the space went.

Same facts, different jobs

Here are excerpts from the saved files after editing. The X post is shown in full:

PatchPitch 0.3.0 dev: an open-source Python CLI tool that automates drafts from JSON/TOML jobs with local Ollama. No browser or web server needed.

#DevTools #LocalAI #LLM #Ollama #OpenSource #Automation

https://github.com/drevendev/PatchPitch

Those six tags describe the subject: developer tools, local AI, language models, Ollama, open source and automation. PatchPitch selected them from a reviewed catalog of eleven candidates, backed by nineteen linked posts from fifteen authors. That gives me examples of usage and a reason for each choice; reach isn't something this sample measured.

The Telegram draft opens directly in Russian:

Я добавил в PatchPitch возможность автоматически генерировать черновики для Telegram, DEV и GitHub на основе выбранных фактов разработки.

In English: “I added the ability to automatically generate drafts for Telegram, DEV and GitHub from selected development facts.” The rest of the saved post explains the local CLI workflow and includes the command.

The GitHub notes take a more functional approach:

The development implementation provides a non-interactive CLI to automate draft generation from JSON or TOML jobs. This workflow utilizes the existing local Ollama model backend and functions without starting a browser or HTTP server. An installed local model is required for operation.

That gives a repository reader the mechanics and a prerequisite. It's also fairly stiff prose. The openings still leaned heavily on the same CLI facts; the formats worked, but their hooks needed more attention. The DEV draft made that especially obvious.

Giving the DEV draft a story

The first DEV version read like a README: plenty about how the pieces fit, very little about why a developer would care. I gave Quillgrain a more specific editorial profile: start with the four-announcement problem, tell the actual experiment, keep the failed X attempt, and show the outputs. Short paragraphs and concrete verbs were part of the brief, too.

Quillgrain compiled that profile into writing context. PatchPitch sent it alongside the selected facts to the local model for a fresh DEV generation. The response still opened with this:

We've all been there: you finally push a significant update, the code is clean, and the tests pass, but then you're faced with the friction of explaining that change in four different places.

That could introduce almost any developer tool. During editing, I replaced it with the opening of this article:

You finish the update. Then you open Telegram, X, DEV and GitHub, and discover that you have four more things to write.

I also pulled the real failure, timings and saved examples into the story. Quillgrain made the brief explicit and available to the generation step; the editorial pass decided which details deserved the reader's attention. Both are part of how this version was made.

Four drafts I could come back to

One part of the experiment was pleasantly uneventful: running it again.

In a separate reuse check, I repeated the completed job and invoked resume with network connections blocked. Both reused the saved work with zero connection attempts. The original responses and edited publication files stayed intact.

The CLI session could then be opened in the studio to read, edit and export. That's the review shown in the screenshots and recordings: switching between saved drafts doesn't need another model request.

The useful part is opening four concrete drafts with the facts already in place. I can spend the next edit on the hook, the awkward sentence or the example that makes the update worth reading. Those are much better problems to have than four empty text boxes.

PatchPitch on GitHub