posteyai Postey Engagement
Replying is the highest-frequency thing an account owner does and the easiest to do badly. A generic reply is worse than no reply: it is public, it is attributed to them, and it reads as automation.
Read before replying
- Accounts first —
postey://accounts, orget_accountsif your client cannot read resources. - The post, then the comment. Read the post's own text
(
postey://posts/{post_id}/content/{platform}) before drafting a reply. A reply that misreads its own parent is the most common failure here. - Notifications about people are this skill's half of
postey://notifications— new comments, mentions, replies. Notifications about posts (did it publish, did it fail) belong topostey-ops.
Audience comments, not internal ones
get_platform_comments reads what real people wrote on the live post. Internal comments —
teammate and client notes inside Postey, read via postey://posts/{post_id}/comments/{platform} —
belong to postey-teams and are never published. Replying to one with reply_comment puts a
colleague's private note on a public timeline. Check which kind you are holding before you draft.
Triage — decide before you draft
| The comment is | Do |
|---|---|
| a genuine question | answer it, specifically, and stop |
| praise | thank briefly, add one concrete detail, do not pitch |
| a correction that is right | say so plainly and thank them; never argue a losing point in public |
| a correction that is wrong | reply once with the evidence; do not reply twice |
| hostile, or bait | do not reply. Say so and move on |
| spam or a scam | do not reply. Suggest the user report it |
| anything about a person's health, money, legal position, or safety | stop and hand to the user |
The last row is not negotiable. An agent replying on someone's behalf about a personal matter can do real harm, and the person on the other end has no idea they are talking to software.
Never reply to a comment on a post the user did not publish through Postey unless they ask — they may not have seen it, and a reply is the first they learn of it.
Tone
Match the platform's register — platform-archetypes.md in the hub carries it. LinkedIn is not X,
and a reply is more informal than the post it hangs off.
If a brand profile exists (postey-voice), its voice and banned lists apply to replies too. Most
voice drift shows up in replies first, because they are written fast.
Three rules that survive every platform:
- Shorter than the comment. A reply longer than what it answers reads as a lecture.
- No links unless asked. A link in a reply reads as a funnel.
- Never open with the person's name if you are unsure of it. Getting it wrong is worse than omitting it.
Show the user before sending
reply_comment is a public write. Draft every reply, show them together, and send only
what the user approves. Batch approval is fine — silent sending is not.
Auto-DM funnels
configure_auto_dm sets up "comment X and I'll send you Y". Read the account's existing
automations first (postey://accounts/{account_id}/automations) — a second automation on the same
trigger word competes with the first.
Design rules:
- One trigger, one thing delivered. A trigger that sends different payloads depending on context will misfire and cannot be debugged from the outside.
- Say what happens in the post itself. "Comment PLAYBOOK and I'll DM it to you" is honest; a silent DM to anyone who comments is not, and platforms treat it as unsolicited messaging.
- Check the platform allows it before promising it. DM automation rules differ per platform and
change; read
postey://platforms/{platform}/rulesrather than assuming.
An automation the user forgot about is still sending DMs in their name. When listing automations, name every active one, not just the one being changed.
Arming one needs an explicit yes, in the turn you arm it. configure_auto_dm is not a draft.
Once it is live it messages every person who hits the trigger, with no further review, for as long
as it stays on. Show the user the trigger word, the exact payload, the account and the post it
attaches to, and wait for them to approve that. This is a stricter gate than replies get: a batch of replies is a
finite list the user can read, while one armed funnel keeps messaging strangers after the
conversation ends. One arming, one yes — batch approval does not carry here. A request to "set up a funnel" is not approval of the message it will send.