| name | triage-issues |
| description | Triage GitHub issues in the googleapis/mcp-toolbox repo: propose the correct labels (type / priority / product / status), check for duplicates, verify a bug has enough info to act on, and draft a triage comment. Use whenever a maintainer asks you to triage, label, categorize, prioritize, or "look at" an issue (or a batch) in mcp-toolbox, e.g. "triage #3648", "what labels should this get", "is this a dup", triage a batch of issue numbers, or when they paste an mcp-toolbox issue link. PROPOSE-ONLY: delivers the triage in chat for the maintainer to apply; never edits labels, comments, closes, or assigns on its own. |
Triage Issues (mcp-toolbox)
Triage here is mostly manual labeling. The product: label auto-routes to the owning team
via .github/blunderbuss.yml. Propose only, never mutating the issue; when a call isn't obvious,
ask rather than guess.
Goal
Given an issue number (or several), deliver a triage the maintainer can apply in seconds: labels
across the four axes (each with a one-line why), likely duplicates, missing bug info, and a
draft comment when one adds value.
Prerequisites
gh authenticated for googleapis/mcp-toolbox, plus the issue number(s). A GitHub MCP server
substitutes for gh if it isn't available: the gh commands below map to its read/list tools.
Guidance
Read source-of-truth live, not from memory (labels/routing drift):
gh label list --repo googleapis/mcp-toolbox --limit 200: the only valid label names. Never propose one not listed..github/blunderbuss.yml: which product: labels route to which team..github/ISSUE_TEMPLATE/bug_report.yml: required bug fields (for the completeness check).- references/maintainer-playbook.md: the authoritative
taxonomy, priority/status definitions, SLO targets, and comment templates. Read it to classify;
this skill only adds how to apply them in a propose-only workflow.
Fetch the issue:
gh issue view <n> --repo googleapis/mcp-toolbox --json number,title,body,author,labels,comments,createdAt
Check bot-noise first. Automated reports (e.g. "Cloud Build Failure Reporter ... failed",
bot author) just need periodic-failure, so skip the rest of the workflow.
The four axes (the playbook has the definitions; below is only how to apply them here). Skip
an axis when it doesn't apply: say so, don't force a label.
type:: the template pre-applies type: bug/type: question; trust it, but correct it
when the body disagrees (a "bug" asking for new behavior is a feature request) and say why.product:: one per data source; highest-leverage label, since it drives team routing.
Infer from the source/tool named (e.g. "looker run_dashboard tool" → product: looker). Don't
force one on core/product-agnostic issues; note it has no product owner. If a real data source
has no matching label yet, say so and flag it for .github/labels.yaml rather than mis-routing.priority:: bugs are only ever p0 or p1 (never p2/p3); feature requests span p0-p3.
Match the issue to the playbook's priority examples and SLO table, state the reason, and let the
maintainer override.status: (optional): waiting for response when a bug lacks info to act, feedback wanted
when waiting on community/author, help wanted for community-open work. See the playbook for
exact semantics and the >60-day-silence close rule.
Community labels (standalone, not status:-prefixed): good first issue for well-scoped,
approachable issues; ready for work for triaged issues actionable now. Propose good first issue
alongside help wanted when the fix is small and self-contained.
Assignment (not a label): rarely needed, since product: auto-routes to the team. Propose an
assignee only when an external contributor volunteers (assign them, to avoid duplicate work) or a
maintainer is picking it up; otherwise leave it unassigned so contributors know it's open.
Duplicates. gh issue list --repo googleapis/mcp-toolbox --state all --search "<key terms>" --limit 20
with distinctive terms (tool name, error string). If it's a known issue, propose duplicate +
close: link and reference the original, and thank the reporter (template below).
Investigate before deferring (bugs). Before proposing waiting for response, try to reproduce
by tracing the code, and check git log/git blame for a fix that already landed silently. If
it's already fixed, propose duplicate + close referencing the commit rather than asking for info.
If you can root-cause it, include the file:line — it sharpens the priority call. Only fall back to
waiting for response when reproduction genuinely isn't possible, and then ask specific,
actionable questions, not "please provide more info". Compare against bug_report.yml required
fields (version, env, expected vs. current, repro) to list exactly what's missing; this feeds the
label and the draft comment.
Feature requests & questions. For a feature request, search the codebase for an existing or
partial implementation before drafting the acknowledgment — it may already be possible (answer and
close) or a duplicate. For a type: question, answer directly from the code with references rather
than only labeling it.
Draft comment. Use the playbook's canonical templates verbatim ("Needs More Information" for a
bug missing repro/details, "Acknowledging a Feature Request" for an FR), filling in specifics like
the exact missing fields; don't invent wording. For a duplicate:
Thanks for reporting this! This is a duplicate of #<original>, so I'm closing this in favor of that issue. Please follow along there for updates.
Rules
- Propose only. Never run
gh issue edit/comment/close or assign. Deliver in chat.
- Only real labels: every proposed label must appear in
gh label list.
- When type/product is a genuine toss-up, ask. A confident wrong
product: mis-routes.
- Cite what backs a claim. Routing/label claims cite the config (e.g. "routes to
toolbox-looker-team per blunderbuss.yml"); codebase claims (root cause, "already fixed",
"already implemented") cite file:line or a commit SHA, or are marked [UNVERIFIED].
Output format
## Issue #<n>: <title>
**Labels:**
- `type: <x>`: <why>
- `product: <x>`: <why + routing, or "no product owner: core/...">
- `priority: <x>`: <why>
- `status: <x>`: <why, if any>
**Duplicates:** <#nums, or "none for terms: ...">
**Completeness (bugs):** <what's missing, or "complete">
**Draft comment:** <paste-ready, or "none needed">
**Apply:** gh issue edit <n> --repo googleapis/mcp-toolbox --add-label "type: ...,product: ...,priority: ..."
Include the ready-to-run gh issue edit line so the maintainer applies with one paste, but leave
running it to them. For a batch, one block per issue plus a one-line summary table.
