---
name: publish-social-content
description: Schedule or publish finished social content through Postdom under human guardrails, then report the observable outcome without waiting indefinitely. Use when the user asks to post, schedule, distribute, or repurpose supplied media across social networks.
---

# Publish social content with Postdom

Use Postdom as the publishing system of record. Never claim that Postdom generates the media itself.

## Required sequence

1. Call get_workspace_status. Use the returned workspace clock, policy state, connection gate, and current billing permission; do not assume a prior read reserves a future publish.
2. Call list_accounts. Use only returned account IDs. Never invent an account or destination.
3. If a redirect-based destination is not connected, call connect_account and give its authorization URL to the human. Never ask for or handle a social password. Bluesky is connected by the human in the Postdom dashboard, not by this tool.
4. Confirm the supplied media is finished and measure its real content type, byte length, width, height, and video duration. Never guess metadata.
5. Call upload_media with the measured metadata and intended destinations. PUT the exact bytes to the returned signed URL with replacement Content-Type and Content-Length headers. Do not attach a Postdom bearer credential or follow a redirect. Poll get_media for no more than two minutes. Continue only when the handle is stored; on failed or deadline expiry, report the handle and last state, then stop.
6. Before publish_video, show the human the accounts, caption, surfaces, media, and schedule. Require explicit confirmation in the current conversation unless a freshly verified Postdom plan authorizes the exact action. To use a plan, call get_plan immediately before publishing, confirm its returned status is approved, and verify the requested accounts, schedule, and remaining capacity are within the returned plan. Pass that exact plan_id to publish_video. If the plan is missing, no longer approved, expired, exhausted, or does not match the action, require explicit current-conversation confirmation instead; never rely on a remembered approval.
7. Call publish_video once with an idempotency key and the verified plan_id when a plan supplied authorization. Keep the returned post ID.
8. Inspect the returned state, then poll get_publish for no more than ten minutes with bounded backoff. Stop immediately and report the post ID when the state is requires_approval or scheduled; human review or the scheduled time is outside this polling turn. If the state is unknown, report it immediately for investigation and stop; never retry automatically. Stop on rejected, published, partial, failed, or blocked. If the deadline expires in another state, report the last observed state and stop.
9. Never retry a failed, partial, blocked, unknown, or timed-out publish automatically. A provider may have published even if Postdom has not yet reconciled it. A requires_approval, scheduled, unknown, or timed-out state is not a completed closed-loop verification. It may be observed later by calling get_publish with the same post ID; never resubmit the publish.

## Safety boundary

- Never call a human dashboard, approval, billing, or policy-administration route.
- Never request, reveal, copy, or store a Postdom credential or social-network credential.
- Publish one post at a time and observe its returned state before starting another when validating a new connection.
- A metric without a numeric value is missing evidence, not zero; preserve Postdom's exact availability state.
- Do not promise reach, engagement, virality, or platform acceptance.