DEV Community

Caleb Rhodes
Caleb Rhodes

Posted on

How to Publish to Social Media from OpenCode

#ai #automation #tutorial #programming

OpenCode can publish to social media through the Groniz Skill, remote MCP server, or CLI. It prepares a draft from files in your project, while Groniz handles the connected account's OAuth, platform-specific settings, scheduling, and delivery across 32+ networks. Keep two approvals in the workflow. First approve the words and assets. Then have OpenCode identify the live integration, inspect its current settings, and show the complete request before anyone approves the write action and publication time. The process does not depend on browser automation or imply unattended publishing.

How the pieces fit together 

Repository source
  -> OpenCode extracts claims and links
  -> OpenCode creates a channel-native draft
  -> You review content and assets
  -> OpenCode discovers the live Groniz schema
  -> You approve publishing or scheduling
  -> You verify on the destination
Enter fullscreen mode Exit fullscreen mode

This system handles publishing. A dependable delivery process may make a regular cadence easier, but it cannot guarantee reach or engagement.

Prerequisites

You need:

  • OpenCode in the project containing your source material.
  • A Groniz account and API key, or an authenticated local Groniz CLI session.
  • At least one destination connected in Groniz.
  • A source file such as CHANGELOG.md, RELEASE.md, or an approved article.
  • Any media assets you intend to attach.
  • A written approval rule that distinguishes drafting from publishing.

OpenCode supports project skills discovered from paths such as .agents/skills/[name]/SKILL.md, so the Groniz Skill is a natural choice for a repeatable repository workflow. Its official documentation also supports remote MCP servers configured under mcp. See the OpenCode skills documentation and OpenCode MCP server documentation for the client-side behavior.

Choose the OpenCode connection path

The Skill is the shortest route when OpenCode can run commands in your environment:

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

You can also connect the remote MCP server in opencode.json:

{
  "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 the real key out of committed configuration. If your normal secret-loading setup can inject the header, use it. The third path is the standalone CLI: install it with the command documented by Groniz, authenticate through its browser device flow, and let OpenCode invoke the authenticated binary.

All three paths reach the same publishing layer. Pick one for the project. Mixing them in a single run makes permissions and failures harder to trace.

Why source-first publishing works across channels

The division of work remains useful across destinations. OpenCode can inspect the exact release note, documentation change, or approved Markdown in the repository. Groniz can expose the current settings for the specific publishing account.

The content, however, must stay channel-native. A technical article may fit Dev.to or Hashnode, a concise progress note may fit X, and a professional reflection may fit LinkedIn. Do not turn one draft into identical cross-posts. The AI-agent social publishing hub explains the broader model; the Markdown publishing guide covers long-form developer destinations. Compare the connection model with the Codex agent hub, then see turning a GitHub release into an X thread with Codex for a repo-native example.

Prepare a source packet

Give OpenCode a bounded set of evidence rather than the whole repository. A small social-source.md file works well:

# Approved source

Release: v2.4.0
Audience: API users
Problem: retries previously required custom code
Change: retry policy is now configurable
Evidence: docs/retries.md and CHANGELOG.md
Link: https://example.com/releases/v2-4-0
Do not claim: lower latency or guaranteed delivery
Enter fullscreen mode Exit fullscreen mode

Ask OpenCode to verify every claim against the named files, flag contradictions, and leave missing facts blank. This catches a common problem: fluent copy that quietly turns a narrow engineering change into a marketing promise.

Reusable asset: a channel brief

Save this as .agents/social/channel-brief.md and fill it before each run:

# Channel brief

Destination:
Objective:
Reader:
Source files:
Required link:
Media files:
Tone:
One useful takeaway:
Claims that require verification:
Claims to exclude:
Publication mode: draft only | publish now | schedule
Approved publication time and timezone:
Enter fullscreen mode Exit fullscreen mode

Then prompt OpenCode:

Read the source files and channel brief. Draft for the named destination,
using only supported claims. Preserve technical qualifiers. Return the draft,
a claim-to-source table, and a review checklist. Stop before any Groniz write
action. Draft approval is not publication approval.
Enter fullscreen mode Exit fullscreen mode

For a release-driven post, the claim table shows whether a claimed benefit came from documentation, code, or inference.

Review the channel-native draft

Review at two levels. First, check substance: version numbers, product names, dates, links, customer claims, and limitations. Then check channel fit: opening line, paragraph length, hashtags or mentions, media crop, and whether the post gives the reader something useful without requiring prior context.

Remove internal paths, confidential issue references, unreleased features, and invented quotes. Confirm that you have permission to use every image. Finally, record one of three states: revise, content approved, or content and publication approved. OpenCode should treat only the last state as permission to write externally.

Deliver through Groniz

For a Skill or CLI run, have OpenCode perform discovery in this order:

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

The settings response is authoritative for required fields, current length limits, post types, and any available dynamic integration tools. Invoke only tools listed there. If media is included, upload each file first:

groniz upload ./approved-image.png
Enter fullscreen mode Exit fullscreen mode

Use the returned .path in the eventual post request, not the local filename or an external image URL. Then ask OpenCode to assemble a publish-now or scheduled request from the discovered schema and show the final destination, content, media paths, and time for approval. Dev.to, Hashnode, Discord, Telegram, X, and LinkedIn are supported destinations, but their capabilities and settings are not identical.

For one reviewed target, the generic scheduling command is:

groniz posts:create \
  -c "APPROVED_CONTENT_FOR_THIS_TARGET" \
  -m "[returned-groniz-media-.path]" \
  -s "2026-08-14T15:00:00Z" \
  -t schedule \
  -i "TARGET_INTEGRATION_ID" \
  --settings '[required-settings-json]'
Enter fullscreen mode Exit fullscreen mode

Replace the settings placeholder with every required value from that target's live response. The media value must be the .path returned by groniz upload. For another destination, repeat discovery and build a new command with that integration's own settings. OpenCode should show each resolved command and wait for publication approval before running it.

Verify delivery and handle failures

A returned post ID shows that Groniz accepted the request. Confirm its status, then open the destination URL when one is returned. Check the native post's line breaks, links, media, account identity, and publication time.

When delivery fails, keep a compact record:

- Integration ID:
- Requested time/timezone:
- Source revision:
- Returned post ID:
- Error or final status:
- Settings refreshed after error: yes/no
- Retry approved by:
Enter fullscreen mode Exit fullscreen mode

Refresh integrations:settings before changing the request. Common categories are expired authorization, a required field omitted from the live schema, content over the current limit, an unsupported post type, a media upload problem, or a timezone mistake. Do not retry blindly: first determine whether the failed request might still have created a post.

Measure the next iteration

Use the destination's native analytics and qualitative replies. Record impressions or views, meaningful responses, clicks when available, and the editorial change you want to test next. Compare similar posts over time; one result cannot establish a best time or winning format. Keep the source brief and final approved draft beside those observations. The next OpenCode run then has a concrete editorial decision to work from instead of a vague instruction to "perform better."

To set up the publishing layer, connect an account and create an API key in Groniz Connectors.

Top comments (1)

Collapse
 
marcusykim profile image
Marcus Kim •

The two-approval boundary is the strongest part here: approving the draft and assets separately from the final destination-specific write action makes publishing auditable without pretending the agent should run unattended. The insistence on discovering live integration settings, uploading media first, and using the returned .path also addresses the operational failures that usually hide behind a "simple" social workflow. For a founder, the source packet and claim-to-source table are valuable product discipline: they keep a release note from quietly becoming an unsupported promise. The tradeoff is that this remains a human-in-the-loop.