after i started writing more consistently, it became obvious that writing is only half the work; distribution is the other half. i wanted a system where i can publish from one canonical source and let automation push the same story to dev.to and linkedin.
quick answer
i set up two publish automations that watch my post changes and sync them to dev.to and linkedin. the first publish creates the post on each platform, and later edits update the same external post instead of creating duplicates. this gives me consistent visibility without adding manual publishing steps after every article.
who this is for
- people who publish technical writing and keep forgetting cross-posting
- creators who want one canonical source plus repeatable distribution
- builders who care about discoverability as much as writing quality
why this matters
if distribution is manual, it eventually slips. then strong posts sit unread because i forgot to copy, paste, format, and re-share them across platforms. automation solves that by making visibility part of the same delivery path as the content itself.
this is the same pattern i described in a practical ai workflow: jira, github, and mcp, define one clear source of truth, then automate the handoff steps so i can spend more time on thinking and less time on clerical work.
step-by-step
1) define the starting point
i chose my site post as the only canonical source. every external platform receives content from that source, not from separate drafts. this keeps language, links, and updates aligned over time.
2) apply the change
i added automation for both targets:
- trigger on post updates and support manual runs when i want a full backfill
- create posts when no external mapping exists
- update existing external posts when a mapping already exists
- keep a small state map so each canonical url stays attached to one external post id
the practical result is that i can keep writing in one place and trust the sync layer to handle distribution. this complements the writing habits from my cursor setup, where reusable workflows remove repeated manual work.
3) validate the result
i test in three passes:
- dry run to confirm detection and decisions without publishing
- publish-all run to verify initial backfill behavior
- normal change-trigger run to verify incremental updates on later edits
when all three pass, i know the pipeline is reliable enough for daily use.
faq
what was the biggest setup mistake?
token and redirect mismatches during oauth were the main failure point at first. once i aligned scopes, callback values, and secret placement, the automation became stable.
should i keep manual publishing as a fallback?
yes, especially while you are in early setup. after the workflow proves stable, manual publishing becomes a recovery path instead of a default habit.
Top comments (0)