--- name: mariadb-operator/mariadb-operator-comment source: https://app.decimal.ai/s/mariadb-operator-mariadb-operator-comment@1/SKILL.md source_sha256: cc90e2937bc9 --- # 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: 1. Render the exact text you are about to post, in full — not a paraphrase or a summary of it. 2. 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"). 3. 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. 4. 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: 1. **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. 2. **`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. 3. **Generic GitHub MCP tools** (`mcp__github__*`), if neither of the above is available. 4. **`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///(issues|pull)/`). 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: /# () Mode: --- comment body --- --- 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](#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 --repo mariadb-operator/mariadb-operator --body "" # or for a PR: GH_TOKEN="$GITHUB_MARIADB_OPERATOR_TOKEN" gh pr comment --repo mariadb-operator/mariadb-operator --body "" ``` - gh CLI with default credentials (drop the `GH_TOKEN` override, rely on ambient `gh auth`): ```bash gh issue comment --repo mariadb-operator/mariadb-operator --body "" # or for a PR: gh pr comment --repo mariadb-operator/mariadb-operator --body "" ``` 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.