message-send

Message Send

Govern a message sent on behalf of a principal: a channel post or a reply in a bound conversation. The skill never receives a provider token, never lets approved content drift before delivery, and calls a message delivered only after the provider reads it back.

Composes

• slack#read_thread

Runners

• send (default): plans one channel post, requests approval only at the live post, posts once, and requires independent readback.
• plan: the provider-neutral authorization step. It binds the principal, audience, content digest, consent basis, preflight checks and approval gate into a runx.message_send.plan.v1 packet, and never delivers.
• plan_post: validates a channel name, channel id, or exact slack://workspace/channel destination, computes the message digest with Runx's native data.digest, and binds that digest, the named principal and the send intent through plan. It does not post and needs no approval.
• plan_post_exact: for an operator that has already selected one exact destination, principal and text under its own policy. It reuses the same validation and digest and emits the same undelivered runx.notify.v1 plan without a second model judgment. Its send_plan.origin is message-send.exact, not a claim that plan ran.
• post: accepts only an exact notify_plan, the matching destination and text, and a stable UUID idempotency key. It recomputes the digest, compares the complete binding, stops unless exact native approval or a matching standing notification authority is present, runs channel.post through the configured binding, then reads the returned message locator back with channel.post.read and seals only the bounded evidence fields.
• reconcile_post: reads back a post whose delivery outcome was ambiguous, without posting again.
• reply: delivers one admitted reply to a bound conversation. The operator supplies the exact source packet, thread, draft, provider and native turn identity. The skill holds unless the source proves complete coverage, then asks for exact approval, runs thread.reply on the chosen connector, and requires thread.reply.read to resolve a stable message locator with the matching content digest. An accepted or queued request alone leaves the work held for reconciliation.