mariadb-operator-comment

mariadb-operator 评论

向 mariadb-operator/mariadb-operator（或用户指定的其他仓库）发布评论或 PR 审查意见。此技能只负责发布——如果内容是代码审查，请先运行 mariadb-operator-pr-review（或者使用本次对话中已生成的审查结果），然后将结果交给此技能进行格式整理和发布。

未经确认，绝不发布

这条规则比下面的任何内容都重要。 在 GitHub 上发布内容是公开操作，而且很难彻底撤销（编辑和删除都会留下审计记录，并且人们可能已经读过通知），整个团队都能看到。调用任何实际发布内容的工具之前：

1. 完整展示即将发布的确切文本——不能改写或概述。
2. 准确说明发布位置：owner/repo#number，以及发布类型是普通评论、审查评论，还是正式审查（注明其结论，例如“请求更改”）。
3. 使用 AskUserQuestion 询问用户是否确认（选项可设为“发布”／“先编辑”／“取消”）。如果用户没有回应、回复含糊不清，或转而讨论其他主题，都视为“否”——不得自行推断并发布。
4. 只有在用户明确同意后，才能调用发布工具或 gh 命令。

如果用户一开始就要求你“直接发布”，仍须先展示最终文本并获取一次明确确认，再调用工具——要求发布本身并不等于确认具体要发布什么，因为你可能在用户看到内容后对其进行了格式整理或概述。

GitHub 凭据

此技能每次调用 GitHub（发布评论或正式审查）时，都要按以下顺序选择访问方式，仅当上一种方式不可用时才尝试下一种：

1. 项目专属的 GitHub MCP 工具（名称类似 mcp__github-mariadb-operator__add_issue_comment、 mcp__github-mariadb-operator__pull_request_review_write、 mcp__github-mariadb-operator__add_comment_to_pending_review）。这些工具可能显示为延迟加载工具；如果是这样，请先使用 ToolSearch 加载其架构（例如： ToolSearch({query: "select:mcp__github-mariadb-operator__add_issue_comment", max_results: 1})），然后再调用。
2. 使用项目专属令牌的 gh CLI，前提是 mariadb-operator MCP 服务未连接。明确使用 GITHUB_MARIADB_OPERATOR_TOKEN（GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh ...），不要使用当前 gh auth 会话中的令牌。
3. 通用 GitHub MCP 工具（mcp__github__*），前提是上述两种方式均不可用。
4. 使用默认凭据的 gh CLI（普通 gh auth，不显式指定令牌），仅当前面所有方式都不可用时才作为最后手段。

步骤 1 — 确定目标

除非用户指定其他仓库，否则默认仓库为 mariadb-operator/mariadb-operator。从用户消息或粘贴的网址（github.com/<owner>/<repo>/(issues|pull)/<n>）中获取议题／PR 编号。如果无法确定目标是议题还是 PR，对于普通评论通常没有影响（GitHub PR 在底层也是议题，因此两者使用相同的评论端点）——只有发布正式 PR 审查（步骤 3）时才有影响，因为这要求目标必须是真正的拉取请求。

步骤 2 — 整理评论正文

两个常见来源：

• 直接请求：用户提供文本，或给出简短的撰写指示（例如“告诉他们修复看起来不错，但询问迁移路径”）。用维护者评论的语气起草：简洁、具体、不说废话。
• 来自 mariadb-operator-pr-review 的输出：如果本次对话中已经有结构化评审（结论表 + 各维度的发现），或用户要求生成一份评审，那么其 Markdown 输出格式已经可以直接放入 GitHub 评论——尽量照原文使用，而不是重新概括成含糊的内容。不要为了缩短内容而悄悄删掉发现；如果进行了删减，请告诉用户删掉了什么。

保持最终渲染的正文为将在 GitHub 上显示的 Markdown 原样——这是你在步骤 4 中展示给用户的内容，也是你在步骤 5 中发布的内容，因此两者不应有出入。

步骤 3 — 选择普通评论还是正式评审

• 普通评论（默认）：在 issue/PR 时间线中发布一条评论。适用于以单篇汇总内容呈现的评审（常见的 mariadb-operator-pr-review 输出）、状态更新、问题，或任何没有对应到特定差异行的内容。更简单，而且默认选择简单方案是合适的——只有当发现确实需要逐行对应时，才采用正式评审。
• 带行内评论的正式 PR 评审：仅当用户明确要求将发现附加到差异中的确切行（例如“在每条发现上留下行内评论”），且每条发现都有明确的 file:line 时使用。这需要先创建待提交的评审，再添加行内评论，然后提交——参见步骤 5。不要默认采用这种方式；一条格式清晰的评论足以应对常见情况，也便于用户在发布前审阅。

步骤 4 — 向用户展示将要发布的确切内容，然后暂停并询问

原样呈现：

Target: <owner>/<repo>#<number> (<issue|PR>)
Mode: <plain comment | formal review: VERDICT>

--- comment body ---
<full rendered Markdown>
--- end ---

然后调用 AskUserQuestion，询问用户是要发布、编辑还是取消。未经明确答复“发布吧”，不得继续。此处是上文所述的硬性关卡——步骤 5 中的任何操作都不能提前执行。

步骤 5 — 发布

根据 GitHub 凭据部分选择访问方式，然后使用该方式发布。

普通评论：

• MCP（项目范围或通用）：使用 add_issue_comment，并提供 owner、repo、issue_number、body——适用于 issue 和 PR。
• 使用项目令牌的 gh CLI：

  GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  # or for a PR:
  GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh pr comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  

• 使用默认凭据的 gh CLI（移除 GH_TOKEN 覆盖，依赖当前环境中的 gh auth）：

  gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  # or for a PR:
  gh pr comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
  

  对于这两种 gh CLI 方式，如果正文较长或包含对引号敏感的字符，请通过 --body-file 传递正文（先将其写入临时目录），而不是使用 --body——这比费力处理 shell 转义更安全。

带行内评论的正式评审：

• MCP（项目范围或通用）：使用 pull_request_review_write 创建待提交的评审；对每条发现调用一次 add_comment_to_pending_review（每次都需要 path、line 和该发现的正文）；然后通过 pull_request_review_write 提交待定评审，并附上总体结论（评论 / 批准 / 请求更改）。
• gh CLI 没有简洁的方式来完成包含多条行内评论的评审——如果没有可用的 MCP 服务，而用户又想要行内评论，请说明这一点，并提供普通评论作为替代方案，不要尝试不可靠的变通方法。

发布后，向用户确认并附上刚刚发布内容的链接或引用——不要只说“完成了”。

此技能不做什么

• 它不会决定 PR 应该说什么——这由 mariadb-operator-pr-review（或用户自己的文字）负责。本技能只负责格式整理和发布。
• 除非用户明确要求，否则不会编辑或删除现有评论；编辑或删除操作同样必须经过确认。