Every time I shipped something, the actual distribution looked like this: write a Bluesky post (300 chars), trim it for X (280), expand it for Mastodon (500), write something longer for Dev.to, remember I already used the "here's what it does" angle last week, wonder whether I'd submitted to the MCP Registry yet. Then repeat that next week, except I didn't, because I had other work.
marketing-pipeline solves the repeat-every-week part. You onboard a project once:
marketing onboard --name my-tool --repo owner/repo --kind mcp-server
That fetches the README, extracts the problem, facts, and angles via Claude, and writes them to projects.yml. From there, a daily GitHub Actions cron at 14:00 UTC runs marketing cycle, which picks the least-recently-used angle per project, formats it per channel, and posts — Bluesky, X, Mastodon, Dev.to, Hashnode.
Per-channel length limits are enforced in code, not by hoping the draft came in under 280 characters. The anti-slop gate in pipeline/antislop.py hard-rejects specific tokens before any post goes out: "excited," "game-changer," "unlock," "AI-powered," emoji, hashtags, exclamation points, rhetorical questions. If a draft hits any of those, it doesn't post.
The kind field routes directory submissions by project type. An mcp-server gets submitted to MCP Registry, Smithery, Glama, and PulseMCP. A claude-skill goes to awesome-claude-code (the pipeline generates the payload; their rules require a human to submit via GitHub issue, so that one step stays manual). A browser-extension routes to Chrome Web Store, Firefox AMO, and Edge Add-ons.
The thing I actually wanted: configure a project once, have it keep showing up without me. That's what this does.
Top comments (0)