publish-message

将本次对话中已经确定的结论发布到其他人可见的目标位置：拉取请求或合并请求、问题或工单、聊天频道或讨论串、文档页面、电子邮件。接受来自任何评审来源的发现；以已确认的证据和处理结论为输入。 按照目标位置的惯例起草完整内容，获取对确切文本和目标位置的批准，然后发布并验证。

如果 AGENTS.md 指向任务跟踪器配置，该配置会记录项目跟踪器已验证的发帖方式，避免重复推导。如果没有此类配置，或配置未涵盖已确定的目标位置，则直接解析目标位置和发帖方式（步骤 1 和 2）。

流程

1. 确定目标位置

使用用户指定的目标位置：拉取请求或合并请求编号、问题键、频道或讨论串、页面、收件人。否则，仅当恰好有一个候选项符合时才进行推断：跟踪当前分支的请求，或先前对话中提到的问题键或讨论串。若两者都无法确定，则询问用户；此消息会对其他人可见，因此必须确认目标位置，而不能猜测。

随后阅读消息将发布到的上下文：请求或工单的标题和描述、讨论串中的近期消息、页面的当前内容。步骤 3 需要这些信息来确定语言、语气和位置。记录受众及可见范围（公开频道、外部收件人、私密讨论串），因为这些因素会影响消息可以包含的内容。

完成条件：已知服务、确切目标位置、相关上下文和受众。

2. 确定发帖方式

如果任务跟踪器配置涵盖该目标位置，则使用其中记录的方式。若配置指定的工具与目标位置所属的服务不同（例如，用于 Slack 频道的 GitHub 跟踪器），则不算涵盖该目标位置；应按没有配置处理并重新解析。优先使用该服务的已连接 MCP 工具或连接器（例如 GitHub、GitLab、Jira、Linear、Slack、Confluence、Notion 或邮件服务器），其次使用该服务的 CLI（如 gh、glab 等），最后使用其文档所述的 API，并通过用户为该服务配置的凭据进行访问。切勿借用其他工具存储中的令牌，例如 git 的凭据助手。

仅在无法明确确定任何发帖方式时询问用户：存在多个可能适用的工具，且不清楚哪个能访问目标位置，或没有可用工具。如果没有任何方式能访问目标位置，步骤 5 会将获批文本交给用户。

完成条件：已确认一种能够访问目标位置的方式，或用户已知晓需要自行发布。

3. 起草完整的发布内容

说明结论、原因，以及足够的背景，帮助读者定位受影响的行为。 精简审查内容时，涵盖每项发现，并保留其处理结果、验证限制、未解决的要求以及仍需做出的决定。 在将已验证的本地更改描述为已合入目标分支之前，请先确认目标分支包含该更改。 否则，应将其描述为等待发布的本地更改，或说明其在目标分支中的状态尚未验证。

如果发布内容包含对 GitHub 或 GitLab 请求的行内建议，请阅读 inline-suggestions.md，了解发现项的放置位置、差异验证和提交处理。 否则，起草一条完整消息。

使消息适合发布媒介：

• 格式：使用目标平台支持的标记格式（GitHub 或 GitLab Markdown、Jira 或 Confluence 标记、Slack mrkdwn、纯文本或 HTML 邮件），并采用读者熟悉的结构：请求中的审查摘要、工单中的状态更新、聊天中先简短说明结论并在串回复中补充细节，或邮件主题行。
• 长度：与发布媒介相符。聊天和邮件应先说明结论并保持简短；审查摘要应涵盖每项发现。
• 位置：如果已有讨论串或对话，请在其中回复；仅在用户提出要求或不存在时才新建。
• 提及和收件人：仅包含用户指定的人员；提及会通知对方。
• 受众：不要包含外部或更广泛受众无法使用或不应看到的内部细节（文件路径、本地分支名、私有链接）。

使用目标位置已有的语言撰写，不一定要使用本次对话的语言。如果目标位置没有语言信号，则使用本次对话的语言；如无法确定，请先询问。

• 使用朴素的句子，以用户的口吻撰写，每个要点写成一个段落。
• 使用逗号、句号或连词连接意思。
• 如果项目的指导文件或风格指南对缩写有规定，请遵循。否则，首次出现时优先使用完整说法而非缩写（写“空值检查”，不要写“NPE”），除非代码库本身使用该术语：读者可能不熟悉相关技术背景。
• 仅保留读者理解或处理每个要点所需的背景和理由。

按照 unslop.md 的要求，去除消息和行内评论中的 AI 化表达，同时不改变其含义或语气。 完成标准：每项内容都是符合目标平台要求的精确草稿，并且每项发现都有明确的处理结果。

4. 审批完整的发布内容

列出服务、目标位置、收件人或提及对象，以及每项内容的完整最终文本，包括每条行内评论的文件、差异侧、行范围、原因和替换内容。 请用户确认由其负责发布这整套内容，并在发布任何内容前等待明确批准。 如果用户已批准这套确切内容及目标位置，则使用该批准。 任何修订后，都要展示修改后的内容并再次取得批准。 完成标准：已批准确切的内容和目标位置。

5. 发布并验证

对于单条消息，通过步骤 2 中的机制发布已批准的文本，然后从目标位置读取并检查文本及其位置。如果服务无法读取已发布内容，请说明这一验证限制。 对于包含内联建议的发布，请按照 inline-suggestions.md 中的提交处理流程操作。 如果没有任何机制能够到达目标位置，请以最终格式向用户提供已批准的文本，确保可直接粘贴。 报告已发布内容的 URL 或引用，包括任何部分结果。 完成条件：每个已批准的内容都已发布到其获批的目标位置，且文本与获批草稿一致（或者已交给用户，并说明该限制）；任何声明的建议数量都与实际发布的条目数量一致。