posteyai/skills · Archived

postey-teams

Run content past a reviewer before it goes out: who is on the team, what they said on a draft, how a share link gets a client's approval, and what "approved" does and does not mean in Postey.

Installation

$ npx skills add posteyai/skills --skill postey-teams

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Also in this package

Other skills from posteyai/skills.

npx skills add posteyai/skills

Browse all from posteyai/skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 6
License LICENSE
Default branch main
Open issues 0
Status Archived

Skill metadata

Parsed from SKILL.md frontmatter.

Version1.0.1

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 5,000 B
  • docs SUMMARY.md 211 B

History

  1. First recorded snapshot · 4 installs

SKILL.md

Postey Teams

Approval is a convention, not a state

Postey has no APPROVED status. PostStatusEnum is DRAFT | SCHEDULED | PUBLISHING | PUBLISHED. Nothing in the system records that a human said yes.

That has three consequences, and getting them wrong is how content goes out unreviewed:

What is true What it means for you The failure it prevents
A draft carries no approval flag Approval lives in an internal comment, a message, or a conversation. Read it; never infer it. Treating a status as consent
Silence is not approval If asked whether something is cleared, say who said what and when — never "no objections were raised" Reporting absence of dissent as sign-off
Nothing stops a DRAFT publishing The status does not protect it. Only the rule that publishing needs explicit instruction does, and that rule lives in the agent, not the server. Assuming the server will catch you

When the user says "it's approved", that is the approval. Take it from them, and say whose approval you are acting on.

Internal comments are the review record

postey://posts/{post_id}/comments/{platform} holds team notes — visible inside Postey, never published. They work on a post in any status, not just drafts.

Read them before drafting a revision. The most common failure in a review loop is rewriting a post while ignoring the note that says what was wrong with it.

Internal comments are not audience comments. Confusing the two means treating a colleague's note as public feedback — or worse, drafting a public reply to an internal note.

Internal comments Audience comments
Who wrote it A teammate or client, inside Postey A real person on the live post
Reach Never published Public
Read via postey://posts/{post_id}/comments/{platform} getplatformcomments
Owned by This skill postey-engagement
A reply goes Back into Postey Out to the public

Share links

resolvesharelink resolves a Postey share URL or share_id to the underlying post. Use it when someone pastes a link — the reviewer often has only that.

A share link is how a client who has no Postey account sees a draft. Two things follow: the recipient may not be in the team list, and anyone holding the link can read the draft. Do not put anything in a draft you would not send to whoever might be forwarded that link.

Teams

postey://teams and postey://teams/{team_id}/members say who exists and who can act. Read them before attributing a comment or asking "who should approve this?" — guessing a reviewer's name in front of a client is a small error with an outsized cost.

An account can belong to several teams, and identities can be shared across accounts (sharesidentitywith in postey://accounts). Two account entries pointing at the same underlying identity will publish to the same place. Check before assuming two accounts mean two audiences.

The routine that works

  1. Read the accounts and confirm which one this content is for.
  2. Draft. Everything stays a DRAFT.
  3. Hand over the share link and say explicitly who needs to approve.
  4. When they respond, read the internal comments and the user's own words.
  5. Revise against what was actually said, and show the diff.
  6. Publish or schedule only on explicit instruction — and scheduling counts as publishing.

Step 6 does not become optional because step 3 happened. A reviewer approving a draft is not the user telling you to publish it.