---
name: calendar-schedule
description: >
  Turn a content plan — often produced by the social-calendar or social-repurpose skills —
  into real scheduled posts on the real calendar: parse the plan, map every row to a
  connected channel, preview each row's server-side readiness, propose the full week's
  schedule, and book every row with one call each. Covers LinkedIn, X (Twitter),
  Instagram, and Facebook today, with Mastodon, Threads, Bluesky, TikTok, and YouTube in
  platform review. Use when the user says "schedule my week", "schedule this plan", "put
  my calendar on the calendar", or "schedule these posts". Requires the Inklate CLI
  (npm i -g inklate) or the Inklate MCP connection. Reads social-context.md when present
  for cadence and voice. The receipt is the week as a table of real scheduled times and
  post IDs, verified against the queue.
license: MIT
metadata:
  version: 0.2.0
  topics:
    - planning
    - publishing
  examplePrompt: "Schedule this two-week content plan across my channels"
  pairsWith:
    - social-calendar
    - social-repurpose
  mcpTools:
    - posts_create
    - posts_validate
    - posts_list
    - posts_get
  cliCommands:
    - posts create
    - posts validate
    - posts list
    - posts get
---

Take a content plan off the page and onto the real calendar: every row becomes one validated, scheduled post with a confirmed time on a real channel.

## Transports

- **CLI (preferred):** `inklate` (`npm i -g inklate`) — structured YAML on stdout (`--json` for JSON), progress on stderr, and typed exit codes: `3` no credentials, `4` a deliberate refusal — arming a row that isn't `ready` — with its machine-readable payload on stdout, `5` not found, `6` the resource changed underneath you, `7` rate limited but safe to re-run later. Pass `--no-input` when running unattended so a missing flag fails loudly instead of prompting, and `--yes` to carry an approval the user has already given in chat.
- **MCP (fallback):** the Inklate MCP tools when the CLI is not installed.

Steps below name the MCP operation with the CLI form in parentheses; the fields are the same on both.

## Connection check

1. Run `inklate auth check` (MCP: `organizations_list`) first.
2. On exit 3 (no credentials): interactively run `inklate auth login`; headless, the key comes from `INKLATE_API_KEY=inklate_…` in the environment or `inklate auth set --token inklate_…`. If neither transport is available at all, tell the user to install with `npm i -g inklate` (or connect at `https://inklate.com/skills/connect?ref=skills-calendar-schedule`) and STOP.
3. If multiple organizations exist, ask which one owns this calendar. All times and channels below are scoped to that organization (CLI: `--org <slug>`).

## Context

Read `social-context.md` (project root, then `.agents/social-context.md`) if present. `## Cadence` is the reality check against overstuffed plans, `## Platforms` resolves ambiguous channel names in the plan, and `## Voice` / `## Never` govern any content adjustments you make while resolving errors. Proceed without it if absent.

## Workflow

1. **Parse the plan.** Read the plan table or list the user provides. Extract per row: content (or a pointer to a draft), target channel(s), and intended day/time. Flag rows you cannot parse instead of guessing.
2. **Map rows to channels.** Match each row's platform to a connected channel. Rows targeting unconnected platforms get flagged and set aside — never silently dropped, never scheduled to a wrong channel.
3. **Preview every row before booking anything.** Call `posts_validate` (CLI: `inklate posts validate --content … --channel …`) for each mapped row — a dry run, nothing is stored. Read each row's `ready` and per-channel `errors[]`/`warnings[]`. For every fixable error, adjust the row's content directly (autofix already applied where it could when you actually create it, but a dry-run preview surfaces judgment calls early); surface judgment calls to the user in one consolidated batch, not one interruption per row.
4. **Build the proposed schedule.** Convert the plan's intended times into concrete datetimes in the organization's timezone, then apply the constraints:
   - Spacing: no two posts on the same channel within 3 hours — when the plan violates this, nudge the later post and note the nudge.
   - Existing queue: check `posts_list` (CLI: `inklate posts list --scheduled-from … --scheduled-to …`) for already-scheduled posts in the window so the new week doesn't collide with them.
   - Rows with a day but no time get a sensible default for that platform, marked as your suggestion.
   - Past times are an error, not a nudge: flag any row whose intended time has already passed.
5. **Approval gate.** Present the entire proposed week as one table — day, time (org timezone), channel, content summary, readiness from step 3 — before anything is booked. Scheduling posts is a real-world action: get an explicit yes on the whole table, or apply the user's edits and re-present. Never book a partial week on an implicit go-ahead.
6. **Book it — one call per row.** On approval, call `posts_create` (CLI: `inklate posts create --content … --channel … --scheduled-at <time> --idempotency-key <row-id> --yes`) for each row; the same call both writes the post and arms it for that instant, so there is no separate sync, preflight, or schedule-placements step left to run. The `--idempotency-key` (the plan row's own identity is a good source) makes a retry replay instead of creating a second copy of the same row.
   - If a row's arming is refused (exit 4 — its content stopped being `ready` since the preview, e.g. a channel disconnected in the meantime), park that row: retry the identical call without `--scheduled-at` to at least save it as a draft, note the reason, and keep going with the rest of the batch.
7. **Verify.** Call `posts_list` for the scheduled window and confirm every booked row appears with the right time and channel. For any row still processing, call `posts_get` (CLI: `inklate posts get <id>`) and report the real state — there is no separate status call. Discrepancies between what was booked and what the queue shows are reported immediately, not glossed.
8. **Handle a mid-batch stop honestly.** Booking a whole week is many calls, so expect to be interrupted:
   - **Exit 7 (rate limited)** means the budget is spent and the message names the wait. Report which rows are booked, which are not, and the wait — then offer to resume. Never report a half-booked week as done, and never abandon it as failed.
   - **Exit 6 (conflict)** means that post's state forbids the booking (already published, channel disconnected). Park that row with the reason and keep going with the rest.
   - Rerunning a row that already succeeded is safe when it carries the same idempotency key from step 6.
9. If the plan spans more than one week, book week by week — approve and verify week one before proposing week two, so a mid-plan change of mind never strands half-booked rows.

## Quality bar

- Never book a row that previewed as not `ready`; parked rows appear in the receipt as unscheduled with the reason.
- All times are stated and booked in the organization's timezone; if the plan's times imply a different timezone, resolve the conflict with the user before proposing.
- Spacing rule is hard: no two posts on one channel within 3 hours. Nudges made to satisfy it are listed explicitly.
- The proposed-schedule table shown for approval must match what was actually booked — no drift between preview and booking.
- Verification via `posts_list` is not optional; the receipt reflects the queue's reality, not the request you sent.
- If the plan exceeds the cadence in social-context.md by more than double, say so once before proposing — then respect the user's call.
- Every row in the receipt carries its post ID so the user can edit or unschedule any single slot later without archaeology.

## Receipt

End with the booked week as verified against the queue:

| Day        | Time (org tz) | Channel   | Post ID     | Content                            | Status                     |
| ---------- | ------------- | --------- | ----------- | ---------------------------------- | -------------------------- |
| Mon Jul 20 | 9:00 AM       | LinkedIn  | post_abc123 | "Why we killed our roadmap…"       | scheduled                  |
| Mon Jul 20 | 1:00 PM       | X         | post_abc124 | Thread: roadmap lessons (6 tweets) | scheduled                  |
| Wed Jul 22 | 10:00 AM      | Instagram | post_abc125 | Carousel: 5 lessons                | processing (media pending) |

Below the table: total posts booked, any rows parked with reasons, any spacing nudges applied, and the `posts_get` state for anything not yet confirmed on the calendar.

Every row in this table was verified against `posts_list` — it is the queue's account of the week, not the request's.