How to automate social media posting with Claude Code

Claude Code social media automation works best when it starts with a file in your project. Claude creates channel-specific drafts from that file, a person reviews them, and Groniz sends or schedules only the approved content. The workflow ends with a delivery record you can inspect.

Claude Code can reach Groniz through a Skill, the native CLI, or a remote HTTP MCP server. All three paths use the same connector core, which handles OAuth, per-platform formatting, scheduling, and delivery to 32+ networks. The path you choose changes how Claude Code invokes those capabilities. The editorial controls stay the same.

The approach fits developers, founders, and advanced creators who already keep product updates, release notes, or articles in files. It gives those files a repeatable route to approved social posts.

Start with clear workflow boundaries

A controlled pipeline has five boundaries:

1. Claude reads a source file containing the actual release, article, changelog, or announcement. A vague sentence in chat is not enough to invent a campaign from.
2. Claude creates a separate draft for each channel. A LinkedIn post should not be treated as an X post with a larger character budget.
3. A person reviews the facts, tone, links, media, destinations, and timing.
4. Claude uses Groniz to create platform drafts or schedule approved posts with the settings required by each live integration.
5. Claude checks the result and confirms what was created, where it will go, and whether anything failed.

The source file records where the claims came from, while separate drafts account for differences between networks. Human approval keeps delivery intentional. Verification replaces "Claude said it posted" with an observable result.

A release workflow might start with docs/releases/v2.4.md, write proposed posts to social/v2.4/, and produce a short delivery report after approval. You can review the generated files in a diff. Changing a claim or link then becomes a normal repository edit instead of a correction buried in chat history.

Choose how Claude Code connects to Groniz

Claude Code supports three valid paths. Pick one based on how much workflow guidance you want Claude to load and how you prefer to expose external actions.

Path 1: install the Groniz Skill

Install the Groniz Skill with:

npx skills add groniz/groniz-cli

Choose this path when you want Claude Code to learn the relevant Groniz commands and when to use each one. A skill can hold the whole procedure, including integration discovery, live requirement checks, media uploads, delivery, and verification.

Anthropic describes Claude Code skills as instructions and multi-step procedures that Claude can load when relevant or invoke directly. The Claude Code feature overview also presents skills as reusable knowledge and workflows.

Use the Skill when Claude needs to follow the same publishing checklist every time, rather than simply gain API access.

Path 2: install the native Groniz CLI

Install the self-contained native CLI and authenticate with the browser device flow:

curl -fsSL https://groniz.com/install.sh | sh
groniz auth:login

The CLI makes commands visible in terminal history, shell scripts, CI-oriented tooling, or Claude Code sessions that already have permission to execute local binaries. It requires no Node runtime after installation and no API key for the browser login flow.

Claude Code can call the binary directly. Put the workflow in your prompt, project instructions, or your own skill. The CLI performs the operation, while your repository defines what Claude must check first.

Path 3: connect the remote HTTP MCP server

Create an API key in Groniz Connectors, then add the remote server:

claude mcp add --transport http \
  --header "Authorization: Bearer YOUR_API_KEY" \
  groniz https://mcp.groniz.com/mcp

Keep Claude Code options before the server name when extending the command. For example, place an added scope option before groniz, rather than appending it as if it were an argument to the server.

The official Claude Code MCP documentation recommends HTTP for remote cloud services. MCP fits workflows in which Claude needs external tools, data, or actions. Once connected, Claude works with the capabilities exposed by the server instead of driving a local executable.

Treat the API key as a credential. Do not commit it to the repository, place it in a source content file, or paste it into reusable prompt examples.

Use Skills and MCP for different jobs

A Skill and MCP can appear to be competing installation options, but they handle different jobs.

A skill stores reusable instructions. It can tell Claude which source files to accept, how to split content by channel, what a person must approve, and which verification evidence to return. If you repeatedly paste the same checklist into Claude Code, put it in a skill.

MCP supplies access to an external service. It lets Claude discover and call Groniz capabilities. The official Claude Code comparison is direct: MCP connects external services, while skills provide knowledge and workflows.

You can use both. MCP provides the publishing actions, while a project skill defines the controlled procedure around them. The CLI can fill the same action role for teams that prefer local commands. In either case, keep the sequence stable: source, channel drafts, review, delivery, and verification.

Build the source-to-draft stage

Start with a real file rather than an unstructured prompt. A good source includes the facts that may appear in the posts and the details needed to check them:

---
campaign: api-v2-launch
approved_channels:
  - linkedin
  - x
  - bluesky
---

# API v2 launch

What shipped, who it is for, migration constraints, and the approved call to action.

Use whatever schema suits the repository. The source needs to be durable and reviewable, with enough detail for Claude to separate facts from proposed copy.

Ask Claude Code to create one file per channel and to preserve the canonical URL. Your prompt can be explicit:

Read docs/releases/api-v2.md. Create channel-specific drafts under
social/api-v2/ for only the approved channels in the frontmatter.

Preserve all technical constraints. Do not schedule or publish anything.
For each draft, include the destination, proposed text, link, media notes,
and any claim that needs human confirmation.

Stop this stage after Claude writes the drafts. A file write is reversible and easy to inspect. Publishing is not. Separating generation from delivery also prevents a copy-editing request from becoming permission to post.

A channel-specific draft is more than a shortened copy of the same paragraph. Claude should adapt the opening, structure, and use of links for the destination while preserving the facts. Formats and capabilities vary by provider, so do not assume every network accepts the same media, metadata, or scheduling options.

Make human review specific

"Review the posts" is too vague to work as a release gate. Give the reviewer a short checklist and require explicit approval of the exact drafts.

The review should cover:

• Every product claim is supported by the source.
• The links and destination accounts are correct.
• Each post fits its audience and channel without changing the meaning.
• Media files are final and licensed for use.
• The requested publication time and timezone are correct.
• The copy contains no sensitive, embargoed, or internal information.

A useful approval message names the revision and scope: "Approve commit abc123 for LinkedIn and Bluesky at 14:00 UTC; keep the X draft unpublished." Unlike "looks good," this instruction maps to exact files, channels, and timing.

For higher-risk accounts, ask Claude to display a delivery manifest before calling an external action. The manifest should list the integration, final text, media paths, post type, status, and scheduled time. The operator can approve that manifest as the final boundary.

Deliver through the live Groniz integration

After approval, Claude should discover the current integration requirements instead of relying on an old template. Start the command-line flow with:

groniz whoami
groniz integrations:list
groniz integrations:settings [id]

groniz whoami confirms the authenticated account. groniz integrations:list resolves the live integration ID for each target. Treat groniz integrations:settings [id] as the source of truth for that integration's required settings, current maximum length, and available integration tools.

Social providers do not expose identical capabilities. Claude should build each outgoing request from the live settings for that integration, without relying on assumptions about the network. If the settings expose a tool needed to fetch dynamic integration data, call it. If they do not expose a tool, skip the call.

Upload each local media file first, then use the returned .path in the post operation. A local filesystem path is not a delivery path, and an external media URL cannot replace the uploaded result.

Once Claude has the live settings and uploaded media paths, it can create a draft or schedule the post with every required channel setting. Drafts allow another review on the platform, but they skip some validation. An accepted draft does not prove that the same content will pass every check when scheduled or published.

A delivery instruction might read:

Use the approved manifest only. Confirm authentication, resolve each live
integration ID, and inspect its current settings. Upload media first and use
the returned .path. Supply every required setting. Create drafts for the two
draft targets and schedule only the explicitly approved scheduled target.
Stop and report if the live requirements conflict with the approved content.

If a live length limit, required field, or media constraint would change the approved post, Claude should return it for review. It should not silently rewrite content during delivery.

Verify the result instead of trusting the attempt

The delivery report should answer four questions:

1. Which integration received the request?
2. Was the result a platform draft, scheduled post, or published post?
3. What post ID, scheduled time, release ID, or platform URL was returned?
4. Did any target fail or require another action?

Have Claude report those fields for each destination and compare them with the approved manifest. Keep mixed results mixed. If two destinations succeed and one fails, the report should identify the failed target without retrying all three and risking duplicates.

Keep the verification record near the content workflow and leave credentials out of it. This record gives maintainers an audit trail and makes a partial delivery visible to the next Claude Code session.

Common mistakes in Claude Code social media automation

The most common failure is combining writing approval with publishing approval. "Make this ready for LinkedIn" authorizes editing, not delivery. Use separate prompts or a skill with an explicit approval boundary.

One post is not universally portable. The connector handles per-platform formatting and delivery, but the editorial draft still needs to suit the channel. Each provider can require different settings or support different formats.

Stale integration assumptions cause another common problem. Inspect groniz integrations:settings [id] immediately before creating the post. Its live response outranks an example copied from a README or an old workflow run.

A successful tool call is not complete verification. Capture the returned identifiers and state, check them against the manifest, and surface partial failures. The workflow should reduce repetitive work while leaving the release boundary easy to inspect.

A maintainable default

A straightforward starting point is the Groniz Skill, versioned campaign sources and drafts, and explicit approval of a delivery manifest. Teams that want terminal-native control can use the CLI directly. Teams that standardize external tools through Claude Code can connect the HTTP MCP server and keep the same skill-based workflow on top.

You can change the integration method later without rewriting the editorial process. Keep a source file, channel drafts, explicit approval, live settings, a delivery result, and a verification record for each post.

To connect Claude Code to the publishing layer, set up your accounts in Groniz Connectors.