/stale-sweep

name: stale-sweep
description: >-
  Sweep the googleapis/mcp-toolbox repo for issues and PRs with no real activity in
  N days (default 60), sort each by whose silence it is (the author's, ours, or
  nobody's), and draft the nudge or close comment. Use whenever a maintainer asks for
  a stale sweep, backlog cleanup, or an SLO check, e.g. "stale sweep", "find issues
  with no activity in 30 days", "what's gone quiet", "what's rotting in the backlog",
  "draft close comments for the stale ones", or during the weekly open-issues review.
  PROPOSE-ONLY: delivers the sweep in chat for the maintainer to apply; never
  comments, labels, closes, or merges on its own.

Stale Sweep (mcp-toolbox)

This repo runs no stale bot (`.github/` has no stale workflow), so closing is always a deliberate maintainer act. The value of a sweep is therefore not the list of old things, which anyone can get by sorting on a date. It's the judgment about which silences belong to the contributor, which belong to us, and which are the backlog working as intended.

Goal

Given a window (default 60 days), deliver a sweep the maintainer can work through in one sitting: every candidate sorted into close / nudge-author / on-us / leave-alone, each with the date and reason that put it there, plus a paste-ready comment wherever one is warranted.

Prerequisites

• `gh` authenticated for `googleapis/mcp-toolbox`. A GitHub MCP server substitutes: the commands

below map to its read/list tools.

• A window. If the maintainer didn't give one, default to 60 days and say that's what you used.

Workflow

Step 1: Read the source of truth

Read these live, not from memory.

• [references/maintainer-playbook.md](references/maintainer-playbook.md): **authoritative** for the

>60-day silence rule on `status: waiting for response` / `status: feedback wanted`, the SLO response and closure targets, and the canonical comment templates.

• `gh label list --repo googleapis/mcp-toolbox --limit 200`: **there is no `stale` label**, so never

propose one. This workflow's vocabulary is `status: waiting for response`, `status: feedback wanted`, `duplicate`, and `wontfix`.

• [`.github/blunderbuss.yml`](https://github.com/googleapis/mcp-toolbox/blob/main/.github/blunderbuss.yml):

which `product:` label routes to which team, needed to name an owner on anything blocked on us.

Step 2: Pull the candidates

CUTOFF=$(date -d '60 days ago' +%F 2>/dev/null || date -v-60d +%F)   # GNU, then BSD/macOS

gh search issues --repo googleapis/mcp-toolbox --state open --updated "<$CUTOFF" \
  --limit 100 --json number,title,url,updatedAt,createdAt,labels,author,commentsCount

gh search prs --repo googleapis/mcp-toolbox --state open --updated "<$CUTOFF" \
  --limit 100 --json number,title,url,updatedAt,labels,author,isDraft

`gh search` defaults to 30 results, so always pass `--limit`.

Step 3: Don't let `updatedAt` decide

`updatedAt` is not a silence measure. Label edits, bot comments, renovate rebases, and cross-references all bump it, so an item a bot has kept warm never enters the candidate list at all despite nobody having looked at it in months. Get the real last-human-touch before judging anything:

gh issue view <n> --repo googleapis/mcp-toolbox --json comments,labels,assignees,createdAt \
  --jq '.comments[-3:] | map({author: .author.login, at: .createdAt, body: .body[0:200]})'

Discount label-only churn and bot comments (`gemini-code-assist`, `renovate`, release automation, the Cloud Build failure reporter). What's left is the last substantive human comment, and that date drives every call below.

When the sweep is scoped to one area rather than the whole repo, widen the search window and filter on last human comment yourself, so bot-warmed items can't hide behind the cutoff.

Step 4: Check whether it already resolved itself

The highest-value step, and the one a stale bot structurally cannot do. Before drafting any nudge or close, check whether the thing fixed itself while nobody was looking:

• `git log --oneline --since=<created date> --grep=<term>`, plus a grep for the feature or symbol.
• For a bug, trace the code path and see whether the defect is still there.
• Search for a newer issue that superseded it.

Either outcome leaves the stale buckets entirely, and both beat silence followed by a timeout:

• **Fixed:** close as fixed in `<sha>`, shipped in vX.Y.Z, citing the commit. That's a real answer,

not a stale close.

• **Superseded:** `duplicate` plus a link to the newer issue.

Step 5: Sort by whose silence it is

Stale is not the same as closeable. Put every remaining candidate in exactly one bucket.

**Blocked on the author.** Carries `status: waiting for response` or `status: feedback wanted`, or the last comment is a maintainer question that never got a reply.

• Past 60 days of silence: propose the close, per the playbook rule.
• Under 60 days: propose a nudge that restates the specific outstanding question and names a close

date.

**Blocked on us.** A report filed with enough information and no maintainer reply, or a contributor PR sitting on review or on maintainer-triggered CI.

• **Never propose closing these.** Timing out work that stalled on our side is the failure mode that

costs contributor trust.

• Each one is an SLO miss, so the action is internal: name the owning team from the `product:` label

per `blunderbuss.yml`, and give the SLO clock from the playbook table.

• Surface them loudly rather than letting them sit below the close list.

**Blocked on nobody.** Triaged feature requests in the backlog, `status: help wanted`, `good first issue`, p2/p3 nice-to-haves.

• Silence is the expected state here, not rot. Leave them alone.
• Flag one only when it's gone genuinely obsolete (targets a removed source, or a design the project

moved past) or when the labels are wrong.

When the bucket is a real toss-up, ask. A wrong nudge is cheap; a wrong close is not.

###