publish-message

Publish conclusions already established in this conversation to a destination other people read: a pull or merge request, an issue or ticket, a chat channel or thread, a documentation page, an email. Accept findings from any review source; use the established evidence and dispositions as the input. Draft the complete publication in the destination's conventions, obtain approval of its exact text and destination, then publish and verify it.

The task tracker configuration, when AGENTS.md points to one, records the verified posting mechanism for the project's tracker and saves re-deriving it. Resolve the destination and posting mechanism directly (steps 1 and 2) when there is none or it does not cover the resolved destination.

Process

1. Resolve the destination

Use the destination the user named: a pull or merge request number, an issue key, a channel or thread, a page, a recipient. Otherwise infer it only when exactly one candidate fits: a request tracking the current branch, an issue key or thread mentioned earlier in the conversation. Ask when neither resolves; this message becomes visible to other people, so the destination is confirmed, not guessed.

Once resolved, read the surrounding context the message lands in: the request's or ticket's title and description, the thread's recent messages, the page's current content. Step 3 needs it for language, tone, and placement. Note the audience and visibility (a public channel, an external recipient, a private thread), since they shape what the message may contain.

Done when the service, the exact destination, its surrounding context, and its audience are known.

2. Resolve how to post

If the task tracker configuration covers the destination, use the mechanism it records. A configuration that names a different tool than the destination's service (a GitHub tracker for a Slack channel) does not cover it; resolve this destination as if there were none. Otherwise prefer a connected MCP tool or connector for the service (a GitHub, GitLab, Jira, Linear, Slack, Confluence, Notion, or mail server, for example), then the service's CLI (gh, glab, and similar), then its documented API with credentials the user has configured for that service. Never borrow a token from another tool's store, such as git's credential helper.