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. When the call hinges on whether the bug is real, hand off to the reproduce-bug skill, which runs the cheap discriminators (wrong tool type, version skew, client-side) and can reproduce most reports on SQLite with no credentials; its verdict sharpens both priority: and status:. 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.