Fix issues being auto-closed despite human activity

The sweep script was closing issues based solely on when a lifecycle label
was applied, ignoring any human comments posted after the label. This caused
active issues (like #11792) to be closed even when users responded to the
stale warning.

Three changes:

1. Teach the triage bot about `stale` and `autoclose` labels so it removes
   them when a human comments on the issue.

2. Add a safety net in `closeExpired()` that checks for non-bot comments
   posted after the lifecycle label was applied — if any exist, skip closing.

3. Extend the 10-upvote protection (which previously only applied to
   enhancements) to all issue types, in both `markStale()` and
   `closeExpired()`.

Fixes #16497

## Test plan

Trace through scenarios manually:
- Issue with stale label + human comment after → triage removes label;
  sweep skips even if triage hasn't run yet (safety net)
- Issue with stale label + no human comment → closes as before
- Issue with 10+ upvotes of any type → never marked stale or closed

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

.claude/commands/dedupe.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Bash(./scripts/gh.sh:*), Bash(./scripts/comment-on-duplicates.sh:*)
+allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(./scripts/comment-on-duplicates.sh:*)
 description: Find duplicate GitHub issues
 ---
 
@@ -13,15 +13,11 @@ To do this, follow these steps precisely:
 4. Next, feed the results from #1 and #2 into another agent, so that it can filter out false positives, that are likely not actually duplicates of the original issue. If there are no duplicates remaining, do not proceed.
 5. Finally, use the comment script to post duplicates:
    ```
-   ./scripts/comment-on-duplicates.sh --potential-duplicates <dup1> <dup2> <dup3>
+   ./scripts/comment-on-duplicates.sh --base-issue <issue-number> --potential-duplicates <dup1> <dup2> <dup3>
    ```
 
 Notes (be sure to tell this to your agents, too):
 
-- Use `./scripts/gh.sh` to interact with Github, rather than web fetch or raw `gh`. Examples:
-  - `./scripts/gh.sh issue view 123` — view an issue
-  - `./scripts/gh.sh issue view 123 --comments` — view with comments
-  - `./scripts/gh.sh issue list --state open --limit 20` — list issues
-  - `./scripts/gh.sh search issues "query" --limit 10` — search for issues
-- Do not use other tools, beyond `./scripts/gh.sh` and the comment script (eg. don't use other MCP servers, file edit, etc.)
+- Use `gh` to interact with Github, rather than web fetch
+- Do not use other tools, beyond `gh` and the comment script (eg. don't use other MCP servers, file edit, etc.)
 - Make a todo list first

.claude/commands/oncall-triage.md

@@ -0,0 +1,40 @@
+---
+allowed-tools: Bash(gh issue list:*), Bash(gh issue view:*), Bash(gh issue edit:*), TodoWrite
+description: Triage GitHub issues and label critical ones for oncall
+---
+
+You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention and apply the "oncall" label.
+
+Repository: anthropics/claude-code
+
+Task overview:
+
+1. First, get all open bugs updated in the last 3 days with at least 50 engagements:
+   ```bash
+   gh issue list --repo anthropics/claude-code --state open --label bug --limit 1000 --json number,title,updatedAt,comments,reactions | jq -r '.[] | select((.updatedAt >= (now - 259200 | strftime("%Y-%m-%dT%H:%M:%SZ"))) and ((.comments | length) + ([.reactions[].content] | length) >= 50)) | "\(.number)"'
+   ```
+
+2. Save the list of issue numbers and create a TODO list with ALL of them. This ensures you process every single one.
+
+3. For each issue in your TODO list:
+   - Use `gh issue view <number> --repo anthropics/claude-code --json title,body,labels,comments` to get full details
+   - Read and understand the full issue content and comments to determine actual user impact
+   - Evaluate: Is this truly blocking users from using Claude Code?
+     - Consider: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
+     - Does it prevent core functionality? Can users work around it?
+   - Be conservative - only flag issues that truly prevent users from getting work done
+
+4. For issues that are truly blocking and don't already have the "oncall" label:
+   - Use `gh issue edit <number> --repo anthropics/claude-code --add-label "oncall"`
+   - Mark the issue as complete in your TODO list
+
+5. After processing all issues, provide a summary:
+   - List each issue number that received the "oncall" label
+   - Include the issue title and brief reason why it qualified
+   - If no issues qualified, state that clearly
+
+Important:
+- Process ALL issues in your TODO list systematically
+- Don't post any comments to issues
+- Only add the "oncall" label, never remove it
+- Use individual `gh issue view` commands instead of bash for loops to avoid approval prompts

.claude/commands/triage-issue.md

@@ -1,70 +0,0 @@
----
-allowed-tools: Bash(./scripts/gh.sh:*),Bash(./scripts/edit-issue-labels.sh:*)
-description: Triage GitHub issues by analyzing and applying labels
----
-
-You're an issue triage assistant. Analyze the issue and manage labels.
-
-IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.
-
-Context:
-
-$ARGUMENTS
-
-TOOLS:
-- `./scripts/gh.sh` — wrapper for `gh` CLI. Only supports these subcommands and flags:
-  - `./scripts/gh.sh label list` — fetch all available labels
-  - `./scripts/gh.sh label list --limit 100` — fetch with limit
-  - `./scripts/gh.sh issue view 123` — read issue title, body, and labels
-  - `./scripts/gh.sh issue view 123 --comments` — read the conversation
-  - `./scripts/gh.sh issue list --state open --limit 20` — list issues
-  - `./scripts/gh.sh search issues "query"` — find similar or duplicate issues
-  - `./scripts/gh.sh search issues "query" --limit 10` — search with limit
-- `./scripts/edit-issue-labels.sh --add-label LABEL --remove-label LABEL` — add or remove labels (issue number is read from the workflow event)
-
-TASK:
-
-1. Run `./scripts/gh.sh label list` to fetch the available labels. You may ONLY use labels from this list. Never invent new labels.
-2. Run `./scripts/gh.sh issue view ISSUE_NUMBER` to read the issue details.
-3. Run `./scripts/gh.sh issue view ISSUE_NUMBER --comments` to read the conversation.
-
-**If EVENT is "issues" (new issue):**
-
-4. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled `invalid`. If invalid, apply only that label and stop.
-
-5. Analyze and apply category labels:
-   - Type (bug, enhancement, question, etc.)
-   - Technical areas and platform
-   - Check for duplicates with `./scripts/gh.sh search issues`. Only mark as duplicate of OPEN issues.
-
-6. Evaluate lifecycle labels:
-   - `needs-repro` (bugs only, 7 days): Bug reports without clear steps to reproduce. A good repro has specific, followable steps that someone else could use to see the same issue.
-     Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count.
-     For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
-   - `needs-info` (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements.
-     Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not `needs-info`.
-
-   Issues with these labels are automatically closed after the timeout if there's no response.
-   The goal is to avoid issues lingering without a clear next step.
-
-7. Apply all selected labels:
-   `./scripts/edit-issue-labels.sh --add-label "label1" --add-label "label2"`
-
-**If EVENT is "issue_comment" (comment on existing issue):**
-
-4. Evaluate lifecycle labels based on the full conversation:
-   - If the issue has `stale` or `autoclose`, remove the label — a new human comment means the issue is still active:
-     `./scripts/edit-issue-labels.sh --remove-label "stale" --remove-label "autoclose"`
-   - If the issue has `needs-repro` or `needs-info` and the missing information has now been provided, remove the label:
-     `./scripts/edit-issue-labels.sh --remove-label "needs-repro"`
-   - If the issue doesn't have lifecycle labels but clearly needs them (e.g., a maintainer asked for repro steps or more details), add the appropriate label.
-   - Comments like "+1", "me too", "same here", or emoji reactions are NOT the missing information. Only remove `needs-repro` or `needs-info` when substantive details are actually provided.
-   - Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.
-
-GUIDELINES:
-- ONLY use labels from `./scripts/gh.sh label list` — never create or guess label names
-- DO NOT post any comments to the issue
-- Be conservative with lifecycle labels — only apply when clearly warranted
-- Only apply lifecycle labels (`needs-repro`, `needs-info`) to bugs — never to questions or enhancements
-- When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
-- It's okay to not add any labels if none are clearly applicable

.github/workflows/claude-dedupe-issues.yml

@@ -17,6 +17,7 @@ jobs:
     permissions:
       contents: read
       issues: write
+      id-token: write
 
     steps:
       - name: Checkout repository
@@ -26,7 +27,6 @@ jobs:
         uses: anthropics/claude-code-action@v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          CLAUDE_CODE_SCRIPT_CAPS: '{"comment-on-duplicates.sh":1}'
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"

.github/workflows/claude-issue-triage.yml

@@ -18,6 +18,7 @@ jobs:
     permissions:
       contents: read
       issues: write
+      id-token: write
 
     steps:
       - name: Checkout repository
@@ -28,12 +29,78 @@ jobs:
         uses: anthropics/claude-code-action@v1
         env:
           GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          GH_REPO: ${{ github.repository }}
-          CLAUDE_CODE_SCRIPT_CAPS: '{"edit-issue-labels.sh":2}'
         with:
           github_token: ${{ secrets.GITHUB_TOKEN }}
           allowed_non_write_users: "*"
-          prompt: "/triage-issue REPO: ${{ github.repository }} ISSUE_NUMBER: ${{ github.event.issue.number }} EVENT: ${{ github.event_name }}"
+          prompt: |
+            You're an issue triage assistant. Analyze the issue and manage labels.
+
+            IMPORTANT: Don't post any comments or messages to the issue. Your only actions are adding or removing labels.
+
+            Context:
+            - REPO: ${{ github.repository }}
+            - ISSUE_NUMBER: ${{ github.event.issue.number }}
+            - EVENT: ${{ github.event_name }}
+
+            ALLOWED LABELS — you may ONLY use labels from this list. Never invent new labels.
+
+            Type: bug, enhancement, question, documentation, duplicate, invalid
+            Lifecycle: needs-repro, needs-info, stale, autoclose
+            Platform: platform:linux, platform:macos, platform:windows, platform:wsl, platform:ios, platform:android, platform:vscode, platform:intellij, platform:web, platform:aws-bedrock
+            API: api:bedrock, api:vertex
+
+            TOOLS:
+            - `gh issue view NUMBER`: Read the issue title, body, and labels
+            - `gh issue view NUMBER --comments`: Read the conversation
+            - `gh search issues QUERY`: Find similar or duplicate issues
+            - `gh issue edit NUMBER --add-label` / `--remove-label`: Add or remove labels
+
+            TASK:
+
+            1. Run `gh issue view ${{ github.event.issue.number }}` to read the issue details.
+            2. Run `gh issue view ${{ github.event.issue.number }} --comments` to read the conversation.
+
+            **If EVENT is "issues" (new issue):**
+
+            3. First, check if this issue is actually about Claude Code (the CLI/IDE tool). Issues about the Claude API, claude.ai, the Claude app, Anthropic billing, or other Anthropic products should be labeled `invalid`. If invalid, apply only that label and stop.
+
+            4. Analyze and apply category labels:
+               - Type (bug, enhancement, question, etc.)
+               - Technical areas and platform
+               - Check for duplicates with `gh search issues`. Only mark as duplicate of OPEN issues.
+
+            5. Evaluate lifecycle labels:
+               - `needs-repro` (bugs only, 7 days): Bug reports without clear steps to reproduce. A good repro has specific, followable steps that someone else could use to see the same issue.
+                 Do NOT apply if the user already provided error messages, logs, file paths, or a description of what they did. Don't require a specific format — narrative descriptions count.
+                 For model behavior issues (e.g. "Claude does X when it should do Y"), don't require traditional repro steps — examples and patterns are sufficient.
+               - `needs-info` (bugs only, 7 days): The issue needs something from the community before it can progress — e.g. error messages, versions, environment details, or answers to follow-up questions. Don't apply to questions or enhancements.
+                 Do NOT apply if the user already provided version, environment, and error details. If the issue just needs engineering investigation, that's not `needs-info`.
+
+               Issues with these labels are automatically closed after the timeout if there's no response.
+               The goal is to avoid issues lingering without a clear next step.
+
+            6. Apply all selected labels:
+               `gh issue edit ${{ github.event.issue.number }} --add-label "label1" --add-label "label2"`
+
+            **If EVENT is "issue_comment" (comment on existing issue):**
+
+            3. Evaluate lifecycle labels based on the full conversation:
+               - If the issue has `stale` or `autoclose`, remove the label — a new human comment means the issue is still active:
+                 `gh issue edit ${{ github.event.issue.number }} --remove-label "stale" --remove-label "autoclose"`
+               - If the issue has `needs-repro` or `needs-info` and the missing information has now been provided, remove the label:
+                 `gh issue edit ${{ github.event.issue.number }} --remove-label "needs-repro"`
+               - If the issue doesn't have lifecycle labels but clearly needs them (e.g., a maintainer asked for repro steps or more details), add the appropriate label.
+               - Comments like "+1", "me too", "same here", or emoji reactions are NOT the missing information. Only remove `needs-repro` or `needs-info` when substantive details are actually provided.
+               - Do NOT add or remove category labels (bug, enhancement, etc.) on comment events.
+
+            GUIDELINES:
+            - ONLY use labels from the ALLOWED LABELS list above — never create or guess label names
+            - DO NOT post any comments to the issue
+            - Be conservative with lifecycle labels — only apply when clearly warranted
+            - Only apply lifecycle labels (`needs-repro`, `needs-info`) to bugs — never to questions or enhancements
+            - When in doubt, don't apply a lifecycle label — false positives are worse than missing labels
+            - It's okay to not add any labels if none are clearly applicable
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           claude_args: |
             --model claude-opus-4-6
+            --allowedTools "Bash(gh issue view:*),Bash(gh issue edit:*),Bash(gh search issues:*)"

.github/workflows/non-write-users-check.yml

@@ -1,47 +0,0 @@
-name: Non-write Users Check
-on:
-  pull_request:
-    paths:
-      - ".github/**"
-
-permissions:
-  contents: read
-  pull-requests: write
-
-jobs:
-  allowed-non-write-check:
-    runs-on: ubuntu-latest
-    env:
-      GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-    steps:
-      - run: |
-          DIFF=$(gh pr diff "$PR_NUMBER" -R "$REPO" || true)
-
-          if ! echo "$DIFF" | grep -qE '^diff --git a/\.github/.*\.ya?ml'; then
-            exit 0
-          fi
-
-          MATCHES=$(echo "$DIFF" | grep "^+.*allowed_non_write_users" || true)
-
-          if [ -z "$MATCHES" ]; then
-            exit 0
-          fi
-
-          EXISTING=$(gh pr view "$PR_NUMBER" -R "$REPO" --json comments --jq '.comments[].body' \
-            | grep -c "<!-- non-write-users-check -->" || true)
-
-          if [ "$EXISTING" -gt 0 ]; then
-            exit 0
-          fi
-
-          gh pr comment "$PR_NUMBER" -R "$REPO" --body '<!-- non-write-users-check -->
-          **`allowed_non_write_users` detected**
-
-          This PR adds or modifies `allowed_non_write_users`, which allows users without write access to trigger Claude Code Action workflows. This can introduce security risks.
-
-          If this is a new flow, please make sure you actually need `allowed_non_write_users`. If you are editing an existing workflow, double check that you are not adding new Claude permissions which might lead to a vulnerability.
-
-          See existing workflows in this repo for safe usage examples, or contact the AppSec team.'
-        env:
-          PR_NUMBER: ${{ github.event.pull_request.number }}
-          REPO: ${{ github.repository }}

.github/workflows/oncall-triage.yml

@@ -0,0 +1,118 @@
+name: Oncall Issue Triage
+description: Automatically identify and label critical blocking issues requiring oncall attention
+on:
+  push:
+    branches:
+      - add-oncall-triage-workflow  # Temporary: for testing only
+  schedule:
+    # Run every 6 hours
+    - cron: '0 */6 * * *'
+  workflow_dispatch: # Allow manual trigger
+
+jobs:
+  oncall-triage:
+    runs-on: ubuntu-latest
+    timeout-minutes: 15
+    permissions:
+      contents: read
+      issues: write
+      id-token: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup GitHub MCP Server
+        run: |
+          mkdir -p /tmp/mcp-config
+          cat > /tmp/mcp-config/mcp-servers.json << 'EOF'
+          {
+            "mcpServers": {
+              "github": {
+                "command": "docker",
+                "args": [
+                  "run",
+                  "-i",
+                  "--rm",
+                  "-e",
+                  "GITHUB_PERSONAL_ACCESS_TOKEN",
+                  "ghcr.io/github/github-mcp-server:sha-7aced2b"
+                ],
+                "env": {
+                  "GITHUB_PERSONAL_ACCESS_TOKEN": "${{ secrets.GITHUB_TOKEN }}"
+                }
+              }
+            }
+          }
+          EOF
+
+      - name: Run Claude Code for Oncall Triage
+        timeout-minutes: 10
+        uses: anthropics/claude-code-action@v1
+        env:
+          GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          allowed_non_write_users: "*"
+          prompt: |
+            You're an oncall triage assistant for GitHub issues. Your task is to identify critical issues that require immediate oncall attention.
+
+            Important: Don't post any comments or messages to the issues. Your only action should be to apply the "oncall" label to qualifying issues.
+
+            Repository: ${{ github.repository }}
+
+            Task overview:
+            1. Fetch all open issues updated in the last 3 days:
+               - Use mcp__github__list_issues with:
+                 - state="open"
+                 - first=5 (fetch only 5 issues per page)
+                 - orderBy="UPDATED_AT"
+                 - direction="DESC"
+               - This will give you the most recently updated issues first
+               - For each page of results, check the updatedAt timestamp of each issue
+               - Add issues updated within the last 3 days (72 hours) to your TODO list as you go
+               - Keep paginating using the 'after' parameter until you encounter issues older than 3 days
+               - Once you hit issues older than 3 days, you can stop fetching (no need to fetch all open issues)
+
+            2. Build your TODO list incrementally as you fetch:
+               - As you fetch each page, immediately add qualifying issues to your TODO list
+               - One TODO item per issue number (e.g., "Evaluate issue #123")
+               - This allows you to start processing while still fetching more pages
+
+            3. For each issue in your TODO list:
+               - Use mcp__github__get_issue to read the issue details (title, body, labels)
+               - Use mcp__github__get_issue_comments to read all comments
+               - Evaluate whether this issue needs the oncall label:
+                 a) Is it a bug? (has "bug" label or describes bug behavior)
+                 b) Does it have at least 50 engagements? (count comments + reactions)
+                 c) Is it truly blocking? Read and understand the full content to determine:
+                    - Does this prevent core functionality from working?
+                    - Can users work around it?
+                    - Consider severity indicators: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
+                    - Be conservative - only flag issues that truly prevent users from getting work done
+
+            4. For issues that meet all criteria and do not already have the "oncall" label:
+               - Use mcp__github__update_issue to add the "oncall" label
+               - Do not post any comments
+               - Do not remove any existing labels
+               - Do not remove the "oncall" label from issues that already have it
+
+            Important guidelines:
+            - Use the TODO list to track your progress through ALL candidate issues
+            - Process issues efficiently - don't read every single issue upfront, work through your TODO list systematically
+            - Be conservative in your assessment - only flag truly critical blocking issues
+            - Do not post any comments to issues
+            - Your only action should be to add the "oncall" label using mcp__github__update_issue
+            - Mark each issue as complete in your TODO list as you process it
+
+            7. After processing all issues in your TODO list, provide a summary of your actions:
+               - Total number of issues processed (candidate issues evaluated)
+               - Number of issues that received the "oncall" label
+               - For each issue that got the label: list issue number, title, and brief reason why it qualified
+               - Close calls: List any issues that almost qualified but didn't quite meet the criteria (e.g., borderline blocking, had workarounds)
+               - If no issues qualified, state that clearly
+               - Format the summary clearly for easy reading
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          claude_args: |
+            --mcp-config /tmp/mcp-config/mcp-servers.json
+            --allowedTools "mcp__github__list_issues,mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue"

plugins/code-review/commands/code-review.md

@@ -68,7 +68,7 @@ Note: Still review Claude generated PR's.
 
 8. Create a list of all comments that you plan on leaving. This is only for you to make sure you are comfortable with the comments. Do not post this list anywhere.
 
-9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment` with `confirmed: true`. For each comment:
+9. Post inline comments for each issue using `mcp__github_inline_comment__create_inline_comment`. For each comment:
    - Provide a brief description of the issue
    - For small, self-contained fixes, include a committable suggestion block
    - For larger fixes (6+ lines, structural changes, or changes spanning multiple locations), describe the issue and suggested fix without a suggestion block

scripts/comment-on-duplicates.sh

@@ -1,28 +1,22 @@
 #!/usr/bin/env bash
 #
 # Comments on a GitHub issue with a list of potential duplicates.
-# Usage: ./comment-on-duplicates.sh --potential-duplicates 456 789 101
-#
-# The base issue number is read from the workflow event payload.
+# Usage: ./comment-on-duplicates.sh --base-issue 123 --potential-duplicates 456 789 101
 #
 
 set -euo pipefail
 
 REPO="anthropics/claude-code"
-
-# Read from event payload so the issue number is bound to the triggering event.
-# Falls back to workflow_dispatch inputs for manual runs.
-BASE_ISSUE=$(jq -r '.issue.number // .inputs.issue_number // empty' "${GITHUB_EVENT_PATH:?GITHUB_EVENT_PATH not set}")
-if ! [[ "$BASE_ISSUE" =~ ^[0-9]+$ ]]; then
-  echo "Error: no issue number in event payload" >&2
-  exit 1
-fi
-
+BASE_ISSUE=""
 DUPLICATES=()
 
 # Parse arguments
 while [[ $# -gt 0 ]]; do
   case $1 in
+    --base-issue)
+      BASE_ISSUE="$2"
+      shift 2
+      ;;
     --potential-duplicates)
       shift
       while [[ $# -gt 0 && ! "$1" =~ ^-- ]]; do
@@ -31,12 +25,23 @@ while [[ $# -gt 0 ]]; do
       done
       ;;
     *)
-      echo "Error: unknown argument (only --potential-duplicates is accepted)" >&2
+      echo "Unknown option: $1" >&2
       exit 1
       ;;
   esac
 done
 
+# Validate base issue
+if [[ -z "$BASE_ISSUE" ]]; then
+  echo "Error: --base-issue is required" >&2
+  exit 1
+fi
+
+if ! [[ "$BASE_ISSUE" =~ ^[0-9]+$ ]]; then
+  echo "Error: --base-issue must be a number, got: $BASE_ISSUE" >&2
+  exit 1
+fi
+
 # Validate duplicates
 if [[ ${#DUPLICATES[@]} -eq 0 ]]; then
   echo "Error: --potential-duplicates requires at least one issue number" >&2

scripts/edit-issue-labels.sh

@@ -1,84 +0,0 @@
-#!/usr/bin/env bash
-#
-# Edits labels on a GitHub issue.
-# Usage: ./edit-issue-labels.sh --add-label bug --add-label needs-triage --remove-label untriaged
-#
-# The issue number is read from the workflow event payload.
-#
-
-set -euo pipefail
-
-# Read from event payload so the issue number is bound to the triggering event.
-# Falls back to workflow_dispatch inputs for manual runs.
-ISSUE=$(jq -r '.issue.number // .inputs.issue_number // empty' "${GITHUB_EVENT_PATH:?GITHUB_EVENT_PATH not set}")
-if ! [[ "$ISSUE" =~ ^[0-9]+$ ]]; then
-  echo "Error: no issue number in event payload" >&2
-  exit 1
-fi
-
-ADD_LABELS=()
-REMOVE_LABELS=()
-
-# Parse arguments
-while [[ $# -gt 0 ]]; do
-  case $1 in
-    --add-label)
-      ADD_LABELS+=("$2")
-      shift 2
-      ;;
-    --remove-label)
-      REMOVE_LABELS+=("$2")
-      shift 2
-      ;;
-    *)
-      echo "Error: unknown argument (only --add-label and --remove-label are accepted)" >&2
-      exit 1
-      ;;
-  esac
-done
-
-if [[ ${#ADD_LABELS[@]} -eq 0 && ${#REMOVE_LABELS[@]} -eq 0 ]]; then
-  exit 1
-fi
-
-# Fetch valid labels from the repo
-VALID_LABELS=$(gh label list --limit 500 --json name --jq '.[].name')
-
-# Filter to only labels that exist in the repo
-FILTERED_ADD=()
-for label in "${ADD_LABELS[@]}"; do
-  if echo "$VALID_LABELS" | grep -qxF "$label"; then
-    FILTERED_ADD+=("$label")
-  fi
-done
-
-FILTERED_REMOVE=()
-for label in "${REMOVE_LABELS[@]}"; do
-  if echo "$VALID_LABELS" | grep -qxF "$label"; then
-    FILTERED_REMOVE+=("$label")
-  fi
-done
-
-if [[ ${#FILTERED_ADD[@]} -eq 0 && ${#FILTERED_REMOVE[@]} -eq 0 ]]; then
-  exit 0
-fi
-
-# Build gh command arguments
-GH_ARGS=("issue" "edit" "$ISSUE")
-
-for label in "${FILTERED_ADD[@]}"; do
-  GH_ARGS+=("--add-label" "$label")
-done
-
-for label in "${FILTERED_REMOVE[@]}"; do
-  GH_ARGS+=("--remove-label" "$label")
-done
-
-gh "${GH_ARGS[@]}"
-
-if [[ ${#FILTERED_ADD[@]} -gt 0 ]]; then
-  echo "Added: ${FILTERED_ADD[*]}"
-fi
-if [[ ${#FILTERED_REMOVE[@]} -gt 0 ]]; then
-  echo "Removed: ${FILTERED_REMOVE[*]}"
-fi

scripts/gh.sh

@@ -1,96 +0,0 @@
-#!/usr/bin/env bash
-set -euo pipefail
-
-# Wrapper around gh CLI that only allows specific subcommands and flags.
-# All commands are scoped to the current repository via GH_REPO or GITHUB_REPOSITORY.
-#
-# Usage:
-#   ./scripts/gh.sh issue view 123
-#   ./scripts/gh.sh issue view 123 --comments
-#   ./scripts/gh.sh issue list --state open --limit 20
-#   ./scripts/gh.sh search issues "search query" --limit 10
-#   ./scripts/gh.sh label list --limit 100
-
-export GH_HOST=github.com
-
-REPO="${GH_REPO:-${GITHUB_REPOSITORY:-}}"
-if [[ -z "$REPO" || "$REPO" == */*/* || "$REPO" != */* ]]; then
-  echo "Error: GH_REPO or GITHUB_REPOSITORY must be set to owner/repo format (e.g., GITHUB_REPOSITORY=anthropics/claude-code)" >&2
-  exit 1
-fi
-export GH_REPO="$REPO"
-
-ALLOWED_FLAGS=(--comments --state --limit --label)
-FLAGS_WITH_VALUES=(--state --limit --label)
-
-SUB1="${1:-}"
-SUB2="${2:-}"
-CMD="$SUB1 $SUB2"
-case "$CMD" in
-  "issue view"|"issue list"|"search issues"|"label list")
-    ;;
-  *)
-    echo "Error: only 'issue view', 'issue list', 'search issues', 'label list' are allowed (e.g., ./scripts/gh.sh issue view 123)" >&2
-    exit 1
-    ;;
-esac
-
-shift 2
-
-# Separate flags from positional arguments
-POSITIONAL=()
-FLAGS=()
-skip_next=false
-for arg in "$@"; do
-  if [[ "$skip_next" == true ]]; then
-    FLAGS+=("$arg")
-    skip_next=false
-  elif [[ "$arg" == -* ]]; then
-    flag="${arg%%=*}"
-    matched=false
-    for allowed in "${ALLOWED_FLAGS[@]}"; do
-      if [[ "$flag" == "$allowed" ]]; then
-        matched=true
-        break
-      fi
-    done
-    if [[ "$matched" == false ]]; then
-      echo "Error: only --comments, --state, --limit, --label flags are allowed (e.g., ./scripts/gh.sh issue list --state open --limit 20)" >&2
-      exit 1
-    fi
-    FLAGS+=("$arg")
-    # If flag expects a value and isn't using = syntax, skip next arg
-    if [[ "$arg" != *=* ]]; then
-      for vflag in "${FLAGS_WITH_VALUES[@]}"; do
-        if [[ "$flag" == "$vflag" ]]; then
-          skip_next=true
-          break
-        fi
-      done
-    fi
-  else
-    POSITIONAL+=("$arg")
-  fi
-done
-
-if [[ "$CMD" == "search issues" ]]; then
-  QUERY="${POSITIONAL[0]:-}"
-  QUERY_LOWER=$(echo "$QUERY" | tr '[:upper:]' '[:lower:]')
-  if [[ "$QUERY_LOWER" == *"repo:"* || "$QUERY_LOWER" == *"org:"* || "$QUERY_LOWER" == *"user:"* ]]; then
-    echo "Error: search query must not contain repo:, org:, or user: qualifiers (e.g., ./scripts/gh.sh search issues \"bug report\" --limit 10)" >&2
-    exit 1
-  fi
-  gh "$SUB1" "$SUB2" "$QUERY" --repo "$REPO" "${FLAGS[@]}"
-elif [[ "$CMD" == "issue view" ]]; then
-  if [[ ${#POSITIONAL[@]} -ne 1 ]] || ! [[ "${POSITIONAL[0]}" =~ ^[0-9]+$ ]]; then
-    echo "Error: issue view requires exactly one numeric issue number (e.g., ./scripts/gh.sh issue view 123)" >&2
-    exit 1
-  fi
-  gh "$SUB1" "$SUB2" "${POSITIONAL[0]}" "${FLAGS[@]}"
-else
-  if [[ ${#POSITIONAL[@]} -ne 0 ]]; then
-    echo "Error: issue list and label list do not accept positional arguments (e.g., ./scripts/gh.sh issue list --state open, ./scripts/gh.sh label list --limit 100)" >&2
-    exit 1
-  fi
-  gh "$SUB1" "$SUB2" "${FLAGS[@]}"
-fi