SKILL.md
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 → PUBLISHEDA 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
postey://posts/{post_id}/publish-status— per platform, not per post.- If a platform is missing from
published_platformswhile listed insocials, 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.
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 |
needsattention on an account is the most common root cause and the cheapest to check. A platform in RECONNECTIONREQUIRED 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 recordIf 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.
restorepost takes one id; restoreposts 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.