How I automated my content distribution with a DSH plugin I scaffolded myself

A developer built a DSH plugin called dsh-crosspost to automate cross-posting markdown articles to platforms like Dev.to and GitHub, and published a scaffolding tool, create-dsh-content, to generate similar plugins. The tool handles authentication, rate limits, and error reporting, and the developer highlighted pitfalls such as stale npm dist-tags and the need for pure ESM modules.

Posting is easy. Posting everywhere, consistently, is the hard part. I wanted a single command that takes one markdown article and pushes it to Dev.to, GitHub as a gist , and eventually Bluesky and Mastodon — without my ever touching those web editors again. So I built it as a plugin for DSH DeepSeek Harness , using a scaffolding tool that I published myself. Here's the story, the 3 pitfalls that cost me the most time, and how you can get the same thing running in about a minute. Writing in public is the cheapest compounding asset a developer has. But cross-posting manually has two failure modes: A plugin that accepts content + title + platforms and returns per-platform status + links removes both. One source, many destinations, audited every time. A DSH content-automation plugin dsh-crosspost with: auth / rate-limit / bad-request instead of a raw stack trace, so an agent can decide to retry or skip per platform. latest dist-tag the big one npm install @deepseek-ai/dsh-tools gives you a stale 0.0.1-rc.1 — the real line lives under the next tag. Wasted an evening debugging failures that were purely "wrong version resolved." Lesson: check dist-tags before installing anything in a fast-moving young ecosystem npm view pkg dist-tags . The plugin must be pure ESM "type": "module" , built with module: esnext + moduleResolution: bundler . Half my build errors were me fighting CJS habits require , module.exports at the boundary. Deps aren't installed via npm in the profile directory — the profile loader resolves bundle name s through node modules /profile store. Unlearning "relative path == works" was harder than the API calls themselves. Instead of hand-writing the plugin skeleton, I packaged everything I learned into create-dsh-content — a scaffold that generates a working, verifying content plugin in one command, then runs --verify type-check + loader dry-run until it's green.What it bakes in: version pins no stale-tag trap , pure-ESM tsconfig, the cordis patch wiring, BYOK credential plumbing, and a generate → verify → install → publish loop you can dogfood. The final step was using my own published package to generate the very plugin that published this post: create-dsh-content published to npm → generates dsh-crosspost dsh plugin add → loads it into my profile dsh crosspost tool → this article + a GitHub gist liveThat's the loop I'd recommend for anyone shipping dev tools: dogfood = honest docs. When your instructions mysteriously work, you know they're real. dsh-crosspost multi-platform cross-poster for DSH Give the scaffold a try and let me know what your first automated cross-post looks like. 🚀