turn your shipped work into posts you approve

the routine

send the release notes you have cleared for public use, including the release link and anything still private. drafting in chat needs no social connection. connect x only if you want the bot to post after review.

every friday at 1pm, use only this week’s approved shipping notes i supplied in this chat. draft two possible posts for x: one explaining a user-visible change, one showing a practical use for it. if there is no approved change, skip the drafts and say why.

put the source note beside each draft and flag anything whose availability is unclear. use the public link i supplied; do not make one up. never add customer names, usage numbers, testimonials or claims that the notes do not support. omit private roadmap items.

leave everything in chat. do not publish, reply, message anyone or change the account. when i ask you to publish a reviewed draft, post exactly that wording. if i edit the wording, use that version.

when

fridays at 13:00, after approved shipping notes are available in the chat

needs

approved release notes; optional twitter connector for x posting, with your own composio project key and auth config

what comes back looks like this (an example, not a real inbox)

post options for sam’s fictional product, cedar notes

option a: cedar notes now lets you rename a saved view. open the view and choose a name that matches the work.
source: sam’s approved shipping note, “rename saved views”.

option b: keep a saved view called “handover” for the items you discuss with priya. the new rename option lets you give an existing view that name.
source: the same shipping note; the handover scenario is an illustration.

held back: jo’s mobile layout work is still private.
needs review: no public release url supplied. neither option posted.

start with shipped work you can point to

a merge, a draft announcement and a feature available to customers are different things. tell the bot which notes are approved and which audience can use the change. if rollout is uncertain, the draft should ask you a question rather than announce availability.

you can paste notes yourself. if you want to explore a repository connection later, read the github guide and choose its access separately. this routine does not require access to your code or private issues.

x needs a connection you configure

the twitter toolkit includes a create-post action, but its managed sign-in is unavailable. you need your own composio project key and auth configuration to connect x.³ do that setup before expecting the bot to publish. the x integration guide covers the connection.

keep Ask every time selected for sending. when you ask the bot to publish, review the text and account before pressing Allow. posting is a send, even when the text began as a draft. do not use a daily sending allowance if every post needs a decision. one exception: a bot on Full access with no sending rule of its own may send up to 25 a day without asking, so give full-access bots Ask every time under sending.⁴

a draft is not a publishing strategy

a draft can't tell you whether a post reaches the right people or sells anything. it also cannot infer your release status from missing notes. keep speculative benefits out of the final wording and check any linked page yourself.

for a longer explanation of a release, use the newsletter routine. edit the social post for its own reader instead of squeezing an entire issue into it. revisit the notes after a release changes so an old draft does not announce something that is no longer available.

the guard rails

• use only notes you have cleared for public release; exclude private roadmap material
• leave sending on Ask every time, with no daily allowance for posts
• check the destination account and final text on the send decision before Allow
• remove unverified benefits, customer names and invented adoption numbers