SkedCast

View saved version →

---
name: account-connect
description: Manage connected social accounts. Use when the user asks which accounts are connected, wants to connect a new account, or asks about posting limits and quota before a big batch.
---

# Connected Accounts

## Seeing what's connected

Call `list_accounts`, optionally filtered by client or platform. Each row shows the
platform, handle, and status. This is the source of truth for "which accounts can I
post to?" — always check it before composing for a specific account. For one account
in full — platform, handle, display name, avatar, status (including whether it needs
re-authorisation), and owning client — call `get_account`.

## Connecting a new account

Call `create_connect_invite` to mint a shareable self-connect link for the requested
platforms. The client (or the user) opens the link and connects the account
themselves through each platform's official OAuth flow — SkedCast never sees their
platform password. The link has an expiry; mention it when sharing.

## Before a big batch

Two read-only tools keep large operations safe:

- **`get_posting_limits`** — per-account anti-ban cadence. Call with a
  `socialAccountId` for one account, or omit it for every active channel plus the
  tenant bypass flag. Respect these limits when pacing a batch.
- **`get_quota`** — the adaptive quota pool: guaranteed slice, used amount, burst
  headroom, tomorrow's guarantee, and the reset clock. Read before planning any
  batch so you don't promise what the quota can't deliver.

## Notes

- Connecting accounts is done by the account owner through the invite link, not by
  the assistant — you mint the link, they complete the OAuth.
- When a publish fails, `get_post_target` reports the platform's own failure reason;
  share it verbatim rather than guessing.

View saved version →

---
name: analytics-report
description: Report on social performance via SkedCast analytics. Use when the user asks how posts performed, for reach/impressions/engagement summaries, per-post or per-account breakdowns, or best times to post.
---

# Analytics & Best-Time Reports

All of these tools are read-only; no confirmation needed.

## Answering "how did we do?"

1. **Start with `get_analytics_overview`.** Pass a date window. Returns reach,
   impressions, and engagement plus a per-platform rollup. This is the right first
   call for "how did my posts perform last week?"

2. **Drill down as needed:**
   - `get_post_analytics` — one post's lifetime per-target breakdown by postId, or a
     keyset page of per-post rows with filters.
   - `get_account_analytics` — one channel's totals and daily series, plus profile-level
     activity (profile views, link taps, video plays) and follower demographics.
   - `get_client_analytics` — one client group's totals, per-platform breakdown, and
     time series. A different projection from the overview filtered by client.
   - `list_reports` / `get_report` — the workspace's saved report definitions; `get_report`
     includes run history (status, window, export availability).
   - `download_report_export` — a time-limited download URL for a completed report run's
     export file. Fetch it when ready to use — the URL expires.

3. **Present a summary, not a data dump.** Lead with the headline numbers, then the
   per-platform rollup, then 1–2 notable posts. Mention the date window you used.

## Answering "when should I post?"

Call `get_best_times` (optionally filtered by client or platform). It returns
worker-derived best posting times, strongest first. Combine with the user's goals:
match their content calendar against the top recommendations and propose specific
slots.

## Notes

- Analytics reflect the connected workspace only — the authenticated user's own data.
- If a date window is ambiguous ("last week"), state your assumption (e.g. last 7
  calendar days) before reporting.

View saved version →

---
name: approval-workflow
description: Work the SkedCast approval queue. Use when the user asks what is waiting for approval, or wants to approve, reject, request changes, or revise a post under review.
---

# Approval Workflow

For teams and agencies where publishing is gated by review. Deciding an approval is a
write action — always confirm with the user before calling `decide_approval`.

## The workflow

1. **List the queue.** Call `list_approvals` (newest first, optional status/post
   filters). For one request in full — the gated post's preview and roll-up, so the
   reviewer sees what they are deciding on — call `get_approval`. Summarize each
   pending request: the post content, target accounts, scheduled time, and who it is
   waiting on.

2. **Present for decision.** Show the user the pending items and ask what to do with
   each: approve, reject, or request changes. Never decide on their behalf.

3. **Decide.** Call `decide_approval` per request. Approving releases the gated post
   for publishing.

4. **Revise if needed.** If the user wants changes to a post under review, use
   `revise_post` to change content, media, or per-platform overrides without
   disturbing its destinations. Note: editing an APPROVED post returns it to review,
   and `revise_post` refuses (naming them) when a destination has already published
   or is about to.

## Key facts

- `list_clients` / `get_client` show each client group's approval policy, so you can
  explain why a post is gated.
- Posts created via `create_post` for a client that requires approval are submitted
  for review automatically instead of publishing.
- Approval decisions are final in the sense that they release or block publishing —
  treat them with the same care as publishing itself.

View saved version →

---
name: campaign-manager
description: Manage SkedCast campaigns (named post groupings). Use when the user wants to create, update, delete, or inspect campaigns, group posts into a campaign, or shift a whole campaign's schedule.
---

# Campaign Manager

Campaigns group posts under a name with an optional client, colour, and date range.
Grouping never changes a post's content or schedule. Create/update/delete are write
actions — confirm with the user first.

## The workflow

1. **List** with `list_campaigns` (optional client/status filters). **Read** one in full
   with `get_campaign`: name, description, status, colour, date range, owning client,
   and post counts.
2. **Create** with `create_campaign`, then add existing posts with `assign_to_campaign`
   (up to 500 posts per call). Remove with `unassign_from_campaign` — the posts and
   their schedules are untouched.
3. **Update** with `update_campaign` to change name, description, status, colour, or
   date range.
4. **Shift** the whole campaign's pending schedule with `shift_campaign` by a relative
   number of minutes — the fast way to move a launch week.
5. **Delete** with `delete_campaign`. The posts are NOT deleted — they lose the
   grouping and keep their own schedules.

## Notes

- Campaigns are an organizational layer, not a publishing mechanism. Scheduling still
  happens per post via the schedule-post skill.
- When reporting campaign contents, use `list_scheduled_posts` filtered by campaign
  to show what's actually in it.

View saved version →

---
name: client-management
description: Manage SkedCast client groups (brands/influencers). Use when the user wants to list, create, update, or archive clients, or asks about a client's approval policy, posting rules, brand voice, or timezone.
---

# Client Management

Client groups organize an agency workspace by brand or influencer. Creating, updating,
and archiving clients are write actions — confirm with the user first.

## The workflow

1. **List clients** with `list_clients` to see the workspace's client groups.
2. **Read one client** with `get_client` for the full picture: name, type, approval
   policy, posting rules, brand voice, and default timezone.
3. **Create** with `create_client` when onboarding a new brand. Set the approval policy
   up front — it decides whether that client's posts publish directly or go to the
   approval queue (see the approval-workflow skill).
4. **Update** with `update_client` to change name, type, approval policy, posting
   rules, brand voice, or timezone.
5. **Archive** with `delete_client` when a client leaves. OWNER ONLY — a Manager holding
   the clients.manage scope cannot do this. Confirm explicitly; archiving is not
   undoable from here.

## Using client context when composing

- Always check `get_client` before drafting for a client: the **brand voice** guides
  tone, **posting rules** constrain content, and the **default timezone** anchors
  scheduling.
- Filter post and analytics tools by client to keep each brand's data separate:
  `list_scheduled_posts`, `get_best_times`, and `list_campaigns` all accept client
  filters.
- A client's approval policy determines the publishing path: posts for approval-gated
  clients are submitted for review automatically.

View saved version →

---
name: evergreen-content
description: Set up evergreen (recycled) posts. Use when the user wants a post to repeat automatically on a schedule, or asks about recycling content.
---

# Evergreen Content (Recycle)

Evergreen posts republish automatically on an interval — useful for timeless tips,
offers, and announcements. Changing recycle settings is a write action — confirm
with the user first.

## The workflow

1. Find the post with `list_scheduled_posts` (search by caption or client).
2. Check the current setup with `get_post_recycle` — returns the evergreen
   configuration and the worker's bookkeeping, or null when the post is not enrolled.
3. Call `set_post_recycle` with the interval, number of times, end date, and maximum
   recycles. Be explicit with the user about all four: how often it repeats, how many
   times total, and when it stops.
4. To stop recycling, call `clear_post_recycle`. Idempotent. Note: already-scheduled
   recycled copies are NOT retracted — cancel those separately with `cancel_post`.

## Notes

- Recycle applies per post; each cycle publishes to the post's existing targets.
- Evergreen content still passes through the client's approval policy and platform
  rules on every cycle.
- Suggest evergreen for content that doesn't date: tips, FAQs, testimonials, and
  recurring offers. Don't suggest it for time-sensitive announcements.

View saved version →

---
name: manage-calendar
description: Manage the SkedCast content calendar. Use when the user asks what is scheduled or publishing on a date, or wants to reschedule, cancel, retry, or inspect scheduled posts and their per-platform destinations.
---

# Manage the Content Calendar

Rescheduling, cancelling, and retrying are write actions — confirm with the user
before calling.

## Seeing what's scheduled

- `list_scheduled_posts` — the workspace's posts (queue, drafts, published),
  newest first, with status/client/platform filters and free-text search over captions,
  client names, and account handles.
- `list_post_targets` — individual post DESTINATIONS (one row per platform account)
  with an optional schedule-time window. This is the tool for "what publishes on
  this date". It carries `total` and `totalPosts` so you can tell a full page from a
  complete set.
- `get_post` — one post with its per-platform variants and fan-out targets.
- `get_post_target` — one destination in full: status, scheduled time, platform,
  account, published permalink, and the failure reason when it failed.

## Changing the schedule

- `reschedule_post` — move a pending post target to a new time (absolute
  `scheduledAt` or relative `shiftMinutes`).
- `cancel_post` — cancel a still-pending post target before it publishes.
- `retry_post` — re-queue a failed or rate-limited target so it publishes again.
  When a target failed, read `get_post_target` first and tell the user the platform's
  own failure reason before retrying.
- `bulk_post_target_action` — reschedule, retry, or cancel up to 5000 targets in one
  call. Returns `{ jobId, accepted, skipped, skippedReasons? }`; skipped targets are
  reported, never silently dropped.
- `shift_campaign` — move a whole campaign's pending schedule by relative minutes.

## Notes

- `get_posting_limits` shows per-account anti-ban cadence; `get_quota` shows the
  scarce-bucket budget. Read them before planning large batches.
- Campaigns are named post groupings: `list_campaigns` / `get_campaign` to inspect,
  `assign_to_campaign` / `unassign_from_campaign` to group (grouping only — never
  changes content or schedule).

View saved version →

---
name: media-library
description: Work with the SkedCast content library (DAM). Use when the user wants to find, import, or upload images and videos for posts, or asks what media is available.
---

# Media Library

The content library holds reusable images and videos. Importing and uploading are
write actions — confirm with the user first.

## Finding assets

Call `list_library_assets` with kind, folder, label, client, or status filters, plus
free-text search. To find assets that are actually publishable, filter
`status: "transcoded"` — every row also carries `status`, `publishable`, and `ready`,
so check those flags before attaching an asset to a post. For one asset in full —
filename, kind, size, dimensions, duration, folder, labels, alt text, pipeline
status, and the per-platform readiness map — call `get_media_asset`.

## Adding media

- **`import_media`** — ingest an external image/video by URL. The file must already be
  reachable at a public URL.
- **`upload_media`** — upload a local image/video and get back a media id for
  `create_post`. Sends the file inline (≤18 MiB) or returns a presigned URL for
  larger files. Use this for bytes you already hold, e.g. an image just rendered in
  the conversation.

## Using media in posts

Pass the media id to `create_post` / `update_post`. For per-platform needs (cover
images, alt text), set them in `variants[].overrides` — `create_post` accepts
per-asset alt text per platform. Check `get_capabilities` first for each platform's
media rules: allowed counts, formats, file-size ceiling, duration bounds, and aspect
ratios.

View saved version →

---
name: schedule-post
description: Draft, validate, and schedule social posts across 11 networks via SkedCast. Use when the user wants to create, schedule, or bulk-schedule posts. Covers the platform rulebook, dry-run validation, and safe publishing.
---

# Schedule a Post with SkedCast

This skill guides composing and scheduling posts through the SkedCast MCP tools.
All write tools require the user's explicit confirmation before calling.

## The workflow

1. **Read the rulebook first.** Call `get_capabilities` before composing. It returns
   per-platform caption/hashtag limits, media rules (counts, formats, size, duration,
   aspect ratios), supported post types, and native-scheduling windows. Never discover
   a limit by failing a publish.

2. **Dry-run with `validate_post`.** It takes the same arguments as `create_post` but
   writes nothing. Returns `{ valid, platforms[], estimatedCostUsd }`. Fix any platform
   verdicts before proceeding.

3. **Confirm with the user.** Show the final caption, target accounts, and scheduled
   time. Only call `create_post` (or `create_posts_bulk`) after they approve.

4. **Create.** `create_post` composes one post fanned out across the selected accounts,
   or saved as a draft. `create_posts_bulk` creates up to 50 posts in one call; each
   item takes the same arguments as `create_post`, items are created independently
   (one failure never rolls back the others), and `validateOnly: true` dry-runs the
   whole batch.

## Key facts

- `create_post` is retry-safe: retrying with identical arguments replays the original
  result instead of creating a duplicate.
- Two publish-now calls with byte-identical content and targets are treated as the
  same post. To publish the same content twice intentionally, vary the content or use
  distinct scheduled times.
- Platform-specific settings (YouTube privacy, TikTok privacy level, Pinterest board,
  Telegram chat) go in `variants[].overrides`. That object also carries `firstComment`:
  a reply posted automatically once the destination goes live. Supported on X, LinkedIn,
  YouTube, Instagram, Facebook, Threads, Telegram, and Bluesky (not TikTok or Pinterest).
  Spell it exactly `firstComment`.
- A client that requires approval gets the post submitted for review instead of
  publishing — see the approval-workflow skill.
- To publish an existing draft, use `publish_draft` (same checks as `create_post`).
- To change a draft's content/targets/schedule in place, use `update_post` (drafts only,
  never publishes).
- Import external images/video into the content library first with `import_media` (public
  URL) or `upload_media` (local file, ≤18 MiB inline), then reference the media id.
- For large calendar moves, prefer `bulk_post_target_action` (up to 5000 targets) over
  many single calls. Check `get_quota` before planning a big batch.

View saved version →

---
name: webhooks-setup
description: Set up SkedCast outbound webhooks. Use when the user wants event notifications (publishing, approvals, failures) delivered to their own endpoint, or asks about webhook deliveries and failures.
---

# Webhooks Setup

Outbound webhooks deliver HMAC-signed event notifications to the user's own endpoint.
All management calls are write actions — confirm with the user first.

## The workflow

1. **List** existing endpoints with `list_webhooks` (URL, subscribed events, active
   flag; the secret is masked).
2. **Create** with `create_webhook`: give the endpoint URL and the subset of events to
   subscribe to (full 40-event catalog — see https://skedcast.com/developers/webhooks
   for the complete list with payload fields). The signing secret is returned ONCE —
   tell the user to store it immediately; it is never readable again.
3. **Test** with `test_webhook`: sends a `webhook.test` delivery and reports the
   outcome, proving the endpoint is reachable and verifying signatures without
   waiting for a real event. This performs a real outbound request.
4. **Inspect** with `get_webhook` (URL, events, active state, consecutive failures,
   when/why auto-disabled) and `list_webhook_deliveries` (per-attempt log with event
   type, response status, error, and timing) — this is how you find out WHY an
   endpoint stopped receiving.
5. **Update** with `update_webhook` to change URL, event list, or active state —
   including re-enabling an endpoint auto-disabled after repeated failures. Note: the
   event list REPLACES the previous one, so pass the full desired set.
6. **Rotate** the signing secret with `rotate_webhook_secret` when it may be
   compromised. The new secret is returned once; the previous secret keeps verifying
   for a short overlap so the user can redeploy without dropping deliveries.
7. **Delete** with `delete_webhook` by id. Deliveries to it stop (cascade).

## Notes

- Webhooks are a developer feature. Keep explanations concrete: what events fire,
  where they go, and how to verify the HMAC signature.
- Never invent event names — refer to the catalog at
  https://skedcast.com/developers/webhooks or the `webhooks` block in openapi.json.
- Event naming is `object.verb`: past tense for outcomes (`post.published`),
  present participle for in-flight states (`target.preparing`), predictive for
  warnings (`account.token_expiring`). `post.published` / `post.failed` fire per
  destination — prefer their `target.published` / `target.failed` twins.
- Deliveries POST a JSON envelope `{ id, type, created, data }`, signed with Standard
  Webhooks headers plus `X-SkedCast-Signature`. Delivery is at-least-once with
  exponential backoff — dedupe on the payload id.
- Key events to know: `target.published` / `target.failed` (per-destination outcomes),
  `media.ready` / `media.failed` (asset pipeline), `account.reauth_required` (channel
  needs reconnecting — publishing to it is paused), `approval.requested` /
  `approval.decided`, `report.completed`, and `post.recycled` (evergreen copy created).

View saved version →

---
name: workspace-overview
description: Understand the SkedCast workspace. Use at the start of a session or when the user asks about their plan, role, permissions, or workspace settings.
---

# Workspace Overview

Call `get_agency` to read the current workspace profile: name, plan, app mode,
settings, and — importantly — the caller's role. This is a read-only call.

## Why it matters

- **Role and permissions.** The assistant acts as the user, never more: their role
  and per-client permissions still apply. If a tool call is rejected, explain it in
  terms of the role (e.g. archiving a client is OWNER ONLY).
- **Plan awareness.** The plan determines connected-account limits, bulk ceilings,
  and which features are available. When a user asks for something beyond their
  plan, explain what their plan includes and which plan unlocks it — link to the
  informational plans page, never to a checkout.
- **Settings context.** Workspace settings (e.g. default timezone) anchor scheduling
  and reporting throughout the session. Read once, reuse everywhere.

## When to call it

At the start of a substantive session, or whenever the user's request touches
permissions, limits, or plan-gated features. Don't call it for every trivial
question — once per session is enough unless something changes.