# Postey Ops

> Know whether the things you scheduled actually went out, find the ones that failed, and fix them. Publishing is asynchronous — created is not published, and scheduled is not published either.

- Skill: `posteyai/postey-ops` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add posteyai/postey-ops`
- Raw SKILL.md: https://api.skillmd.com/api/skills/posteyai/postey-ops/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: posteyai (https://skillmd.com/u/posteyai)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/posteyai/postey-ops

---


# Postey Ops

## The thing this skill exists for

**Publishing is asynchronous, and every status short of `PUBLISHED` means it has not gone out.**

```
DRAFT → SCHEDULED → PUBLISHING → PUBLISHED
```

A successful `schedule_post` call means the job was accepted. It says nothing about whether the
platform took the post. A post can sit in `PUBLISHING`, or reach `PUBLISHED` on one platform and
fail on another in the same post, because each platform publishes independently.

**Never tell the user something published because the call that scheduled it returned success.**
Read `postey://posts/{post_id}/publish-status` and say what it actually says.

## Checking a post

1. `postey://posts/{post_id}/publish-status` — per platform, not per post.
2. If a platform is missing from `published_platforms` while listed in `socials`, that platform did
   **not** go out. That is the single most useful signal in the system and the easiest to miss:
   the post looks published because one platform succeeded.
3. `postey://notifications` — this skill's half is notifications about **posts**: publish failures,
   token expiry, quota. Notifications about **people** (comments, mentions) belong to
   `postey-engagement`.

## Common causes, in the order worth checking

| Symptom | Check first |
|---|---|
| one platform missing, others fine | that account's connection — `postey://accounts` reports `needs_attention` per platform |
| everything stuck in `SCHEDULED` past its time | the scheduler worker, not Postey's API |
| `PUBLISHING` for a long time | a platform accepted the upload and has not confirmed; video is slower |
| published but no `live_link` | it went out; the link fetch lagged. Not a failure |
| nothing scheduled that the user expected | the schedule was never created, or was created on a different account |

`needs_attention` on an account is the most common root cause and the cheapest to check. A platform
in `RECONNECTION_REQUIRED` will fail every publish silently until someone reconnects it, and the
draft looks perfectly healthy.

## Reporting

Say per platform, with the status, not "it published". The user cares which ones landed:

```
post 10168
  LINKEDIN   PUBLISHED   2026-07-26 17:30   live_link present
  X          not in published_platforms — the account shows twitter RECONNECTION_REQUIRED
  THREADS    listed in socials, no publish record
```

If something failed, say what to do: reconnect the platform, restore the post if it was deleted, or
recreate and re-schedule. Do not retry a publish on the user's behalf without asking — a duplicate
post is worse than a late one, and the failure may have partially succeeded.

## Recovering a deleted post

Read `postey://accounts/{account_id}/trash` before recreating anything. A post the user deleted by
mistake is still there, and restoring it keeps its id, its per-platform copy and its comment
history — recreating loses all three.

`restore_post` takes one id; `restore_posts` takes several. Both return the post to DRAFT, never to
its previous SCHEDULED or PUBLISHED state, so a restored post still needs the user's explicit yes
before it goes anywhere. Say what you found in the trash and let the user pick; do not restore a
batch on the assumption every deletion was accidental.

## Cadence

`get_schedule` and `postey://accounts` give the queue. When asked to plan cadence, the constraint
is what the account can sustain, not what the platform allows. An empty queue next week is a more
useful thing to report than an optimal posting time.

Scheduling itself is the hub's (`schedule.create`), and **scheduling counts as publishing**: it
needs the user's explicit approval, because a scheduled post publishes itself.