The latest articles on DEV Community by buchylx (@buchylx). https://dev.to/buchylx https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4096571%2F95fcacae-9594-470c-8886-e5cb639b747d.png https://dev.to/buchylx en buchylx Thu, 27 Aug 2026 03:33:58 +0000 https://dev.to/buchylx/dsh-crosspost-triple-platform-test-48j1 https://dev.to/buchylx/dsh-crosspost-triple-platform-test-48j1 <p>dsh-crosspost now supports three platforms in one call. Testing dev.to + github gist + bluesky simultaneously. This is a throwaway test.</p> buchylx Thu, 27 Aug 2026 03:22:54 +0000 https://dev.to/buchylx/how-i-automated-my-content-distribution-with-a-dsh-plugin-i-scaffolded-myself-2gbg https://dev.to/buchylx/how-i-automated-my-content-distribution-with-a-dsh-plugin-i-scaffolded-myself-2gbg <h1> How I automated my content distribution with a DSH plugin I scaffolded myself </h1> <p>Posting is easy. <strong>Posting everywhere, consistently, is the hard part.</strong></p> <p>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 <strong>DSH (DeepSeek Harness)</strong>, using a scaffolding tool that I published myself.</p> <p>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.</p> <h2> Why automate distribution at all? </h2> <p>Writing in public is the cheapest compounding asset a developer has. But cross-posting manually has two failure modes:</p> <ol> <li> <strong>You skip platforms</strong> — the "I'll do it later" tab that stays open forever.</li> <li> <strong>You lose the content graph</strong> — each platform becomes a silo with a slightly different version.</li> </ol> <p>A plugin that accepts <code>content + title + [platforms]</code> and returns <code>per-platform status + links</code> removes both. One source, many destinations, audited every time.</p> <h2> What I built </h2> <p>A DSH <strong>content-automation plugin</strong> (<code>dsh-crosspost</code>) with:</p> <ul> <li> <strong>Platform adapters</strong>: Dev.to (real), GitHub gist (real), Bluesky + Mastodon (stubs, next milestone).</li> <li> <strong>BYOK credentials</strong>: your tokens live in your DSH profile config — never in code, no platform approval needed from the plugin author.</li> <li> <strong>Error classification</strong>: every adapter wraps HTTP in try/catch and returns <code>auth / rate-limit / bad-request</code> instead of a raw stack trace, so an agent can decide to retry or skip per platform.</li> <li> <strong>Parallel orchestration</strong>: one platform failing never blocks the others.</li> </ul> <h2> The 3 pitfalls that cost me the most time </h2> <h3> 1. The stale <code>latest</code> dist-tag (the big one) </h3> <p><code>npm install @deepseek-ai/dsh-tools</code> gives you a <strong>stale 0.0.1-rc.1</strong> — the real line lives under the <code>next</code> tag. Wasted an evening debugging failures that were purely "wrong version resolved." Lesson: <strong>check dist-tags before installing anything in a fast-moving young ecosystem</strong> (<code>npm view pkg dist-tags</code>).</p> <h3> 2. Pure ESM + bare specifiers </h3> <p>The plugin must be pure ESM (<code>"type": "module"</code>), built with <code>module: esnext</code> + <code>moduleResolution: bundler</code>. Half my build errors were me fighting CJS habits (<code>require</code>, <code>module.exports</code>) at the boundary.</p> <h3> 3. The bundle patch, not a relative path </h3> <p>Deps aren't installed via npm in the profile directory — the profile loader resolves bundle <code>name</code>s through <code>node_modules</code>/profile store. Unlearning "relative path == works" was harder than the API calls themselves.</p> <h2> The 60-second scaffold </h2> <p>Instead of hand-writing the plugin skeleton, I packaged everything I learned into <strong><code>create-dsh-content</code></strong> — a scaffold that generates a working, verifying content plugin in one command, then runs <code>--verify</code> (type-check + loader dry-run) until it's green.</p> <p>What it bakes in: version pins (no stale-tag trap), pure-ESM tsconfig, the cordis patch wiring, BYOK credential plumbing, and a <code>generate → verify → install → publish</code> loop you can dogfood.</p> <h2> The best part: dogfooding it </h2> <p>The final step was using <strong>my own published package</strong> to generate the very plugin that published this post:</p> <ol> <li> <code>create-dsh-content</code> (published to npm) → generates <code>dsh-crosspost</code> </li> <li> <code>dsh plugin add</code> → loads it into my profile</li> <li>Agent calls the <code>dsh_crosspost</code> tool → this article + a GitHub gist live</li> </ol> <p>That's the loop I'd recommend for anyone shipping dev tools: <strong>dogfood = honest docs.</strong> When your instructions mysteriously work, you know they're real.</p> <h2> Links </h2> <ul> <li>Scaffold repo: <a href="https://github.com/buchylx/create-dsh-content-plugin" rel="noopener noreferrer">github.com/buchylx/create-dsh-content-plugin</a> </li> <li>Scaffold on npm: <a href="https://www.npmjs.com/package/create-dsh-content" rel="noopener noreferrer">npmjs.com/package/create-dsh-content</a> </li> <li>This plugin: <code>dsh-crosspost</code> (multi-platform cross-poster for DSH)</li> </ul> <p>Give the scaffold a try and let me know what your first automated cross-post looks like. 🚀</p> automation devtools plugins devrel