stale-issue-cleanup

name	stale-issue-cleanup
description	Find and close stale bug issues in microsoft/AzureStorageExplorer. Use this when asked to clean up stale issues, close inactive bugs, or perform issue hygiene.

Definition of Stale

An issue is stale when ALL of the following are true:

1. The issue is open.
2. The most recent comment was posted by a member of the microsoft/azure-storage-explorer GitHub team.
3. That comment was posted 14 or more days ago.
4. No one outside the team has commented since — including the original author and any other community members.

Important Design Decisions

• Prefer GraphQL over REST. Use gh api graphql for all GitHub queries. GraphQL lets us fetch issue type, last comment, and author in a single request instead of N+1 REST calls.
• Only target Bug-type issues. Feature requests and tasks should be left alone, even if they are old. Filter by issueType.name == "Bug".
• Never close accessibility issues. Any issue with a label starting with :accessibility: must be skipped, regardless of staleness.

Step-by-Step Procedure

Step 1: Get team members

Run this command to get the list of Storage Explorer team member logins:

gh api --paginate /orgs/microsoft/teams/azure-storage-explorer/members --jq '.[].login'

Store these logins for comparison throughout the process.

Step 2: Find candidate bug issues

Use a single GraphQL query to get open Bug issues with their last comment:

gh api graphql -f query='
{
  repository(owner: "microsoft", name: "AzureStorageExplorer") {
    issues(first: 50, states: OPEN, orderBy: {field: UPDATED_AT, direction: ASC}) {
      nodes {
        number
        title
        updatedAt
        issueType { name }
        labels(first: 50) {
          nodes { name }
        }
        comments(last: 1) {
          nodes {
            author { login }
            createdAt
            body
          }
        }
      }
      pageInfo { hasNextPage endCursor }
    }
  }
}'

Use pagination (pass after: "{endCursor}") to fetch additional pages if needed.

Filter results to issues where:

1. issueType.name is "Bug"
2. No label starts with :accessibility:
3. updatedAt is ≥14 days ago
4. The last comment exists and its author is a team member (from Step 1)
5. The last comment's createdAt is ≥14 days ago

Step 3: Verify each candidate

For each candidate, read the last comment's body. Only mark as stale if the team member was asking the reporter for something (e.g., repro steps, logs, version info, confirmation, follow-up). If the team member's comment was just an acknowledgment or internal note, skip the issue.

Step 4: Close stale issues

For each confirmed stale issue, do the following in order:

4a. Post a contextual closing comment

Read the team member's last comment to understand what they asked for. Then post a comment using gh issue comment.

The comment should follow this template:

Closing due to inactivity. If you're still experiencing this issue, [ACTION].

Where [ACTION] is tuned to what the team member asked for. Examples:

• "...please reply with the requested logs and we can revisit."
• "...please reply with the repro steps and we'll take another look."
• "...please reply to confirm whether the issue persists on the latest version."
• "...please reply and let us know if the suggested workaround resolved it."

Keep it to ONE sentence. Do not restate what was asked — just tell them what to provide if they want to re-engage.

Use:

gh issue comment {number} --repo microsoft/AzureStorageExplorer --body "{comment}"

4b. Close the issue as not planned

gh issue close {number} --repo microsoft/AzureStorageExplorer --reason "not planned"

4c. Set the Resolution project field to "Stale"

Use GraphQL to update the project field:

1. Find the issue's project item ID on the Storage Explorer project.
2. Find the field ID for "Resolution" and the option ID for "Stale".
3. Update the field value.

Combine lookups into a single query where possible:

gh api graphql -f query='
  query {
    repository(owner: "microsoft", name: "AzureStorageExplorer") {
      issue(number: {NUMBER}) {
        projectItems(first: 10) {
          nodes {
            id
            project { title id }
          }
        }
      }
    }
  }
'

Then update:

gh api graphql -f query='
  mutation {
    updateProjectV2ItemFieldValue(input: {
      projectId: "{PROJECT_ID}"
      itemId: "{ITEM_ID}"
      fieldId: "{FIELD_ID}"
      value: { singleSelectOptionId: "{STALE_OPTION_ID}" }
    }) {
      projectV2Item { id }
    }
  }
'

If the token lacks read:project scope, note this in the summary and skip this step.

Step 5: Report

After processing all issues, print a summary:

• Total open issues scanned
• Number of stale issues found and closed
• List each closed issue: number, title, and what was requested

If no stale issues were found, say so.

Important Rules

• DRY RUN: If the user says "dry run", list the stale issues and what you would do, but do NOT post comments, close issues, or update projects.
• Never close issues where the last comment is from a non-team member. The reporter may have replied — always verify.
• Be conservative. If you're unsure whether an issue is stale, skip it.
• Rate limiting. Pause briefly between API calls if processing many issues.