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

Aditya Singh — Sun, 25 Oct 2026 06:29:10 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

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.

Demo

claude.ai

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).

Code

its-adityasingh / Slothgram

Slothgram: ONE DEV ONE POST

Write once, adapt, and publish to developer communities. Publishing runs on Temporal, so every destination is a durable, retryable, independent job.

Project layout

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)

Why Temporal

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`.

…

View on GitHub

How I Built It

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:

exactly one variant per destination
each platform's character limits
the link is still present
hashtag counts are capped
a warning appears for any number that wasn't in the original post, so invented metrics get flagged

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:

Nothing sends until an explicit approval signal arrives. Scheduled posts then wait on a durable timer.
One destination failing never affects another.
Failures that never reached the platform retry with exponential backoff, up to 5 attempts.
Job IDs come from a hash of user, post, destination and content, so resubmitting the same content never starts a duplicate. Retry only re-runs destinations that actually failed.
If a request may have landed but the response was lost, the job moves to needs_review instead of being retried automatically.
Demo results are always marked simulated and carry no URL.

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

Done: Temporal workflows, demo adapter, Ollama module and CLI, DEV.to draft adapter.
Tested with mocked HTTP only: the DEV.to adapter and the Ollama module.
Not built yet: X, LinkedIn and GitHub adapters (they need official API access), the FastAPI layer, a database, authentication, and a settings screen.

Why Does Open Innovation Matter?

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.

Prize Categories

Best Use of Temporal

DEV Community: Aditya Singh