Publora

View saved version →

---
name: publora-linkedin-engagement
description: >
  Comment, react and reshare on LinkedIn through Publora, including supported
  mentions and comment images. Use for responding to an existing post.
  LinkedIn analytics are not exposed by these tools.
---

# LinkedIn engagement

These actions affect real LinkedIn posts under the connected account's name.
Use the exact target and content authorized by the user; clarify missing
details, but do not repeat confirmation already given for those exact details.

## Account and target

Call `list_connections` and use the returned LinkedIn `platformId` verbatim.
If it is absent or needs reconnection, link to
[Publora Channels](https://app.publora.com/dashboard/accounts) and recheck
after connection. These personal tools do not substitute for Agency tools.

For comments and reactions, `postedId` accepts an exact activity, share or
ugcPost URN. From a supplied LinkedIn activity URL, preserve its exact numeric
activity ID as `urn:li:activity:<id>`. Do not change the prefix to share or
ugcPost to guess another identifier. Follow the specific tool's schema:
reshare `parent` has its own accepted URN forms.

## Actions

| Action | Tool | Removal |
|---|---|---|
| React | `linkedin_create_reaction` | `linkedin_delete_reaction` |
| Comment or reply | `linkedin_create_comment` | `linkedin_delete_comment` |
| Reshare to the feed | `linkedin_create_reshare` | No published-reshare deletion tool |

Show drafted commentary before posting it unless the user already supplied
and approved the exact text. A vague request for a nice comment is not
approval of an invented message. Do not add a promotion, hashtags or emoji
unless requested. Deleting a comment loses the original text and requires
authorization for that specific comment.

Comments use `message` (up to 1,250 characters), optionally `parentComment`
for a reply and `imageUrl` for a supported public image. Check the live schema
for image format/size limits; a successful response does not guarantee an
unsupported image will render. Do not attach video or documents to comments.

## Mentions

Use `linkedin_list_mentionables` for native app-scoped person IDs captured
from engagement on connected company pages. A name or public profile slug
is not a native mention ID. Absence from the result does not prove the person
never engaged; say that no usable mention ID was returned.

When using a person's own connected account ID, follow the tool schema to
remove the leading `linkedin-` from the connection ID before constructing a
person URN. Never substitute an ID from a linkedin.com profile URL.
Use the native IDs and mention format accepted by `linkedin_create_comment`.

## Reshares

Use `linkedin_create_reshare` with the real parent URN, account and approved
commentary. Follow its current visibility and parent schema. It does not
modify the original post. `delete_post` cannot remove a published LinkedIn
reshare; direct the user to LinkedIn for that action.

For a scheduled repost supported by personal `platformSettings.linkedin`,
use the canonical share/ugcPost URN accepted by that field, not an activity
URN. Follow `publora-publishing` for draft and scheduling operations.

## Errors and retries

- `LINKEDIN_DAILY_LIMIT_REACHED`: the request was not sent. Explain the
  returned limit and retryAt; wait until that time, never loop immediately.
- `LINKEDIN_COMMENTS_RESTRICTED`: terminal for this target. Do not retry or
  invent another URN; explain the restriction.
- Respect other provider/rate-limit responses. Backend-reported limits take
  precedence; do not hardcode plan budgets or self-throttle from defaults.
- These engagement tools do not accept `idempotencyKey`. After an uncertain
  write outcome, inspect available evidence or have the user check LinkedIn
  before repeating a comment or reshare.

Do not bulk-engage or repeat comments across a feed. Do not invent LinkedIn
metrics. Publora's exposed statistics tools cover personal Instagram, Bluesky
a

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: publora-media
description: >
  Attach images or video to Publora posts from a chat file, public URL or
  uploaded bytes, and resolve media errors before scheduling. Use when a post
  needs media, an upload is pending, or an attachment blocks publication.
---

# Media in Publora

For personal posts, use the paths below. Agency client posts use
`company_reserve_media`, `company_complete_media`, `company_delete_media`
and `company_list_post_media`; follow the Agency flow in
`publora-publishing`. Never mix their media IDs or post IDs.

Finish the media work before scheduling. An attachment operation does not
authorize publication or rescheduling.

## File from the conversation

1. Create a personal draft with `create_post`, omitting `scheduledTime`
   and `publishNow`, or use the existing authorized draft.
2. Call `attach_media` with its `postGroupId` and the real file reference
   accepted by the current host's `file` parameter. Optional `fileName`
   changes the stored filename.
3. Verify the attachment is ready with `get_post`.

The host resolves the file to a temporary download URL for Publora. Do not
invent a URL, paste base64, or send a sandbox path as a download URL. If the
host exposes an absolute-local-path file parameter, supply an actual file
there. If it cannot resolve the file, use a public URL or upload the bytes.

One file per call. No PUT or `complete_media` is needed for this path.
`attach_media` leaves the post in draft and demotes an already scheduled post.
Explain that effect before changing a scheduled post; restore only the schedule
the user has authorized. Retrying the same attachment uses the same post,
file identity, filename and idempotency key.

## Public file URL

Pass `mediaUrls` to `create_post` or `update_post`. Publora fetches and
stores the file on its servers.

- Use direct public HTTPS file URLs, not Google Drive/Dropbox share pages.
- Images: jpeg, png, gif, webp, tiff, avif, up to 25 MB.
- Videos: mp4, mov, webm, up to 150 MB.
- Up to 10 files; each target may impose a lower limit or other format rules.

`update_post.mediaUrls` appends files; it does not replace existing attachments
or unfinished upload slots. Inspect `get_post` before adding replacements.
Report download/validation errors accurately. A private or expired link needs
repair; a repeated call with the same unusable link will not help.
For drafts omit publishing fields. Schedule separately after content/media
approval, using the current `update_post` schema.

## Upload bytes

Use this route only if you can read the bytes and perform the PUT.

1. `get_upload_url` with postGroupId, a unique filename, contentType and type.
2. PUT the exact bytes to the returned uploadUrl with the same Content-Type.
   Do not send a Publora credential to storage.
3. `complete_media` with the returned mediaId.
4. `get_post` to verify ready before scheduling.

For the same unfinished upload, identical postGroupId/fileName/contentType/type
reissues the same slot. Use distinct filenames for distinct files.

- `MEDIA_UPLOAD_PENDING`: upload the bytes before retrying completion.
- `MEDIA_VALIDATION_PENDING`, or `retryable: true` with
  `WAIT_AND_RETRY_SAME_MEDIA`: wait retryAfterSec, then repeat
  `complete_media` with the same mediaId. Do not reserve another slot.
- Follow the server's nextAction for other failures. Never label pending
  media ready or schedule while validation is incomplete.

## Repairing attachments

Read `get_post.media` to identify the exact attachment and state.

- Use `delete_media` for an existing duplicate or unfinished reservation
  only when the user's request authorizes discarding that specific file.
- Use `prune_media_reference` for `MEDIA_REFERENCE_MISSING` when the
  reference remains but the MediaFile record is absent or inaccessible.
- Deleting media from a scheduled post demotes it to draft. Inspect the
  resulting state and restore the authorized schedule only after repair.
- A failed upload alone is not permissi

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: publora-publishing
description: >
  Draft, schedule, publish and edit social posts through Publora, and inspect
  the queue or supported Instagram, Bluesky and Mastodon statistics. Use for
  personal publishing, Agency client work and Workspace webhook subscriptions;
  keep their tools and IDs separate.
---

# Publishing with Publora

Follow the user's requested scope. For a first post, prepare a draft, agree on
the text, then choose a publishing time. A request for accounts or examples
does not authorize a write. Confirm missing details; do not ask again when
the user already approved the exact content, accounts and action.

Use the tools actually exposed by the client. If a documented tool or argument
is missing, explain that the connection needs an update. Do not send unknown
fields or substitute a different publishing action.

## Choose the account context

For personal posts, call `list_connections` and copy each `platformId`
verbatim into `platforms`. Never infer IDs from names. If a target is missing
or needs reconnection, link to [Publora Channels](https://app.publora.com/dashboard/accounts)
and recheck after the user connects it. Pinterest is connect-only.

For Agency client work, use the Agency flow below. Personal tools cannot
access Agency content. Never substitute personal accounts when Agency tools
or permissions are unavailable.

## Personal drafts and scheduling

| Intent | Call |
|---|---|
| Create a draft | `create_post` with content and real targets; omit `scheduledTime` and `publishNow` |
| Schedule a new, approved post | `create_post` with `scheduledTime`; omit `publishNow` |
| Schedule an existing draft | `update_post` with its `postGroupId`, `status: "scheduled"` and `scheduledTime` |
| Publish immediately, when explicitly requested | `create_post` or `update_post` with `publishNow: true`; omit `scheduledTime` and `status` |

Reuse a saved draft instead of creating another. Read its current state before
editing when needed. Publish Now uses server time and is asynchronous; a
successful call is not proof of publication. Do not emulate it by inventing
a future publishing time.

After draft approval, obtain any missing date, time and time zone. Show the
exact local time and zone; convert it to ISO 8601 UTC or an explicit offset.
Read `account_context` before a batch, to check a schedule horizon, or after
a quota/feature error. Supply the intended `scheduledTime` for the relevant
quota period; omit it for Publish Now. The snapshot does not reserve quota.
A full deferred queue does not itself block Publish Now if monthly quota remains.
Do not switch a scheduled request to Publish Now to bypass a limit.

Inspect returned warnings and the stored effective time. Verify with
`get_post`; report the ID, actual targets, status and time in the user's zone.
If scheduling fails, keep the draft and explain the required repair.

## Content and media

Use current tool schemas, connection capabilities and backend validation as
the authority. Common text limits are:

| Network | Text limits |
|---|---|
| X | 280 weighted characters; up to 25,000 for eligible Premium accounts |
| Threads | 500 per part |
| Mastodon | Usually 500; instance limits may differ |
| Instagram / TikTok | 2,200 |
| YouTube | 5,000 description; 100 title |
| LinkedIn | 3,000 |
| Bluesky | 300 graphemes; UTF-8 byte limits also apply |
| Facebook | 63,206 |
| Telegram | 4,096 text; 1,024 for bot media captions |

X and Threads can split long content into a chain. A standalone `---` line
sets a break; media attach to the first part. Do not silently truncate or drop
targets. Explain splitting or propose an edit when the result would differ
from the requested format. Threads may require reconnection for
`threads_manage_replies`. After partial publication, inspect the result;
never recreate the entire chain or guess what reached the network.

Instagram and TikTok need media; YouTube needs a video. Follow
`publora-media` and verify attachments are

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: publora-setup
description: >
  Help a user start with Publora: show connected accounts with example prompts,
  connect a missing social account, or prepare and schedule their first post.
  Use for first-run help and requests for accounts plus examples. A request only
  to list accounts or check the queue does not require a guided first-post flow.
---

# Get started with Publora

Follow the user's current request. The Try now prompt asks for accounts and
examples; it does not authorize creating a post. This skill can also be chosen
from a first-post request without any setup button.

## Accounts and a useful next step

This section is for personal accounts. If the user explicitly chooses Agency
client work, follow the Agency flow in `publora-publishing`: discover the
workspace with `company_list_contexts`, read its capabilities with
`company_get_workspace_context`, then use separate `company_*` operations
and channel keys from `company_list_channels`.
If those tools are unavailable, explain that limitation instead of substituting
personal accounts. Keep the same draft-first sequence in either context.

Call `list_connections`. Use actual account names, exact `platformId` values,
and connection status from the result. If authorization or the tool fails,
explain how to reconnect/retry; do not describe the failure as an empty list.

If accounts are connected, show them and two short examples adapted to an
active account (or use explicit placeholders):

- "Draft a post about [topic] for my [account]."
- "Schedule this draft for [date] at [time] [time zone]."

If there are no accounts, link to [Connect a social account in Publora](https://app.publora.com/dashboard/accounts).
Explain the steps: sign in to the same Publora account used by the plugin,
choose the social network, follow its connection instructions and select the
account/page if asked, then return and say "Check my connected accounts."
For Telegram and networks that use credentials, follow the dashboard's own
instructions rather than asking for credentials in chat.

If all accounts require reconnection, use the same dashboard link and ask the
user to reconnect one. If only some require reconnection, offer an active one
and identify the others clearly. Recheck connections after the user returns.

A user can prepare text in chat before connecting an account. Do not invent a
Publora draft ID or call `create_post` until a real target is available.

## From a draft to the first scheduled post

When the user wants to continue, ask for the missing topic and target account.
Use choices and content they have already provided. Prepare the text for
review before asking for a publishing time. Saving a draft uses `create_post`
without `scheduledTime` or `publishNow`; follow the packaged `publora-publishing` skill for
exact target IDs and post operations. For media requirements, follow
`publora-media`; a text proposal can be reviewed in chat before adding media.

After the user approves the draft, obtain the missing date, time and time zone.
Summarize the approved content, target and exact local time with its time zone.
Schedule on the user's confirmation; do not ask again if their latest request
already approves those exact details. Convert the chosen time to UTC.
Check `account_context` for the schedule horizon or quota errors when needed;
never switch to immediate publication to bypass a scheduling limit.

If a saved draft already exists, schedule that draft with `update_post`, keeping
its `postGroupId`, with `status: "scheduled"` and the agreed `scheduledTime`,
rather than creating a duplicate. Omit `publishNow`. Read its current state first
when needed and verify required media are ready. For an uncertain
write result, inspect the existing post before retrying; reuse the same
idempotency key and identical body for the same operation, when the tool
supports that key. If the current client lacks a required tool or argument,
explain the connection-update requirement; do not

Preview of the first 4,000 characters. Read full instructions →