DEV Community

Caleb Rhodes
Caleb Rhodes

Posted on

How to Publish Markdown to Dev.to and Hashnode with OpenCode

#markdown #devto #programming #tutorial

OpenCode can turn repository Markdown into drafts for Dev.to and Hashnode, then use Groniz to publish or schedule the approved versions. This is not a matter of sending the same file twice. Start from one canonical source, make a version for each destination, and review the code, links, metadata, and canonical handling. Then inspect each live Groniz integration separately. Groniz handles account authorization, destination settings, scheduling, and delivery, while OpenCode keeps the article tied to the repository. This article does not claim a live end-to-end test for either destination; each live schema wins.

The two-destination workflow 

Canonical Markdown
  -> validate code, links, and claims
  -> create Dev.to and Hashnode variants
  -> review metadata and canonical plan
  -> discover each integration's live schema
  -> approve and deliver separately
  -> verify both native articles
Enter fullscreen mode Exit fullscreen mode

Dev.to and Hashnode are both developer publishing destinations. Their required settings, limits, metadata, and available post types are still not interchangeable.

Prerequisites

Prepare:

  • OpenCode with access to the article repository.
  • A Groniz account and a connected Dev.to integration.
  • A connected Hashnode integration before attempting that destination.
  • The canonical Markdown file and every local image it references.
  • A decision about the canonical URL and publication order.
  • Permission to publish under the selected author or publication.

Install the Groniz Skill with:

npx skills add groniz/groniz-cli
Enter fullscreen mode Exit fullscreen mode

OpenCode discovers skills from project locations including .agents/skills/[name]/SKILL.md, as described in the official OpenCode skills guide. If you prefer MCP, OpenCode supports remote servers in opencode.json; the official MCP guide documents that client configuration.

{
  "mcp": {
    "groniz": {
      "type": "remote",
      "url": "https://mcp.groniz.com/mcp",
      "enabled": true,
      "headers": { "Authorization": "Bearer YOUR_API_KEY" },
    },
  },
}
Enter fullscreen mode Exit fullscreen mode

Keep credentials outside version control.

Why Markdown publishing needs destination-specific work

Developer readers tend to notice broken code blocks, stale commands, and missing context. Repository access lets OpenCode run examples, follow relative links, and compare claims with current files before it touches the publishing layer.

The destination still shapes the final article. A Dev.to version may need different publication settings from a Hashnode version; a series, organization, canonical URL, or cover image must be handled according to what the live integration actually exposes. Never infer one schema from the other. For the wider architecture, start with publishing to social media from OpenCode and the Markdown publishing channel hub. The repository-verification pattern also appears in the Codex GitHub release-to-X guide, although its output format is short-form.

Prepare the canonical source

Keep the master article neutral about the destination. A practical structure is:

articles/
  retry-guide.md
  assets/
    retry-flow.png
  publish/
    retry-guide.devto.md
    retry-guide.hashnode.md
Enter fullscreen mode Exit fullscreen mode

Before adapting it, ask OpenCode to:

  1. Run or validate every command it can safely test.
  2. Resolve relative links and identify repository-only URLs.
  3. Check headings, fenced code languages, tables, and image references.
  4. Map factual product claims to source files.
  5. Flag secrets, private hostnames, internal issue IDs, and unreleased features.

Do not let the destination variants become new sources of truth. Corrections belong in the canonical file first, followed by regeneration of both variants.

Create two channel-native drafts

Give OpenCode a transformation request that preserves the technical body while allowing destination-specific framing:

Use articles/retry-guide.md as the canonical source. Produce separate Dev.to
and Hashnode drafts. Preserve all code and technical qualifiers. For each
draft, return proposed title, description, tags, cover asset, canonical plan,
and any destination setting that must be discovered at runtime. Do not assume
the two destinations share fields. Do not publish or schedule anything.
Enter fullscreen mode Exit fullscreen mode

The two versions may share most of the tutorial, but their introduction, closing context, metadata, and publication relationship should be explicit. Avoid appending a large promotional block. If the article originated on your site, settle canonical handling before delivery so copies do not compete accidentally.

Reusable asset: publication manifest

Save this beside the canonical article as retry-guide.publish.md:

# Publication manifest

Canonical source: articles/retry-guide.md
Canonical public URL:
Source commit:

## Dev.to
Integration ID:
Draft file: articles/publish/retry-guide.devto.md
Required settings: discover live
Approved title/tags:
Approved media paths:
Publication time/timezone:

## Hashnode
Integration ID:
Draft file: articles/publish/retry-guide.hashnode.md
Required settings: discover live
Approved title/tags:
Approved media paths:
Publication time/timezone:

Reviewer:
Content approval:
Publication approval:
Enter fullscreen mode Exit fullscreen mode

The manifest records the source commit behind each public article and prevents approval for one destination from silently carrying over to the other.

Review before either write action

Render both Markdown files locally. Check headings, lists, callouts, tables, syntax highlighting, embedded HTML, image captions, and link targets. Copy commands into a clean environment when practical. Confirm that examples contain placeholders rather than credentials and that version-specific instructions name the tested version.

Then review the publication layer: author identity, title, description, tags, canonical URL, cover image rights, and schedule timezone. Approve Dev.to and Hashnode independently. A valid Dev.to draft is not evidence that the Hashnode request is valid.

Deliver through Groniz, one integration at a time

Start by confirming the authenticated account and resolving live IDs:

groniz whoami
groniz integrations:list
groniz integrations:settings [devto-integration-id]
groniz integrations:settings [hashnode-integration-id]
Enter fullscreen mode Exit fullscreen mode

Treat each settings result as authoritative. Supply every required value and stay within the reported limits. If the schema lists dynamic integration tools, call only the tools it lists and use the returned values. For example, a publication selector must come from live data if the integration requires one; it should not be copied from an example.

Upload approved media before constructing either post request:

groniz upload ./articles/assets/retry-flow.png
Enter fullscreen mode Exit fullscreen mode

Record the returned .path in the manifest and use that path, not the local filename or an external URL. Have OpenCode show the complete proposed Dev.to request for publication approval, then do the same for Hashnode. Schedule or publish each only after its own approval.

The CLI commands remain separate because each integration has its own schema:

groniz posts:create \
  -c "$(cat -- ./articles/publish/retry-guide.devto.md)" \
  -m "[returned-groniz-media-.path]" \
  -s "2026-08-18T14:00:00Z" \
  -t schedule \
  -i "DEVTO_INTEGRATION_ID" \
  --settings '[devto-required-settings-json]'

groniz posts:create \
  -c "$(cat -- ./articles/publish/retry-guide.hashnode.md)" \
  -m "[returned-groniz-media-.path]" \
  -s "2026-08-19T14:00:00Z" \
  -t schedule \
  -i "HASHNODE_INTEGRATION_ID" \
  --settings '[hashnode-required-settings-json]'
Enter fullscreen mode Exit fullscreen mode

Use the returned .path for each -m argument. Resolve the two settings placeholders independently, then show each completed command for its own publication approval.

Verify delivery and handle partial success

After each request, capture the Groniz post ID, status, scheduled or published time, and returned platform URL. Open the native article and test the table of contents, code blocks, images, outbound links, author, tags, and canonical behavior.

Partial success is normal. Dev.to may publish while Hashnode rejects a field or lacks a connected integration. Leave the successful destination alone while fixing the other. Refresh only the failed integration's settings, compare the request with that schema, and determine whether the rejected operation created a draft before retrying.

Use this failure record:

Destination:
Integration ID:
Source commit:
Post ID/status:
Native URL:
Observed rendering issue or error:
Settings refreshed:
Correction:
Retry separately approved:
Enter fullscreen mode Exit fullscreen mode

Measure the next iteration

Use native Dev.to and Hashnode analytics and reader signals available to the account. Track article views, reading or engagement indicators provided by the destination, meaningful comments, referral traffic to the canonical site, and corrections readers surface. Compare the two editions cautiously: different audiences and distribution systems make raw totals an imperfect contest.

Put concrete findings back into the manifest. For example, record that "tables were hard to scan on mobile" or "the runnable example prompted detailed comments." The next OpenCode pass will have a specific editorial issue to address, without treating publishing frequency as a guarantee of growth.

When both integrations are ready, set up their connections in Groniz Connectors.

Top comments (0)