Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .claude/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .agents/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .cursor/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .gemini/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .github/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "mariadb-operator-comment" agent skill from https://github.com/mariadb-operator/mariadb-operator/tree/main/.agents/skills/mariadb-operator-comment into .opencode/skills/mariadb-operator-comment/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "mariadb-operator-comment", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
mariadb-operator-comment
GitHub stars
1k
Token cost
~2.2k tokens
SKILL.md length
1,036 words
Files
1
Skills in repo
3
Repo updated
First seen
Licence
Apache-2.0
At a glance
Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator.
Works in 5 steps: Resolve the target → Assemble the comment body → Pick plain comment vs. formal review → …
The user wants to publish something to GitHub for this repo — comment on issue 123
SKILL.md covers Never post without confirmation, GitHub credentials, Step 1 — Resolve the target and Step 2 — Assemble the comment…, plus 4 more sections
Calls gh; needs GITHUB_MARIADB_OPERATOR_TOKEN and GH_TOKEN
What it does
Mariadb Operator Comment is an agent skill from mariadb-operator/mariadb-operator. Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator. Use whenever the user wants to publish something to GitHub for this repo — "comment on issue 123", "post this as a PR comment", "leave a note on 456", "reply on the PR" — and especially when they want the output of the mariadb-operator-pr-review skill delivered to GitHub instead of just shown in chat, e.g. "review PR 1234 and post it as a comment" or "post the review results to the PR". Always confirms…
Its SKILL.md is about 2.2k tokens, which your agent loads only when the skill is triggered. It is a single SKILL.md file with no bundled scripts. Compatibility notes: Requires either the project-scoped GitHub MCP server (tools named mcpgithub-mariadb-operator) or the gh CLI authenticated via a GITHUBMARIADBOPERATORTOKEN…
It sits in Development, covering Pull requests. It works with MariaDB, GitHub, Kubernetes and MySQL. The repository describes itself as: 🦭 Run and operate MariaDB in a cloud native way. The licence is Apache-2.0.
When your agent uses it
The user wants to publish something to GitHub for this repo — comment on issue 123
Post this as a PR comment
Leave a note on 456
Example prompts
“comment on issue 123”
“post this as a PR comment”
“leave a note on 456”
“/mariadb-operator-comment”
Requirements
A credential in GITHUB_MARIADB_OPERATOR_TOKEN
Compatibility (from SKILL.md): Requires either the project-scoped GitHub MCP server (tools named mcp__github-mariadb-operator__*) or the gh CLI authenticated via a GITHUB_MARIADB_OPERATOR_TOKEN environment variable.
Read from SKILL.md and the folder at commit e071201. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves these tools, so the agent can use them without asking each time:
Bash(gh:*)
AskUserQuestion
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
gh
From the folder's file list and the shell code blocks in SKILL.md.
Network
No URLs in SKILL.md. Its commands use gh, which can reach the network depending on how they are called.
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names these keys or tokens, usually read from environment variables:
GITHUB_MARIADB_OPERATOR_TOKEN
GH_TOKEN
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Compatibility
Requires either the project-scoped GitHub MCP server (tools named mcp__github-mariadb-operator__*) or the gh CLI authenticated via a GITHUB_MARIADB_OPERATOR_TOKEN environment variable.
From compatibility in the SKILL.md frontmatter.
Context cost
Mariadb Operator Comment loads about 2.2k tokens when it runs. Until then it costs about 157 tokens; SKILL.md has 1,036 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~157
When it runs· the whole SKILL.md, loaded when a task matches
~2.2k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/mariadb-operator-comment/SKILL.md (or your agent's skills folder).
name
mariadb-operator-comment
description
Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator. Use whenever the user wants to publish something to GitHub for this repo — "comment on issue #123", "post this as a PR comment", "leave a note on #456", "reply on the PR" — and especially when they want the output of the mariadb-operator-pr-review skill delivered to GitHub instead of just shown in chat, e.g. "review PR #1234 and post it as a comment" or "post the review results to the PR". Always confirms the exact comment text with the user before publishing — never posts autonomously.
allowed-tools
Bash(gh:*), AskUserQuestion
compatibility
Requires either the project-scoped GitHub MCP server (tools named mcp__github-mariadb-operator__*) or the gh CLI authenticated via a GITHUB_MARIADB_OPERATOR_TOKEN environment variable.
license
Apache-2.0
metadata.author
mariadb-operator
metadata.version
1.0
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.
Show full SKILL.md (475 more words)Show less
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: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".
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.
Mariadb Operator Comment next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Mariadb Operator Comment compared with similar skills
Skill
Stars
Used in
Tokens
Auto-check
Licence
Repo updated
Mariadb Operator Comment this skillmariadb-operator/mariadb-operator
Reviews pull requests for the NGINX Kubernetes Ingress Controller with a fixed workflow, strict comment guardrails and a set output format, leaving repo detail to sibling skills.
Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator. Mariadb Operator Comment is an agent skill from mariadb-operator/mariadb-operator. Post a comment (or a formal PR review) to a GitHub issue or pull request in mariadb-operator/mariadb-operator.
When should I use Mariadb Operator Comment?
Mariadb Operator Comment fits situations like: the user wants to publish something to GitHub for this repo — comment on issue 123; post this as a PR comment; leave a note on 456.
How do I install Mariadb Operator Comment in Claude Code?
Run `npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a claude-code`. Or copy the skill folder (.agents/skills/mariadb-operator-comment in mariadb-operator/mariadb-operator) into .claude/skills/mariadb-operator-comment in your project. Claude Code loads it when a task matches its description.
How do I install Mariadb Operator Comment in Codex?
Run `npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a codex`. Or copy the skill folder (.agents/skills/mariadb-operator-comment in mariadb-operator/mariadb-operator) into .agents/skills/mariadb-operator-comment in your project. Codex loads it when a task matches its description.
Can I use Mariadb Operator Comment in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add mariadb-operator/mariadb-operator --skill mariadb-operator-comment -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/mariadb-operator-comment, .gemini/skills/mariadb-operator-comment, .github/skills/mariadb-operator-comment and .opencode/skills/mariadb-operator-comment in your project.
What does Mariadb Operator Comment need to run?
Going by SKILL.md and its folder, Mariadb Operator Comment needs the command-line tools its instructions call (gh) and credentials named GITHUB_MARIADB_OPERATOR_TOKEN and GH_TOKEN. Our summary lists: A credential in GITHUB_MARIADB_OPERATOR_TOKEN. Its frontmatter pre-approves these tools: Bash(gh:*), AskUserQuestion. Compatibility (from SKILL.md): Requires either the project-scoped GitHub MCP server (tools named mcp__github-mariadb-operator__*) or the gh CLI authenticated via a GITHUB_MARIADB_OPERATOR_TOKEN environment variable.
.
Does Mariadb Operator Comment access the network?
SKILL.md contains no URLs. Its commands use gh, which can reach the network depending on how they are called. This is read from the text; nothing was executed.
Is Mariadb Operator Comment safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Mariadb Operator Comment use?
Mariadb Operator Comment is published under the Apache-2.0 licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Mariadb Operator Comment use?
About 2.2k tokens (SKILL.md is roughly 8.6k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Mariadb Operator Comment?
Skills that share tags, products or a category with Mariadb Operator Comment: Git Commits (databasus/databasus, 8.8k stars), Resolve PR Review (shencangsheng/easydb_app, 590 stars), Cherry Pick PR (kubernetes-sigs/cloud-provider-azure, 294 stars) and NIC Code Review (nginx/kubernetes-ingress, 5.1k stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Mariadb Operator Comment?
mariadb-operator (a GitHub organization) maintains it in mariadb-operator/mariadb-operator, which has 1,023 GitHub stars. The repository holds 3 skills in this directory. The repository was last updated on October 7, 2026.
