How to automate social media posting with Claude Code

Start Claude Code social media automation with a file in your project. Claude turns that file into channel-specific drafts, a person reviews them, and Groniz sends or schedules only the approved content. At the end, you have 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.

This setup works well for people who already keep product updates, release notes, or articles in files. It gives that existing material a repeatable route to approved social posts.

Start with clear workflow boundaries

A controlled pipeline needs five boundaries:

1. Claude reads a source file containing the actual release, article, changelog, or announcement. A vague sentence in chat is not enough material for a campaign.
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 reports what it created, where it will go, and whether anything failed.

The source file shows where each claim came from. Separate drafts account for the differences between networks, and human approval prevents accidental delivery. Verification gives you something firmer than "Claude said it posted."

For example, 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. If a claim or link changes, you make a normal repository edit instead of hunting through chat history.

Choose how Claude Code connects to Groniz

Claude Code supports three connection paths. Your choice depends on how much workflow guidance Claude should load and how you want it to access external actions.

Path 1: install the Groniz Skill

Install the Groniz Skill with:

npx skills add groniz/groniz-cli

Choose this path when Claude Code should learn the relevant Groniz commands and when to use them. A skill can hold the full 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, not 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 leaves commands visible in terminal history, shell scripts, CI-oriented tooling, or Claude Code sessions that already have permission to run local binaries. After installation, it needs neither a Node runtime nor an 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; 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 groniz https://mcp.groniz.com/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

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 gives Claude access to an external service, including the Groniz capabilities it can discover and call. 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, and a project skill defines the controlled procedure around them. For teams that prefer local commands, the CLI can handle the action side instead. Whichever method you choose, 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
canonical_url: https://example.com/blog/api-v2
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. What matters is that the source stays durable and reviewable, with enough detail for Claude to distinguish 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 after Claude writes the drafts. A file write is reversible and easy to inspect; publishing is not. Keeping generation separate from delivery also prevents a copy-editing request from turning into permission to post.

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

If Instagram is a primary destination, a focused Instagram automation workflow can sit alongside this broader guide. The same approval model also applies to architectures that use a different agent client.

Make human review specific

"Review the posts" is too vague for 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." That maps to exact files, channels, and timing. "Looks good" does not.

For higher-risk accounts, ask Claude to display a delivery manifest before it calls an external action. The manifest should list the integration, final text, media paths, post type, status, and scheduled time. The operator then approves 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. The response from groniz integrations:settings <id> is the source of truth for that integration's required settings, current maximum length, and available integration tools.

Social providers do not expose identical capabilities, so Claude should build each outgoing request from that integration's live settings. If the settings expose a tool needed to fetch dynamic integration data, call it. If they do not, skip the call.

Upload each local media file first, then use the returned .path in the post operation. Neither a local filesystem path nor an external media URL can 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. A CLI draft gives you another chance to review the content on the platform, but draft creation skips content-length and provider-settings validation. Acceptance as a 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 send it back for review. It should never rewrite approved content silently 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. Do not flatten mixed results into a single success or failure. 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. Maintainers get an audit trail, and the next Claude Code session can see any partial delivery.

Common mistakes in Claude Code social media automation

A common failure is treating writing approval as 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 has to suit the channel. Providers can require different settings and 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 only the attempt, not the full verification. Capture the returned identifiers and state, check them against the manifest, and report partial failures. This workflow cuts repetitive work without obscuring the release boundary.

A maintainable default

A practical starting point is the Groniz Skill, versioned campaign sources and drafts, plus 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. Each post still needs its source file, channel drafts, explicit approval, live settings, delivery result, and verification record.

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