mariadb-operator-comment

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

mariadb-operator Comment

mariadb-operator 评论

Publish a comment or PR review to

mariadb-operator/mariadb-operator

(or another repo the user names). This skill only handles delivery — if the content is a code review, run

mariadb-operator-pr-review

first (or use its output if already produced in this conversation) and pass the result in here for formatting and posting.

向

mariadb-operator/mariadb-operator

（或用户指定的其他仓库）发布评论或PR评审。此技能仅处理交付——如果内容是代码评审，请先运行

mariadb-operator-pr-review

（或使用本次对话中已生成的输出），并将结果传入此处进行格式化和发布。

Never post without confirmation

未经确认绝不发布

This is the one rule that matters more than anything else below. Posting to GitHub is public, hard to fully undo (edits and deletions leave an audit trail, and people may already have read a notification), and visible to the whole team. Before calling any tool that actually publishes something:

Render the exact text you are about to post, in full — not a paraphrase or a summary of it.
State exactly where it's going:
```
owner/repo#number
```
, and whether it's a plain comment, a review comment, or a formal review (with its verdict, e.g. "Request changes").
Ask the user to confirm with
```
AskUserQuestion
```
(options like "Post it" / "Edit first" / "Cancel"). Treat silence, an ambiguous reply, or moving on to a different topic as "no" — do not post speculatively.
Only after an explicit go-ahead, call the posting tool or
```
gh
```
command.

If the user asks you to "just post it" up front, still show the rendered text and get one explicit confirmation before the tool call — the instruction to post is not itself the confirmation of what gets posted, since you may have formatted or summarized content since they last saw it.

这是比以下所有规则都重要的核心规则。发布到GitHub是公开操作，几乎无法完全撤销（编辑和删除会留下审计痕迹，且他人可能已查看通知），并会被整个团队看到。在调用任何实际发布内容的工具之前：

完整呈现即将发布的确切文本——而非释义或摘要。
明确说明发布位置：
```
owner/repo#number
```
，以及发布类型是普通评论、评审评论还是正式评审（需包含评审结论，例如“请求修改”）。
使用
```
AskUserQuestion
```
询问用户确认（选项如“发布”/“先编辑”/“取消”）。将沉默、模糊回复或切换到其他话题视为“拒绝”——不得推测性发布。
仅在获得明确许可后，才调用发布工具或
```
gh
```
命令。

如果用户一开始要求“直接发布”，仍需展示渲染后的文本并在调用工具前获得一次明确确认——发布指令本身并非对发布内容的确认，因为自用户上次查看后，你可能已对内容进行了格式化或总结。

GitHub credentials

GitHub 凭据

Whenever this skill calls GitHub — posting a comment or a formal review — pick the access method in this order, falling through only when the previous one is unavailable:

Project-scoped GitHub MCP tools (names like

mcp__github-mariadb-operator__add_issue_comment

mcp__github-mariadb-operator__pull_request_review_write

mcp__github-mariadb-operator__add_comment_to_pending_review

). These may show up as deferred tools — if so, load their schema with

ToolSearch

(e.g.

ToolSearch({query: "select:mcp__github-mariadb-operator__add_issue_comment", max_results: 1})

) before calling them.

gh
CLI with the project-specific token, if the
```
mariadb-operator
```
MCP server isn't connected. Use
```
GITHUB_MARIADB_OPERATOR_TOKEN
```
explicitly (
```
GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh ...
```
) rather than the ambient
```
gh auth
```
session.
Generic GitHub MCP tools (
```
mcp__github__*
```
), if neither of the above is available.
gh
CLI with default credentials (plain
```
gh auth
```
, no explicit token) as the last resort, if none of the above work.

每当此技能调用GitHub——发布评论或正式评审时，按以下顺序选择访问方式，仅当前一种方式不可用时才降级：

项目范围的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

加载其 schema（例如

ToolSearch({query: "select:mcp__github-mariadb-operator__add_issue_comment", max_results: 1})

）。

带有项目特定令牌的
gh
CLI，若
```
mariadb-operator
```
MCP服务器未连接。显式使用
```
GITHUB_MARIADB_OPERATOR_TOKEN
```
（
```
GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh ...
```
），而非环境中的
```
gh auth
```
会话。
通用GitHub MCP工具（
```
mcp__github__*
```
），若上述两种方式均不可用。
带有默认凭据的
gh
CLI（直接使用
```
gh auth
```
，不指定显式令牌），作为最后的备选方案，若以上方式均无效。

Step 1 — Resolve the target

步骤1 — 确定目标仓库

Default repo is

mariadb-operator/mariadb-operator

unless the user names another one. Get the issue/PR number from the user's message or a pasted URL (

github.com/<owner>/<repo>/(issues|pull)/<n>

). If it's ambiguous whether something is an issue or a PR, it usually doesn't matter for a plain comment (GitHub PRs are issues under the hood, so the same comment endpoint works for both) — it only matters if you're posting a formal PR review (Step 3), which requires an actual pull request.

默认仓库为

mariadb-operator/mariadb-operator

，除非用户指定其他仓库。从用户消息或粘贴的URL（

github.com/<owner>/<repo>/(issues|pull)/<n>

）中获取issue/PR编号。若无法明确是issue还是PR，对于普通评论通常无关紧要（GitHub PR本质上是issue，因此同一评论端点对两者均适用）——仅当发布正式PR评审（步骤3）时才需要明确，因为这要求是实际的拉取请求。

Step 2 — Assemble the comment body

步骤2 — 组装评论内容

Two common sources:

Direct ask: the user gives you the text, or a short instruction to write one (e.g. "tell them the fix looks good but ask about the migration path"). Draft it in the tone of a maintainer comment: concise, specific, no filler.
From
mariadb-operator-pr-review
output: if a structured review (verdict table + per-dimension findings) already exists in this conversation, or you're asked to produce one, its Markdown output format is already written to drop straight into a GitHub comment — use it close to verbatim rather than re-summarizing it into something vaguer. Do not silently drop findings to shorten it; if you trim, tell the user what you cut.

Keep the rendered body in Markdown exactly as it will appear on GitHub — this is what you show the user in Step 4, and what you post in Step 5, so there should be no gap between the two.

常见的两种来源：

直接需求：用户提供文本，或给出简短指令撰写评论（例如“告知他们修复看起来不错，但询问迁移路径”）。以维护者的语气撰写：简洁、具体，无冗余内容。
来自
mariadb-operator-pr-review
的输出：若本次对话中已存在结构化评审（结论表格 + 各维度发现），或用户要求生成此类评审，其Markdown输出格式可直接用于GitHub评论——应近乎原封不动地使用，而非重新概括为模糊内容。不得为缩短内容而静默删除发现；若需删减，需告知用户删减的内容。

保持渲染后的内容与将在GitHub上显示的Markdown完全一致——这是你在步骤4中展示给用户的内容，也是步骤5中发布的内容，两者之间不应存在差异。

Step 3 — Pick plain comment vs. formal review

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

Plain comment (default): one comment on the issue/PR timeline. Use this for a review delivered as a single consolidated write-up (the normal
```
mariadb-operator-pr-review
```
output), status updates, questions, or anything that isn't anchored to specific diff lines. Simpler, and simplicity is the right default here — only reach for a formal review when the findings genuinely need per-line anchoring.
Formal PR review with inline comments: only when the user explicitly wants findings attached to their exact lines in the diff (e.g. "leave inline comments on each finding"), and each finding has a concrete
```
file:line
```
. This requires a pending review that inline comments are added to before submission — see Step 5. Don't reach for this by default; a single well-formatted comment covers the common case and is easier for the user to review before you post it.

普通评论（默认）：在issue/PR时间线上发布一条评论。适用于以单一整合文稿形式交付的评审（
```
mariadb-operator-pr-review
```
的常规输出）、状态更新、问题询问，或任何不锚定到特定差异行的内容。更简单，且简单是此处的正确默认选择——仅当发现内容确实需要按行锚定时，才使用正式评审。
带有内联评论的正式PR评审：仅当用户明确要求将发现内容附加到差异中的确切行时（例如“为每个发现留下内联评论”），且每个发现都有具体的
```
file:line
```
。这需要先创建待处理评审，添加内联评论后再提交——详见步骤5。不要默认使用此方式；格式良好的单条评论可覆盖常见场景，且用户在发布前更容易审核。

Step 4 — Show the user exactly what will be posted, then stop and ask

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

Render, verbatim:

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

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

Then call

AskUserQuestion

asking whether to post, edit, or cancel. Do not proceed past this point without an explicit "post it" answer. This is the hard gate described above — nothing in Step 5 runs before it.

逐字渲染：

目标：<owner>/<repo>#<number> (<issue|PR>)
模式：<普通评论 | 正式评审：评审结论>

--- 评论内容 ---
<完整渲染的Markdown>
--- 结束 ---

然后调用

AskUserQuestion

询问用户是发布、编辑还是取消。未获得明确的“发布”答复前，不得进入下一步。这是上述的硬性门槛——步骤5的操作需在此之后执行。

Step 5 — Post

步骤5 — 发布

Pick the access method per the GitHub credentials section, then post with it.

Plain comment:

MCP (project-scoped or generic):
```
add_issue_comment
```
with
```
owner
```
,
```
repo
```
,
```
issue_number
```
,
```
body
```
— works for both issues and PRs.

gh CLI with the project token:

bash

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 with default credentials (drop the
```
GH_TOKEN
```
override, rely on ambient
```
gh auth
```
):
bash
```
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>"
```
For either gh CLI variant, pass the body via
```
--body-file
```
(write it to the scratchpad directory first) instead of
```
--body
```
when it's long or has quoting-sensitive characters — safer than fighting shell escaping.

Formal review with inline comments:

MCP (project-scoped or generic): use
```
pull_request_review_write
```
to create a pending review,
```
add_comment_to_pending_review
```
once per finding (each needs
```
path
```
,
```
line
```
, and the finding's body), then submit the pending review with its overall verdict (comment / approve / request changes) via
```
pull_request_review_write
```
.
There's no clean
```
gh
```
CLI equivalent for multi-inline-comment reviews — if no MCP server is available and the user wants inline comments, say so and offer the plain-comment fallback instead of improvising something fragile.

After posting, confirm back to the user with a link or reference to what was just published — don't just say "done".

按照GitHub凭据部分选择访问方式，然后进行发布。

普通评论：

MCP（项目范围或通用）：使用
```
add_issue_comment
```
，传入
```
owner
```
、
```
repo
```
、
```
issue_number
```
、
```
body
```
——对issue和PR均适用。

带有项目令牌的gh CLI：

bash

GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
# 针对PR的命令：
GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh pr comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"

带有默认凭据的gh CLI（移除
```
GH_TOKEN
```
覆盖，依赖环境中的
```
gh auth
```
）：
bash
```
gh issue comment <n> --repo mariadb-operator/mariadb-operator --body "<text>"
# 针对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服务器不可用且用户需要内联评论，需告知用户并提供普通评论作为替代方案，而非尝试脆弱的临时方案。

发布完成后，向用户返回已发布内容的链接或引用进行确认——不要仅回复“已完成”。

What this skill does not do

此技能不处理的事项

It does not decide what to say about a PR — that's
```
mariadb-operator-pr-review
```
(or the user's own words). This skill only formats and delivers.
It does not edit or delete existing comments unless the user explicitly asks for that, and the same confirmation gate applies before any edit/delete too.

不决定PR的评论内容——这是
```
mariadb-operator-pr-review
```
的职责（或用户自行撰写）。此技能仅负责格式化和交付。
除非用户明确要求，否则不编辑或删除现有评论，且在执行任何编辑/删除操作前同样需经过确认门槛。