Mariadb Operator Comment

mariadb-operator Comment

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.

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 credentials

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.

Step 1 — Resolve the target

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.

Step 2 — Assemble the comment body

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.

Step 3 — Pick plain comment vs. formal review

• 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.

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

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.

Step 5 — Post

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:

  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):

  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".

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.