too lazy to post too obsessed with building so built slothgram, one Dev one Psot🦥

A developer built Slothgram, an open-source tool that takes a single update and generates editable, per-destination versions for X, LinkedIn, DEV.to and GitHub, then publishes each as an independent job. The backend runs an open-weight model locally via an Ollama-compatible server (default qwen2.5:7b-instruct) with JSON-schema-constrained output, while deterministic code validates results and the AI module holds no publishing credentials. Publishing is orchestrated on Temporal, giving each destination its own durable, retryable workflow with an approval signal, scheduled timers, backoff retries and idempotency keys; the project ships with 24 passing tests.

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady https://dev.to/challenges/hacktoberfest-week3-2026-10-19 Slothgram: ONE DEV ONE POST. You ship something, then open four tabs, rewrite the same update four times, pick hashtags, and publish one platform at a time. Slothgram turns that into one step: write the update once, get a separate version for each destination X, LinkedIn, DEV.to, GitHub , edit each version, and publish them as independent jobs. It's for developers, students and open-source contributors who would rather build than post. The "lazy" part is deliberate. You get less repetitive writing, but you still approve every post before it goes anywhere. The demo runs in your browser in a clearly labeled demo mode . You can write a post, choose destinations, get an editable version per destination with character-limit checks, confirm, and watch simulated publishing, including a failed destination you can retry without touching the ones that succeeded. Nothing is really published, and the page never claims otherwise. The connection indicators are all red because no real platform is connected. The browser demo adapts text with simple rules. The open-weight model step lives in the backend see below . Write once, adapt, and publish to developer communities. Publishing runs on Temporal , so every destination is a durable, retryable, independent job. slothgram/ frontend/index.html landing page + browser demo open it in a browser, no build step backend/slothgram/ ai.py, workflows.py, activities.py, adapters.py, client.py, worker.py, cli.py backend/tests/ 24 tests docker-compose.yml local Temporal server .env.example, LICENSE MIT | Requirement | How it is done | |---|---| | One job per destination | One PublishDestinationWorkflow per destination. One failure never touches another. | | User must approve first | Workflow waits for the approve signal 7 day timeout, then canceled . | | Schedule after confirmation | After approval, a durable timer waits until scheduled at . cancel interrupts it. | | Retries with backoff | Activity RetryPolicy : 2s start, x2, max 2 min, 5 attempts. Rate limits use next retry delay . | | No duplicate posts | Idempotency key = hash user, post, destination, content . Workflow ID is derived from it with REJECT DUPLICATE . | Open-weight AI local inference . The backend sends the post to a model running on your own machine through an Ollama-compatible server. The default is qwen2.5:7b-instruct , and you can switch to another instruct model such as gemma3:4b by changing one setting. The model returns JSON-schema-constrained output: a variant per destination with title, text, hashtags, link handling, an explanation and warnings. The model only proposes text. Deterministic code checks everything it returns: The post is sent as delimited untrusted data, so instructions hidden inside it are not followed. The AI module has no publishing credentials and no way to publish. If the server is down or the model isn't installed, you get the exact fix for example ollama pull qwen2.5:7b-instruct . Malformed output is retried once, then fails with a clear message. Reliable publishing with Temporal. Each destination is its own durable workflow: needs review instead of being retried automatically. There's also a DEV.to adapter that creates drafts through the official API. Stack: Python, Temporal, httpx, Pydantic. 24 tests pass, with the workflow tests running against a local Temporal dev server. Honest status A tool that reads your unpublished work and writes in your voice shouldn't have to send that text to someone else's server. With an open-weight model on local inference, your drafts stay on your machine, you can swap models without rewriting the app, and there's no account or per-token bill. A closed API would have made the privacy story a promise instead of a design. Temporal being open source also means the publishing engine can be self-hosted and inspected, which matters for software that holds API keys and posts on your behalf.