Add joke section to README

Updates edit-issue-labels.sh and comment-on-duplicates.sh to read the
issue number from GITHUB_EVENT_PATH (the workflow event payload) instead
of accepting it as a CLI argument. Simplifies the call signature and
keeps the scripts aligned with the triggering issue.

Also updates the /triage-issue and /dedupe command docs to match.

🏠 Remote-Dev: homespace

.claude-plugin/marketplace.json

@@ -15,14 +15,25 @@
       "category": "development"
     },
     {
-      "name": "pr-review-toolkit",
-      "description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
+      "name": "claude-opus-4-5-migration",
+      "description": "Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.",
       "version": "1.0.0",
       "author": {
-        "name": "Anthropic",
-        "email": "support@anthropic.com"
+        "name": "William Hu",
+        "email": "whu@anthropic.com"
       },
-      "source": "./plugins/pr-review-toolkit",
+      "source": "./plugins/claude-opus-4-5-migration",
+      "category": "development"
+    },
+    {
+      "name": "code-review",
+      "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
+      "version": "1.0.0",
+      "author": {
+        "name": "Boris Cherny",
+        "email": "boris@anthropic.com"
+      },
+      "source": "./plugins/code-review",
       "category": "productivity"
     },
     {
@@ -36,39 +47,6 @@
       "source": "./plugins/commit-commands",
       "category": "productivity"
     },
-    {
-      "name": "feature-dev",
-      "description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
-      "version": "1.0.0",
-      "author": {
-        "name": "Siddharth Bidasaria",
-        "email": "sbidasaria@anthropic.com"
-      },
-      "source": "./plugins/feature-dev",
-      "category": "development"
-    },
-    {
-      "name": "security-guidance",
-      "description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
-      "version": "1.0.0",
-      "author": {
-        "name": "David Dworken",
-        "email": "dworken@anthropic.com"
-      },
-      "source": "./plugins/security-guidance",
-      "category": "security"
-    },
-    {
-      "name": "code-review",
-      "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
-      "version": "1.0.0",
-      "author": {
-        "name": "Boris Cherny",
-        "email": "boris@anthropic.com"
-      },
-      "source": "./plugins/code-review",
-      "category": "productivity"
-    },
     {
       "name": "explanatory-output-style",
       "description": "Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style)",
@@ -81,15 +59,15 @@
       "category": "learning"
     },
     {
-      "name": "learning-output-style",
-      "description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
+      "name": "feature-dev",
+      "description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
       "version": "1.0.0",
       "author": {
-        "name": "Boris Cherny",
-        "email": "boris@anthropic.com"
+        "name": "Siddharth Bidasaria",
+        "email": "sbidasaria@anthropic.com"
       },
-      "source": "./plugins/learning-output-style",
-      "category": "learning"
+      "source": "./plugins/feature-dev",
+      "category": "development"
     },
     {
       "name": "frontend-design",
@@ -102,17 +80,6 @@
       "source": "./plugins/frontend-design",
       "category": "development"
     },
-    {
-      "name": "ralph-wiggum",
-      "description": "Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly, seeing its previous work, until completion.",
-      "version": "1.0.0",
-      "author": {
-        "name": "Daisy Hollman",
-        "email": "daisy@anthropic.com"
-      },
-      "source": "./plugins/ralph-wiggum",
-      "category": "development"
-    },
     {
       "name": "hookify",
       "description": "Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or from explicit instructions. Define rules via simple markdown files.",
@@ -124,6 +91,17 @@
       "source": "./plugins/hookify",
       "category": "productivity"
     },
+    {
+      "name": "learning-output-style",
+      "description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
+      "version": "1.0.0",
+      "author": {
+        "name": "Boris Cherny",
+        "email": "boris@anthropic.com"
+      },
+      "source": "./plugins/learning-output-style",
+      "category": "learning"
+    },
     {
       "name": "plugin-dev",
       "description": "Comprehensive toolkit for developing Claude Code plugins. Includes 7 expert skills covering hooks, MCP integration, commands, agents, and best practices. AI-assisted plugin creation and validation.",
@@ -134,6 +112,39 @@
       },
       "source": "./plugins/plugin-dev",
       "category": "development"
+    },
+    {
+      "name": "pr-review-toolkit",
+      "description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
+      "version": "1.0.0",
+      "author": {
+        "name": "Anthropic",
+        "email": "support@anthropic.com"
+      },
+      "source": "./plugins/pr-review-toolkit",
+      "category": "productivity"
+    },
+    {
+      "name": "ralph-wiggum",
+      "description": "Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly, seeing its previous work, until completion.",
+      "version": "1.0.0",
+      "author": {
+        "name": "Daisy Hollman",
+        "email": "daisy@anthropic.com"
+      },
+      "source": "./plugins/ralph-wiggum",
+      "category": "development"
+    },
+    {
+      "name": "security-guidance",
+      "description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
+      "version": "1.0.0",
+      "author": {
+        "name": "David Dworken",
+        "email": "dworken@anthropic.com"
+      },
+      "source": "./plugins/security-guidance",
+      "category": "security"
     }
   ]
 }

.claude/commands/dedupe.md

@@ -1,5 +1,5 @@
 ---
-allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh api:*), Bash(gh issue comment:*)
+allowed-tools: Bash(./scripts/gh.sh:*), Bash(./scripts/comment-on-duplicates.sh:*)
 description: Find duplicate GitHub issues
 ---
 
@@ -11,28 +11,17 @@ To do this, follow these steps precisely:
 2. Use an agent to view a Github issue, and ask the agent to return a summary of the issue
 3. Then, launch 5 parallel agents to search Github for duplicates of this issue, using diverse keywords and search approaches, using the summary from #1
 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, comment back on the issue with a list of up to three duplicate issues (or zero, if there are no likely duplicates)
+5. Finally, use the comment script to post duplicates:
+   ```
+   ./scripts/comment-on-duplicates.sh --potential-duplicates <dup1> <dup2> <dup3>
+   ```
 
 Notes (be sure to tell this to your agents, too):
 
-- Use `gh` to interact with Github, rather than web fetch
-- Do not use other tools, beyond `gh` (eg. don't use other MCP servers, file edit, etc.)
+- 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.)
 - Make a todo list first
-- For your comment, follow the following format precisely (assuming for this example that you found 3 suspected duplicates):
-
----
-
-Found 3 possible duplicate issues:
-
-1. <link to issue>
-2. <link to issue>
-3. <link to issue>
-
-This issue will be automatically closed as a duplicate in 3 days.
-
-- If your issue is a duplicate, please close it and 👍 the existing issue instead
-- To prevent auto-closure, add a comment or 👎 this comment
-
-🤖 Generated with [Claude Code](https://claude.ai/code)
-
----

.claude/commands/oncall-triage.md

@@ -1,40 +0,0 @@
----
-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

@@ -0,0 +1,70 @@
+---
+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

@@ -23,13 +23,16 @@ jobs:
         uses: actions/checkout@v4
 
       - name: Run Claude Code slash command
-        uses: anthropics/claude-code-base-action@beta
+        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: "*"
           prompt: "/dedupe ${{ github.repository }}/issues/${{ github.event.issue.number || inputs.issue_number }}"
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           claude_args: "--model claude-sonnet-4-5-20250929"
-          claude_env: |
-            GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
 
       - name: Log duplicate comment event to Statsig
         if: always()

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

@@ -1,13 +1,20 @@
 name: Claude Issue Triage
-description: Automatically triage GitHub issues using Claude Code
 on:
   issues:
     types: [opened]
+  issue_comment:
+    types: [created]
 
 jobs:
   triage-issue:
     runs-on: ubuntu-latest
     timeout-minutes: 10
+    if: >-
+      github.event_name == 'issues' ||
+      (github.event_name == 'issue_comment' && !github.event.issue.pull_request && github.event.comment.user.type != 'Bot')
+    concurrency:
+      group: issue-triage-${{ github.event.issue.number }}
+      cancel-in-progress: true
     permissions:
       contents: read
       issues: write
@@ -16,92 +23,17 @@ jobs:
       - name: Checkout repository
         uses: actions/checkout@v4
 
-      - name: Create triage prompt
-        run: |
-          mkdir -p /tmp/claude-prompts
-          cat > /tmp/claude-prompts/triage-prompt.txt << 'EOF'
-          You're an issue triage assistant for GitHub issues. Your task is to analyze the issue and select appropriate labels from the provided list.
-
-          IMPORTANT: Don't post any comments or messages to the issue. Your only action should be to apply labels.
-
-          Issue Information:
-          - REPO: ${{ github.repository }}
-          - ISSUE_NUMBER: ${{ github.event.issue.number }}
-
-          TASK OVERVIEW:
-
-          1. First, fetch the list of labels available in this repository by running: `gh label list`. Run exactly this command with nothing else.
-
-          2. Next, use the GitHub tools to get context about the issue:
-             - You have access to these tools:
-               - mcp__github__get_issue: Use this to retrieve the current issue's details including title, description, and existing labels
-               - mcp__github__get_issue_comments: Use this to read any discussion or additional context provided in the comments
-               - mcp__github__update_issue: Use this to apply labels to the issue (do not use this for commenting)
-               - mcp__github__search_issues: Use this to find similar issues that might provide context for proper categorization and to identify potential duplicate issues
-               - mcp__github__list_issues: Use this to understand patterns in how other issues are labeled
-             - Start by using mcp__github__get_issue to get the issue details
-
-          3. Analyze the issue content, considering:
-             - The issue title and description
-             - The type of issue (bug report, feature request, question, etc.)
-             - Technical areas mentioned
-             - Severity or priority indicators
-             - User impact
-             - Components affected
-
-          4. Select appropriate labels from the available labels list provided above:
-             - Choose labels that accurately reflect the issue's nature
-             - Be specific but comprehensive
-             - Select priority labels if you can determine urgency (high-priority, med-priority, or low-priority)
-             - Consider platform labels (android, ios) if applicable
-             - If you find similar issues using mcp__github__search_issues, consider using a "duplicate" label if appropriate. Only do so if the issue is a duplicate of another OPEN issue.
-
-          5. Apply the selected labels:
-             - Use mcp__github__update_issue to apply your selected labels
-             - DO NOT post any comments explaining your decision
-             - DO NOT communicate directly with users
-             - If no labels are clearly applicable, do not apply any labels
-
-          IMPORTANT GUIDELINES:
-          - Be thorough in your analysis
-          - Only select labels from the provided list above
-          - DO NOT post any comments to the issue
-          - Your ONLY action should be to apply labels using mcp__github__update_issue
-          - It's okay to not add any labels if none are clearly applicable
-          EOF
-
-      - 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 Issue Triage
-        uses: anthropics/claude-code-base-action@beta
+        timeout-minutes: 5
+        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:
-          prompt_file: /tmp/claude-prompts/triage-prompt.txt
-          allowed_tools: "Bash(gh label list),mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue,mcp__github__search_issues,mcp__github__list_issues"
-          timeout_minutes: "5"
+          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 }}"
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
-          mcp_config: /tmp/mcp-config/mcp-servers.json
-          claude_args: "--model claude-sonnet-4-5-20250929"
-          claude_env: |
-            GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          claude_args: |
+            --model claude-opus-4-6

.github/workflows/claude.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: Run Claude Code
         id: claude
-        uses: anthropics/claude-code-action@beta
+        uses: anthropics/claude-code-action@v1
         with:
           anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
           claude_args: "--model claude-sonnet-4-5-20250929"

.github/workflows/issue-lifecycle-comment.yml

@@ -0,0 +1,27 @@
+name: "Issue Lifecycle Comment"
+
+on:
+  issues:
+    types: [labeled]
+
+permissions:
+  issues: write
+
+jobs:
+  comment:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Post lifecycle comment
+        run: bun run scripts/lifecycle-comment.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          LABEL: ${{ github.event.label.name }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}

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

@@ -0,0 +1,47 @@
+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

@@ -1,120 +0,0 @@
-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
-
-    steps:
-      - name: Checkout repository
-        uses: actions/checkout@v4
-
-      - name: Create oncall triage prompt
-        run: |
-          mkdir -p /tmp/claude-prompts
-          cat > /tmp/claude-prompts/oncall-triage-prompt.txt << 'EOF'
-          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
-          EOF
-
-      - 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
-        uses: anthropics/claude-code-base-action@beta
-        with:
-          prompt_file: /tmp/claude-prompts/oncall-triage-prompt.txt
-          allowed_tools: "mcp__github__list_issues,mcp__github__get_issue,mcp__github__get_issue_comments,mcp__github__update_issue"
-          timeout_minutes: "10"
-          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
-          mcp_config: /tmp/mcp-config/mcp-servers.json
-          claude_env: |
-            GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/remove-autoclose-label.yml

@@ -0,0 +1,42 @@
+name: "Remove Autoclose Label on Activity"
+
+on:
+  issue_comment:
+    types: [created]
+
+permissions:
+  issues: write
+
+jobs:
+  remove-autoclose:
+    # Only run if the issue has the autoclose label
+    if: |
+      github.event.issue.state == 'open' &&
+      contains(github.event.issue.labels.*.name, 'autoclose') &&
+      github.event.comment.user.login != 'github-actions[bot]'
+    runs-on: ubuntu-latest
+    steps:
+      - name: Remove autoclose label
+        uses: actions/github-script@v7
+        with:
+          script: |
+            console.log(`Removing autoclose label from issue #${context.issue.number} due to new comment from ${context.payload.comment.user.login}`);
+            
+            try {
+              // Remove the autoclose label
+              await github.rest.issues.removeLabel({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                issue_number: context.issue.number,
+                name: 'autoclose'
+              });
+              
+              console.log(`Successfully removed autoclose label from issue #${context.issue.number}`);
+            } catch (error) {
+              // If the label was already removed or doesn't exist, that's fine
+              if (error.status === 404) {
+                console.log(`Autoclose label was already removed from issue #${context.issue.number}`);
+              } else {
+                throw error;
+              }
+            }

.github/workflows/sweep.yml

@@ -0,0 +1,31 @@
+name: "Issue Sweep"
+
+on:
+  schedule:
+    - cron: "0 10,22 * * *"
+  workflow_dispatch:
+
+permissions:
+  issues: write
+
+concurrency:
+  group: daily-issue-sweep
+
+jobs:
+  sweep:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Enforce lifecycle timeouts
+        run: bun run scripts/sweep.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_REPOSITORY_OWNER: ${{ github.repository_owner }}
+          GITHUB_REPOSITORY_NAME: ${{ github.event.repository.name }}

README.md

@@ -6,35 +6,42 @@
 
 Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows -- all through natural language commands. Use it in your terminal, IDE, or tag @claude on Github.
 
-**Learn more in the [official documentation](https://docs.anthropic.com/en/docs/claude-code/overview)**.
+**Learn more in the [official documentation](https://code.claude.com/docs/en/overview)**.
 
 <img src="./demo.gif" />
 
 ## Get started
+> [!NOTE]
+> Installation via npm is deprecated. Use one of the recommended methods below.
+
+For more installation options, uninstall steps, and troubleshooting, see the [setup documentation](https://code.claude.com/docs/en/setup).
 
 1. Install Claude Code:
 
-**MacOS/Linux:**
-```bash
-curl -fsSL https://claude.ai/install.sh | bash
-```
+    **MacOS/Linux (Recommended):**
+    ```bash
+    curl -fsSL https://claude.ai/install.sh | bash
+    ```
 
-**Homebrew (MacOS):**
-```bash
-brew install --cask claude-code
-```
+    **Homebrew (MacOS/Linux):**
+    ```bash
+    brew install --cask claude-code
+    ```
 
-**Windows:**
-```powershell
-irm https://claude.ai/install.ps1 | iex
-```
+    **Windows (Recommended):**
+    ```powershell
+    irm https://claude.ai/install.ps1 | iex
+    ```
 
-**NPM:**
-```bash
-npm install -g @anthropic-ai/claude-code
-```
+    **WinGet (Windows):**
+    ```powershell
+    winget install Anthropic.ClaudeCode
+    ```
 
-NOTE: If installing with NPM, you also need to install [Node.js 18+](https://nodejs.org/en/download/)
+    **NPM (Deprecated):**
+    ```bash
+    npm install -g @anthropic-ai/claude-code
+    ```
 
 2. Navigate to your project directory and run `claude`.
 
@@ -42,6 +49,10 @@ NOTE: If installing with NPM, you also need to install [Node.js 18+](https://nod
 
 This repository includes several Claude Code plugins that extend functionality with custom commands and agents. See the [plugins directory](./plugins/README.md) for detailed documentation on available plugins.
 
+## Joke
+
+Why do programmers prefer dark mode? Because light attracts bugs.
+
 ## Reporting Bugs
 
 We welcome your feedback. Use the `/bug` command to report issues directly within Claude Code, or file a [GitHub issue](https://github.com/anthropics/claude-code/issues).
@@ -56,7 +67,7 @@ When you use Claude Code, we collect feedback, which includes usage data (such a
 
 ### How we use your data
 
-See our [data usage policies](https://docs.anthropic.com/en/docs/claude-code/data-usage).
+See our [data usage policies](https://code.claude.com/docs/en/data-usage).
 
 ### Privacy safeguards
 

examples/settings/README.md

@@ -0,0 +1,31 @@
+# Settings Examples
+
+Example Claude Code settings files, primarily intended for organization-wide deployments. Use these are starting points — adjust them to fit your needs.
+
+These may be applied at any level of the [settings hierarchy](https://code.claude.com/docs/en/settings#settings-files), though certain properties only take effect if specified in enterprise settings (e.g. `strictKnownMarketplaces`, `allowManagedHooksOnly`, `allowManagedPermissionRulesOnly`).
+
+
+## Configuration Examples
+
+> [!WARNING]
+> These examples are community-maintained snippets which may be unsupported or incorrect. You are responsible for the correctness of your own settings configuration.
+
+| Setting | [`settings-lax.json`](./settings-lax.json) | [`settings-strict.json`](./settings-strict.json) | [`settings-bash-sandbox.json`](./settings-bash-sandbox.json) |
+|---------|:---:|:---:|:---:|
+| Disable `--dangerously-skip-permissions` | ✅ | ✅ | |
+| Block plugin marketplaces | ✅ | ✅ | |
+| Block user and project-defined permission `allow` / `ask` / `deny` | | ✅ | ✅ |
+| Block user and project-defined hooks | | ✅ | |
+| Deny web fetch and search tools | | ✅ | |
+| Bash tool requires approval | | ✅ | |
+| Bash tool must run inside of sandbox | | | ✅ |
+
+## Tips
+- Consider merging snippets of the above examples to reach your desired configuration
+- Settings files must be valid JSON
+- Before deploying configuration files to your organization, test them locally by applying to `managed-settings.json`, `settings.json` or `settings.local.json`
+- The `sandbox` property only applies to the `Bash` tool; it does not apply to other tools (like Read, Write, WebSearch, WebFetch, MCPs), hooks, or internal commands
+
+## Full Documentation
+
+See https://code.claude.com/docs/en/settings for complete documentation on all available managed settings.

examples/settings/settings-bash-sandbox.json

@@ -0,0 +1,18 @@
+{
+  "allowManagedPermissionRulesOnly": true,
+  "sandbox": {
+    "enabled": true,
+    "autoAllowBashIfSandboxed": false,
+    "allowUnsandboxedCommands": false,
+    "excludedCommands": [],
+    "network": {
+      "allowUnixSockets": [],
+      "allowAllUnixSockets": false,
+      "allowLocalBinding": false,
+      "allowedDomains": [],
+      "httpProxyPort": null,
+      "socksProxyPort": null
+    },
+    "enableWeakerNestedSandbox": false
+  }
+}

examples/settings/settings-lax.json

@@ -0,0 +1,6 @@
+{
+  "permissions": {
+    "disableBypassPermissionsMode": "disable"
+  },
+  "strictKnownMarketplaces": []
+}

examples/settings/settings-strict.json

@@ -0,0 +1,28 @@
+{
+  "permissions": {
+    "disableBypassPermissionsMode": "disable",
+    "ask": [
+      "Bash"
+    ],
+    "deny": [
+      "WebSearch",
+      "WebFetch"
+    ]
+  },
+  "allowManagedPermissionRulesOnly": true,
+  "allowManagedHooksOnly": true,
+  "strictKnownMarketplaces": [],
+  "sandbox": {
+    "autoAllowBashIfSandboxed": false,
+    "excludedCommands": [],
+    "network": {
+      "allowUnixSockets": [],
+      "allowAllUnixSockets": false,
+      "allowLocalBinding": false,
+      "allowedDomains": [],
+      "httpProxyPort": null,
+      "socksProxyPort": null
+    },
+    "enableWeakerNestedSandbox": false
+  }
+}

plugins/README.md

@@ -10,50 +10,21 @@ Learn more in the [official plugins documentation](https://docs.claude.com/en/do
 
 ## Plugins in This Directory
 
-### [agent-sdk-dev](./agent-sdk-dev/)
-
-**Claude Agent SDK Development Plugin**
-
-Streamlines the development of Claude Agent SDK applications with scaffolding commands and verification agents.
-
-- **Command**: `/new-sdk-app` - Interactive setup for new Agent SDK projects
-- **Agents**: `agent-sdk-verifier-py` and `agent-sdk-verifier-ts` - Validate SDK applications against best practices
-- **Use case**: Creating and verifying Claude Agent SDK applications in Python or TypeScript
-
-### [commit-commands](./commit-commands/)
-
-**Git Workflow Automation Plugin**
-
-Simplifies common git operations with streamlined commands for committing, pushing, and creating pull requests.
-
-- **Commands**:
-  - `/commit` - Create a git commit with appropriate message
-  - `/commit-push-pr` - Commit, push, and create a PR in one command
-  - `/clean_gone` - Clean up stale local branches marked as [gone]
-- **Use case**: Faster git workflows with less context switching
-
-### [code-review](./code-review/)
-
-**Automated Pull Request Code Review Plugin**
-
-Provides automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives.
-
-- **Command**:
-  - `/code-review` - Automated PR review workflow
-- **Use case**: Automated code review on pull requests with high-confidence issue detection (threshold ≥80)
-
-### [feature-dev](./feature-dev/)
-
-**Comprehensive Feature Development Workflow Plugin**
-
-Provides a structured 7-phase approach to feature development with specialized agents for exploration, architecture, and review.
-
-- **Command**: `/feature-dev` - Guided feature development workflow
-- **Agents**:
-  - `code-explorer` - Deeply analyzes existing codebase features
-  - `code-architect` - Designs feature architectures and implementation blueprints
-  - `code-reviewer` - Reviews code for bugs, quality issues, and project conventions
-- **Use case**: Building new features with systematic codebase understanding and quality assurance
+| Name | Description | Contents |
+|------|-------------|----------|
+| [agent-sdk-dev](./agent-sdk-dev/) | Development kit for working with the Claude Agent SDK | **Command:** `/new-sdk-app` - Interactive setup for new Agent SDK projects<br>**Agents:** `agent-sdk-verifier-py`, `agent-sdk-verifier-ts` - Validate SDK applications against best practices |
+| [claude-opus-4-5-migration](./claude-opus-4-5-migration/) | Migrate code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5 | **Skill:** `claude-opus-4-5-migration` - Automated migration of model strings, beta headers, and prompt adjustments |
+| [code-review](./code-review/) | Automated PR code review using multiple specialized agents with confidence-based scoring to filter false positives | **Command:** `/code-review` - Automated PR review workflow<br>**Agents:** 5 parallel Sonnet agents for CLAUDE.md compliance, bug detection, historical context, PR history, and code comments |
+| [commit-commands](./commit-commands/) | Git workflow automation for committing, pushing, and creating pull requests | **Commands:** `/commit`, `/commit-push-pr`, `/clean_gone` - Streamlined git operations |
+| [explanatory-output-style](./explanatory-output-style/) | Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style) | **Hook:** SessionStart - Injects educational context at the start of each session |
+| [feature-dev](./feature-dev/) | Comprehensive feature development workflow with a structured 7-phase approach | **Command:** `/feature-dev` - Guided feature development workflow<br>**Agents:** `code-explorer`, `code-architect`, `code-reviewer` - For codebase analysis, architecture design, and quality review |
+| [frontend-design](./frontend-design/) | Create distinctive, production-grade frontend interfaces that avoid generic AI aesthetics | **Skill:** `frontend-design` - Auto-invoked for frontend work, providing guidance on bold design choices, typography, animations, and visual details |
+| [hookify](./hookify/) | Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or explicit instructions | **Commands:** `/hookify`, `/hookify:list`, `/hookify:configure`, `/hookify:help`<br>**Agent:** `conversation-analyzer` - Analyzes conversations for problematic behaviors<br>**Skill:** `writing-rules` - Guidance on hookify rule syntax |
+| [learning-output-style](./learning-output-style/) | Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style) | **Hook:** SessionStart - Encourages users to write meaningful code (5-10 lines) at decision points while receiving educational insights |
+| [plugin-dev](./plugin-dev/) | Comprehensive toolkit for developing Claude Code plugins with 7 expert skills and AI-assisted creation | **Command:** `/plugin-dev:create-plugin` - 8-phase guided workflow for building plugins<br>**Agents:** `agent-creator`, `plugin-validator`, `skill-reviewer`<br>**Skills:** Hook development, MCP integration, plugin structure, settings, commands, agents, and skill development |
+| [pr-review-toolkit](./pr-review-toolkit/) | Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification | **Command:** `/pr-review-toolkit:review-pr` - Run with optional review aspects (comments, tests, errors, types, code, simplify, all)<br>**Agents:** `comment-analyzer`, `pr-test-analyzer`, `silent-failure-hunter`, `type-design-analyzer`, `code-reviewer`, `code-simplifier` |
+| [ralph-wiggum](./ralph-wiggum/) | Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly until completion | **Commands:** `/ralph-loop`, `/cancel-ralph` - Start/stop autonomous iteration loops<br>**Hook:** Stop - Intercepts exit attempts to continue iteration |
+| [security-guidance](./security-guidance/) | Security reminder hook that warns about potential security issues when editing files | **Hook:** PreToolUse - Monitors 9 security patterns including command injection, XSS, eval usage, dangerous HTML, pickle deserialization, and os.system calls |
 
 ## Installation
 
@@ -81,8 +52,11 @@ Each plugin follows the standard Claude Code plugin structure:
 plugin-name/
 ├── .claude-plugin/
 │   └── plugin.json          # Plugin metadata
-├── commands/                 # Slash commands (optional)
-├── agents/                   # Specialized agents (optional)
+├── commands/                # Slash commands (optional)
+├── agents/                  # Specialized agents (optional)
+├── skills/                  # Agent Skills (optional)
+├── hooks/                   # Event handlers (optional)
+├── .mcp.json                # External tool configuration (optional)
 └── README.md                # Plugin documentation
 ```
 

plugins/claude-opus-4-5-migration/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "claude-opus-4-5-migration",
+  "version": "1.0.0",
+  "description": "Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.",
+  "author": {
+    "name": "William Hu",
+    "email": "whu@anthropic.com"
+  }
+}

plugins/claude-opus-4-5-migration/README.md

@@ -0,0 +1,21 @@
+# Claude Opus 4.5 Migration Plugin
+
+Migrate your code and prompts from Sonnet 4.x and Opus 4.1 to Opus 4.5.
+
+## Overview
+
+This skill updates your code and prompts to be compatible with Opus 4.5. It automates the migration process, handling model strings, beta headers, and other configuration details. If you run into any issues with Opus 4.5 after migration, you can continue using this skill to adjust your prompts.
+
+## Usage
+
+```
+"Migrate my codebase to Opus 4.5"
+```
+
+## Learn More
+
+Refer to our [prompting guide](https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-4-best-practices) for best practices on prompting Claude models.
+
+## Authors
+
+William Hu (whu@anthropic.com)

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/SKILL.md

@@ -0,0 +1,105 @@
+---
+name: claude-opus-4-5-migration
+description: Migrate prompts and code from Claude Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5. Use when the user wants to update their codebase, prompts, or API calls to use Opus 4.5. Handles model string updates and prompt adjustments for known Opus 4.5 behavioral differences. Does NOT migrate Haiku 4.5.
+---
+
+# Opus 4.5 Migration Guide
+
+One-shot migration from Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5.
+
+## Migration Workflow
+
+1. Search codebase for model strings and API calls
+2. Update model strings to Opus 4.5 (see platform-specific strings below)
+3. Remove unsupported beta headers
+4. Add effort parameter set to `"high"` (see `references/effort.md`)
+5. Summarize all changes made
+6. Tell the user: "If you encounter any issues with Opus 4.5, let me know and I can help adjust your prompts."
+
+## Model String Updates
+
+Identify which platform the codebase uses, then replace model strings accordingly.
+
+### Unsupported Beta Headers
+
+Remove the `context-1m-2025-08-07` beta header if present—it is not yet supported with Opus 4.5. Leave a comment noting this:
+
+```python
+# Note: 1M context beta (context-1m-2025-08-07) not yet supported with Opus 4.5
+```
+
+### Target Model Strings (Opus 4.5)
+
+| Platform | Opus 4.5 Model String |
+|----------|----------------------|
+| Anthropic API (1P) | `claude-opus-4-5-20251101` |
+| AWS Bedrock | `anthropic.claude-opus-4-5-20251101-v1:0` |
+| Google Vertex AI | `claude-opus-4-5@20251101` |
+| Azure AI Foundry | `claude-opus-4-5-20251101` |
+
+### Source Model Strings to Replace
+
+| Source Model | Anthropic API (1P) | AWS Bedrock | Google Vertex AI |
+|--------------|-------------------|-------------|------------------|
+| Sonnet 4.0 | `claude-sonnet-4-20250514` | `anthropic.claude-sonnet-4-20250514-v1:0` | `claude-sonnet-4@20250514` |
+| Sonnet 4.5 | `claude-sonnet-4-5-20250929` | `anthropic.claude-sonnet-4-5-20250929-v1:0` | `claude-sonnet-4-5@20250929` |
+| Opus 4.1 | `claude-opus-4-1-20250422` | `anthropic.claude-opus-4-1-20250422-v1:0` | `claude-opus-4-1@20250422` |
+
+**Do NOT migrate**: Any Haiku models (e.g., `claude-haiku-4-5-20251001`).
+
+## Prompt Adjustments
+
+Opus 4.5 has known behavioral differences from previous models. **Only apply these fixes if the user explicitly requests them or reports a specific issue.** By default, just update model strings.
+
+**Integration guidelines**: When adding snippets, don't just append them to prompts. Integrate them thoughtfully:
+- Use XML tags (e.g., `<code_guidelines>`, `<tool_usage>`) to organize additions
+- Match the style and structure of the existing prompt
+- Place snippets in logical locations (e.g., coding guidelines near other coding instructions)
+- If the prompt already uses XML tags, add new content within appropriate existing tags or create consistent new ones
+
+### 1. Tool Overtriggering
+
+Opus 4.5 is more responsive to system prompts. Aggressive language that prevented undertriggering on previous models may now cause overtriggering.
+
+**Apply if**: User reports tools being called too frequently or unnecessarily.
+
+**Find and soften**:
+- `CRITICAL:` → remove or soften
+- `You MUST...` → `You should...`
+- `ALWAYS do X` → `Do X`
+- `NEVER skip...` → `Don't skip...`
+- `REQUIRED` → remove or soften
+
+Only apply to tool-triggering instructions. Leave other uses of emphasis alone.
+
+### 2. Over-Engineering Prevention
+
+Opus 4.5 tends to create extra files, add unnecessary abstractions, or build unrequested flexibility.
+
+**Apply if**: User reports unwanted files, excessive abstraction, or unrequested features. Add the snippet from `references/prompt-snippets.md`.
+
+### 3. Code Exploration
+
+Opus 4.5 can be overly conservative about exploring code, proposing solutions without reading files.
+
+**Apply if**: User reports the model proposing fixes without inspecting relevant code. Add the snippet from `references/prompt-snippets.md`.
+
+### 4. Frontend Design
+
+**Apply if**: User requests improved frontend design quality or reports generic-looking outputs.
+
+Add the frontend aesthetics snippet from `references/prompt-snippets.md`.
+
+### 5. Thinking Sensitivity
+
+When extended thinking is not enabled (the default), Opus 4.5 is particularly sensitive to the word "think" and its variants. Extended thinking is enabled only if the API request contains a `thinking` parameter.
+
+**Apply if**: User reports issues related to "thinking" while extended thinking is not enabled (no `thinking` parameter in request).
+
+Replace "think" with alternatives like "consider," "believe," or "evaluate."
+
+## Reference
+
+See `references/prompt-snippets.md` for the full text of each snippet to add.
+
+See `references/effort.md` for configuring the effort parameter (only if user requests it).

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/references/effort.md

@@ -0,0 +1,70 @@
+# Effort Parameter (Beta)
+
+**Add effort set to `"high"` during migration.** This is the default configuration for best performance with Opus 4.5.
+
+## Overview
+
+Effort controls how eagerly Claude spends tokens. It affects all tokens: thinking, text responses, and function calls.
+
+| Effort | Use Case |
+|--------|----------|
+| `high` | Best performance, deep reasoning (default) |
+| `medium` | Balance of cost/latency vs. performance |
+| `low` | Simple, high-volume queries; significant token savings |
+
+## Implementation
+
+Requires beta flag `effort-2025-11-24` in API calls.
+
+**Python SDK:**
+```python
+response = client.messages.create(
+    model="claude-opus-4-5-20251101",
+    max_tokens=1024,
+    betas=["effort-2025-11-24"],
+    output_config={
+        "effort": "high"  # or "medium" or "low"
+    },
+    messages=[...]
+)
+```
+
+**TypeScript SDK:**
+```typescript
+const response = await client.messages.create({
+  model: "claude-opus-4-5-20251101",
+  max_tokens: 1024,
+  betas: ["effort-2025-11-24"],
+  output_config: {
+    effort: "high"  // or "medium" or "low"
+  },
+  messages: [...]
+});
+```
+
+**Raw API:**
+```json
+{
+  "model": "claude-opus-4-5-20251101",
+  "max_tokens": 1024,
+  "anthropic-beta": "effort-2025-11-24",
+  "output_config": {
+    "effort": "high"
+  },
+  "messages": [...]
+}
+```
+
+## Effort vs. Thinking Budget
+
+Effort is independent of thinking budget:
+
+- High effort + no thinking = more tokens, but no thinking tokens
+- High effort + 32k thinking = more tokens, but thinking capped at 32k
+
+## Recommendations
+
+1. First determine effort level, then set thinking budget
+2. Best performance: high effort + high thinking budget
+3. Cost/latency optimization: medium effort
+4. Simple high-volume queries: low effort

plugins/claude-opus-4-5-migration/skills/claude-opus-4-5-migration/references/prompt-snippets.md

@@ -0,0 +1,106 @@
+# Prompt Snippets for Opus 4.5
+
+Only apply these snippets if the user explicitly requests them or reports a specific issue. By default, the migration should only update model strings.
+
+## 1. Tool Overtriggering
+
+**Problem**: Prompts designed to reduce undertriggering on previous models may cause Opus 4.5 to overtrigger.
+
+**When to add**: User reports tools being called too frequently or unnecessarily.
+
+**Solution**: Replace aggressive language with normal phrasing.
+
+| Before | After |
+|--------|-------|
+| `CRITICAL: You MUST use this tool when...` | `Use this tool when...` |
+| `ALWAYS call the search function before...` | `Call the search function before...` |
+| `You are REQUIRED to...` | `You should...` |
+| `NEVER skip this step` | `Don't skip this step` |
+
+## 2. Over-Engineering Prevention
+
+**Problem**: Opus 4.5 may create extra files, add unnecessary abstractions, or build unrequested flexibility.
+
+**When to add**: User reports unwanted files, excessive abstraction, or unrequested features.
+
+**Snippet to add to system prompt**:
+
+```
+- Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused.
+- Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.
+- Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs). Don't use backwards-compatibility shims when you can just change the code.
+- Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task. Reuse existing abstractions where possible and follow the DRY principle.
+```
+
+## 3. Code Exploration
+
+**Problem**: Opus 4.5 may propose solutions without reading code or make assumptions about unread files.
+
+**When to add**: User reports the model proposing fixes without inspecting relevant code.
+
+**Snippet to add to system prompt**:
+
+```
+ALWAYS read and understand relevant files before proposing code edits. Do not speculate about code you have not inspected. If the user references a specific file/path, you MUST open and inspect it before explaining or proposing fixes. Be rigorous and persistent in searching code for key facts. Thoroughly review the style, conventions, and abstractions of the codebase before implementing new features or abstractions.
+```
+
+## 4. Frontend Design Quality
+
+**Problem**: Default frontend outputs may look generic ("AI slop" aesthetic).
+
+**When to add**: User requests improved frontend design quality or reports generic-looking outputs.
+
+**Snippet to add to system prompt**:
+
+```xml
+<frontend_aesthetics>
+You tend to converge toward generic, "on distribution" outputs. In frontend design, this creates what users call the "AI slop" aesthetic. Avoid this: make creative, distinctive frontends that surprise and delight.
+
+Focus on:
+- Typography: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics.
+- Color & Theme: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes. Draw from IDE themes and cultural aesthetics for inspiration.
+- Motion: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions.
+- Backgrounds: Create atmosphere and depth rather than defaulting to solid colors. Layer CSS gradients, use geometric patterns, or add contextual effects that match the overall aesthetic.
+
+Avoid generic AI-generated aesthetics:
+- Overused font families (Inter, Roboto, Arial, system fonts)
+- Clichéd color schemes (particularly purple gradients on white backgrounds)
+- Predictable layouts and component patterns
+- Cookie-cutter design that lacks context-specific character
+
+Interpret creatively and make unexpected choices that feel genuinely designed for the context. Vary between light and dark themes, different fonts, different aesthetics. You still tend to converge on common choices (Space Grotesk, for example) across generations. Avoid this: it is critical that you think outside the box!
+</frontend_aesthetics>
+```
+
+## 5. Thinking Sensitivity
+
+**Problem**: When extended thinking is not enabled (the default), Opus 4.5 is particularly sensitive to the word "think" and its variants.
+
+Extended thinking is not enabled by default. It is only enabled if the API request contains a `thinking` parameter:
+```json
+"thinking": {
+    "type": "enabled",
+    "budget_tokens": 10000
+}
+```
+
+**When to apply**: User reports issues related to "thinking" while extended thinking is not enabled (no `thinking` parameter in their request).
+
+**Solution**: Replace "think" with alternative words.
+
+| Before | After |
+|--------|-------|
+| `think about` | `consider` |
+| `think through` | `evaluate` |
+| `I think` | `I believe` |
+| `think carefully` | `consider carefully` |
+| `thinking` | `reasoning` / `considering` |
+
+## Usage Guidelines
+
+1. **Integrate thoughtfully** - Don't just append snippets; weave them into the existing prompt structure
+2. **Use XML tags** - Wrap additions in descriptive tags (e.g., `<coding_guidelines>`, `<tool_behavior>`) that match or complement existing prompt structure
+3. **Match prompt style** - If the prompt is concise, trim the snippet; if verbose, keep full detail
+4. **Place logically** - Put coding snippets near other coding instructions, tool guidance near tool definitions, etc.
+5. **Preserve existing content** - Insert snippets without removing functional content
+6. **Summarize changes** - After migration, list all model string updates and prompt modifications made

plugins/code-review/README.md

@@ -22,23 +22,29 @@ Performs automated code review on a pull request using multiple specialized agen
    - **Agent #4**: Analyze git blame/history for context-based issues
 5. Scores each issue 0-100 for confidence level
 6. Filters out issues below 80 confidence threshold
-7. Posts review comment with high-confidence issues only
+7. Outputs review (to terminal by default, or as PR comment with `--comment` flag)
 
 **Usage:**
 ```bash
-/code-review
+/code-review [--comment]
 ```
 
+**Options:**
+- `--comment`: Post the review as a comment on the pull request (default: outputs to terminal only)
+
 **Example workflow:**
 ```bash
-# On a PR branch, run:
+# On a PR branch, run locally (outputs to terminal):
 /code-review
 
+# Post review as PR comment:
+/code-review --comment
+
 # Claude will:
 # - Launch 4 review agents in parallel
 # - Score each issue for confidence
-# - Post comment with issues ≥80 confidence
-# - Skip posting if no high-confidence issues found
+# - Output issues ≥80 confidence (to terminal or PR depending on flag)
+# - Skip if no high-confidence issues found
 ```
 
 **Features:**
@@ -114,17 +120,23 @@ This plugin is included in the Claude Code repository. The command is automatica
 ### Standard PR review workflow:
 ```bash
 # Create PR with changes
+# Run local review (outputs to terminal)
 /code-review
 
 # Review the automated feedback
 # Make any necessary fixes
+
+# Optionally post as PR comment
+/code-review --comment
+
 # Merge when ready
 ```
 
 ### As part of CI/CD:
 ```bash
 # Trigger on PR creation or update
-# Automatically posts review comments
+# Use --comment flag to post review comments
+/code-review --comment
 # Skip if review already exists
 ```
 

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

@@ -1,89 +1,106 @@
 ---
-allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*)
+allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*), mcp__github_inline_comment__create_inline_comment
 description: Code review a pull request
-disable-model-invocation: false
 ---
 
 Provide a code review for the given pull request.
 
+**Agent assumptions (applies to all agents and subagents):**
+- All tools are functional and will work without error. Do not test tools or make exploratory calls. Make sure this is clear to every subagent that is launched.
+- Only call a tool if it is required to complete the task. Every tool call should have a clear purpose.
+
 To do this, follow these steps precisely:
 
-1. Use a Haiku agent to check if the pull request (a) is closed, (b) is a draft, (c) does not need a code review (eg. because it is an automated pull request, or is very simple and obviously ok), or (d) already has a code review from you from earlier. If so, do not proceed.
-2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files the pull request modified
-3. Use a Haiku agent to view the pull request, and ask the agent to return a summary of the change
-4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
-   a. Agent #1: Audit the changes to make sure they compily with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
-   b. Agent #2: Read the file changes in the pull request, then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
-   c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
-   d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
-   e. Agent #5: Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
-5. For each issue found in #4, launch a parallel Haiku agent that takes the PR, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
-   a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
-   b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
-   c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
-   d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
-   e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
-6. Filter out any issues with a score less than 80. If there are no issues that meet this criteria, do not proceed.
-7. Use a Haiku agent to repeat the eligibility check from #1, to make sure that the pull request is still eligible for code review.
-8. Finally, use the gh bash command to comment back on the pull request with the result. When writing your comment, keep in mind to:
-   a. Keep your output brief
-   b. Avoid emojis
-   c. Link and cite relevant code, files, and URLs
+1. Launch a haiku agent to check if any of the following are true:
+   - The pull request is closed
+   - The pull request is a draft
+   - The pull request does not need code review (e.g. automated PR, trivial change that is obviously correct)
+   - Claude has already commented on this PR (check `gh pr view <PR> --comments` for comments left by claude)
 
-Examples of false positives, for steps 4 and 5:
+   If any condition is true, stop and do not proceed.
+
+Note: Still review Claude generated PR's.
+
+2. Launch a haiku agent to return a list of file paths (not their contents) for all relevant CLAUDE.md files including:
+   - The root CLAUDE.md file, if it exists
+   - Any CLAUDE.md files in directories containing files modified by the pull request
+
+3. Launch a sonnet agent to view the pull request and return a summary of the changes
+
+4. Launch 4 agents in parallel to independently review the changes. Each agent should return the list of issues, where each issue includes a description and the reason it was flagged (e.g. "CLAUDE.md adherence", "bug"). The agents should do the following:
+
+   Agents 1 + 2: CLAUDE.md compliance sonnet agents
+   Audit changes for CLAUDE.md compliance in parallel. Note: When evaluating CLAUDE.md compliance for a file, you should only consider CLAUDE.md files that share a file path with the file or parents.
+
+   Agent 3: Opus bug agent (parallel subagent with agent 4)
+   Scan for obvious bugs. Focus only on the diff itself without reading extra context. Flag only significant bugs; ignore nitpicks and likely false positives. Do not flag issues that you cannot validate without looking at context outside of the git diff.
+
+   Agent 4: Opus bug agent (parallel subagent with agent 3)
+   Look for problems that exist in the introduced code. This could be security issues, incorrect logic, etc. Only look for issues that fall within the changed code.
+
+   **CRITICAL: We only want HIGH SIGNAL issues.** Flag issues where:
+   - The code will fail to compile or parse (syntax errors, type errors, missing imports, unresolved references)
+   - The code will definitely produce wrong results regardless of inputs (clear logic errors)
+   - Clear, unambiguous CLAUDE.md violations where you can quote the exact rule being broken
+
+   Do NOT flag:
+   - Code style or quality concerns
+   - Potential issues that depend on specific inputs or state
+   - Subjective suggestions or improvements
+
+   If you are not certain an issue is real, do not flag it. False positives erode trust and waste reviewer time.
+
+   In addition to the above, each subagent should be told the PR title and description. This will help provide context regarding the author's intent.
+
+5. For each issue found in the previous step by agents 3 and 4, launch parallel subagents to validate the issue. These subagents should get the PR title and description along with a description of the issue. The agent's job is to review the issue to validate that the stated issue is truly an issue with high confidence. For example, if an issue such as "variable is not defined" was flagged, the subagent's job would be to validate that is actually true in the code. Another example would be CLAUDE.md issues. The agent should validate that the CLAUDE.md rule that was violated is scoped for this file and is actually violated. Use Opus subagents for bugs and logic issues, and sonnet agents for CLAUDE.md violations.
+
+6. Filter out any issues that were not validated in step 5. This step will give us our list of high signal issues for our review.
+
+7. Output a summary of the review findings to the terminal:
+   - If issues were found, list each issue with a brief description.
+   - If no issues were found, state: "No issues found. Checked for bugs and CLAUDE.md compliance."
+
+   If `--comment` argument was NOT provided, stop here. Do not post any GitHub comments.
+
+   If `--comment` argument IS provided and NO issues were found, post a summary comment using `gh pr comment` and stop.
+
+   If `--comment` argument IS provided and issues were found, continue to step 8.
+
+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:
+   - 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
+   - Never post a committable suggestion UNLESS committing the suggestion fixes the issue entirely. If follow up steps are required, do not leave a committable suggestion.
+
+   **IMPORTANT: Only post ONE comment per unique issue. Do not post duplicate comments.**
+
+Use this list when evaluating issues in Steps 4 and 5 (these are false positives, do NOT flag):
 
 - Pre-existing issues
-- Something that looks like a bug but is not actually a bug
-- Pedantic nitpicks that a senior engineer wouldn't call out
-- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
-- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
-- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
-- Changes in functionality that are likely intentional or are directly related to the broader change
-- Real issues, but on lines that the user did not modify in their pull request
+- Something that appears to be a bug but is actually correct
+- Pedantic nitpicks that a senior engineer would not flag
+- Issues that a linter will catch (do not run the linter to verify)
+- General code quality concerns (e.g., lack of test coverage, general security issues) unless explicitly required in CLAUDE.md
+- Issues mentioned in CLAUDE.md but explicitly silenced in the code (e.g., via a lint ignore comment)
 
 Notes:
 
-- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
-- Use `gh` to interact with Github (eg. to fetch a pull request, or to create inline comments), rather than web fetch
-- Make a todo list first
-- You must cite and link each bug (eg. if referring to a CLAUDE.md, you must link it)
-- For your final comment, follow the following format precisely (assuming for this example that you found 3 issues):
+- Use gh CLI to interact with GitHub (e.g., fetch pull requests, create comments). Do not use web fetch.
+- Create a todo list before starting.
+- You must cite and link each issue in inline comments (e.g., if referring to a CLAUDE.md, include a link to it).
+- If no issues are found and `--comment` argument is provided, post a comment with the following format:
 
 ---
 
-### Code review
-
-Found 3 issues:
-
-1. <brief description of bug> (CLAUDE.md says "<...>")
-
-<link to file and line with full sha1 + line range for context, note that you MUST provide the full sha and not use bash here, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
-
-2. <brief description of bug> (some/other/CLAUDE.md says "<...>")
-
-<link to file and line with full sha1 + line range for context>
-
-3. <brief description of bug> (bug due to <file and code snippet>)
-
-<link to file and line with full sha1 + line range for context>
-
-🤖 Generated with [Claude Code](https://claude.ai/code)
-
-<sub>- If this code review was useful, please react with 👍. Otherwise, react with 👎.</sub>
-
----
-
-- Or, if you found no issues:
-
----
-
-### Code review
+## Code review
 
 No issues found. Checked for bugs and CLAUDE.md compliance.
 
-🤖 Generated with [Claude Code](https://claude.ai/code)
+---
 
-- When linking to code, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-cli-internal/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
+- When linking to code in inline comments, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-code/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
   - Requires full git sha
   - You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
   - Repo name must match the repo you're code reviewing

plugins/ralph-wiggum/commands/cancel-ralph.md

@@ -1,26 +1,18 @@
 ---
 description: "Cancel active Ralph Wiggum loop"
-allowed-tools: ["Bash"]
+allowed-tools: ["Bash(test -f .claude/ralph-loop.local.md:*)", "Bash(rm .claude/ralph-loop.local.md)", "Read(.claude/ralph-loop.local.md)"]
 hide-from-slash-command-tool: "true"
 ---
 
 # Cancel Ralph
 
-```!
-if [[ -f .claude/ralph-loop.local.md ]]; then
-  ITERATION=$(grep '^iteration:' .claude/ralph-loop.local.md | sed 's/iteration: *//')
-  echo "FOUND_LOOP=true"
-  echo "ITERATION=$ITERATION"
-else
-  echo "FOUND_LOOP=false"
-fi
-```
+To cancel the Ralph loop:
 
-Check the output above:
+1. Check if `.claude/ralph-loop.local.md` exists using Bash: `test -f .claude/ralph-loop.local.md && echo "EXISTS" || echo "NOT_FOUND"`
 
-1. **If FOUND_LOOP=false**:
-   - Say "No active Ralph loop found."
+2. **If NOT_FOUND**: Say "No active Ralph loop found."
 
-2. **If FOUND_LOOP=true**:
-   - Use Bash: `rm .claude/ralph-loop.local.md`
-   - Report: "Cancelled Ralph loop (was at iteration N)" where N is the ITERATION value from above.
+3. **If EXISTS**:
+   - Read `.claude/ralph-loop.local.md` to get the current iteration number from the `iteration:` field
+   - Remove the file using Bash: `rm .claude/ralph-loop.local.md`
+   - Report: "Cancelled Ralph loop (was at iteration N)" where N is the iteration value

plugins/ralph-wiggum/commands/ralph-loop.md

@@ -1,7 +1,7 @@
 ---
 description: "Start Ralph Wiggum loop in current session"
 argument-hint: "PROMPT [--max-iterations N] [--completion-promise TEXT]"
-allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh)"]
+allowed-tools: ["Bash(${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh:*)"]
 hide-from-slash-command-tool: "true"
 ---
 
@@ -11,36 +11,6 @@ Execute the setup script to initialize the Ralph loop:
 
 ```!
 "${CLAUDE_PLUGIN_ROOT}/scripts/setup-ralph-loop.sh" $ARGUMENTS
-
-# Extract and display completion promise if set
-if [ -f .claude/ralph-loop.local.md ]; then
-  PROMISE=$(grep '^completion_promise:' .claude/ralph-loop.local.md | sed 's/completion_promise: *//' | sed 's/^"\(.*\)"$/\1/')
-  if [ -n "$PROMISE" ] && [ "$PROMISE" != "null" ]; then
-    echo ""
-    echo "═══════════════════════════════════════════════════════════"
-    echo "CRITICAL - Ralph Loop Completion Promise"
-    echo "═══════════════════════════════════════════════════════════"
-    echo ""
-    echo "To complete this loop, output this EXACT text:"
-    echo "  <promise>$PROMISE</promise>"
-    echo ""
-    echo "STRICT REQUIREMENTS (DO NOT VIOLATE):"
-    echo "  ✓ Use <promise> XML tags EXACTLY as shown above"
-    echo "  ✓ The statement MUST be completely and unequivocally TRUE"
-    echo "  ✓ Do NOT output false statements to exit the loop"
-    echo "  ✓ Do NOT lie even if you think you should exit"
-    echo ""
-    echo "IMPORTANT - Do not circumvent the loop:"
-    echo "  Even if you believe you're stuck, the task is impossible,"
-    echo "  or you've been running too long - you MUST NOT output a"
-    echo "  false promise statement. The loop is designed to continue"
-    echo "  until the promise is GENUINELY TRUE. Trust the process."
-    echo ""
-    echo "  If the loop should stop, the promise statement will become"
-    echo "  true naturally. Do not force it by lying."
-    echo "═══════════════════════════════════════════════════════════"
-  fi
-fi
 ```
 
 Please work on the task. When you try to exit, the Ralph loop will feed the SAME PROMPT back to you for the next iteration. You'll see your previous work in files and git history, allowing you to iterate and improve.

plugins/ralph-wiggum/scripts/setup-ralph-loop.sh

@@ -174,3 +174,30 @@ if [[ -n "$PROMPT" ]]; then
   echo ""
   echo "$PROMPT"
 fi
+
+# Display completion promise requirements if set
+if [[ "$COMPLETION_PROMISE" != "null" ]]; then
+  echo ""
+  echo "═══════════════════════════════════════════════════════════"
+  echo "CRITICAL - Ralph Loop Completion Promise"
+  echo "═══════════════════════════════════════════════════════════"
+  echo ""
+  echo "To complete this loop, output this EXACT text:"
+  echo "  <promise>$COMPLETION_PROMISE</promise>"
+  echo ""
+  echo "STRICT REQUIREMENTS (DO NOT VIOLATE):"
+  echo "  ✓ Use <promise> XML tags EXACTLY as shown above"
+  echo "  ✓ The statement MUST be completely and unequivocally TRUE"
+  echo "  ✓ Do NOT output false statements to exit the loop"
+  echo "  ✓ Do NOT lie even if you think you should exit"
+  echo ""
+  echo "IMPORTANT - Do not circumvent the loop:"
+  echo "  Even if you believe you're stuck, the task is impossible,"
+  echo "  or you've been running too long - you MUST NOT output a"
+  echo "  false promise statement. The loop is designed to continue"
+  echo "  until the promise is GENUINELY TRUE. Trust the process."
+  echo ""
+  echo "  If the loop should stop, the promise statement will become"
+  echo "  true naturally. Do not force it by lying."
+  echo "═══════════════════════════════════════════════════════════"
+fi

scripts/comment-on-duplicates.sh

@@ -0,0 +1,95 @@
+#!/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.
+#
+
+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
+
+DUPLICATES=()
+
+# Parse arguments
+while [[ $# -gt 0 ]]; do
+  case $1 in
+    --potential-duplicates)
+      shift
+      while [[ $# -gt 0 && ! "$1" =~ ^-- ]]; do
+        DUPLICATES+=("$1")
+        shift
+      done
+      ;;
+    *)
+      echo "Error: unknown argument (only --potential-duplicates is accepted)" >&2
+      exit 1
+      ;;
+  esac
+done
+
+# Validate duplicates
+if [[ ${#DUPLICATES[@]} -eq 0 ]]; then
+  echo "Error: --potential-duplicates requires at least one issue number" >&2
+  exit 1
+fi
+
+if [[ ${#DUPLICATES[@]} -gt 3 ]]; then
+  echo "Error: --potential-duplicates accepts at most 3 issues" >&2
+  exit 1
+fi
+
+for dup in "${DUPLICATES[@]}"; do
+  if ! [[ "$dup" =~ ^[0-9]+$ ]]; then
+    echo "Error: duplicate issue must be a number, got: $dup" >&2
+    exit 1
+  fi
+done
+
+# Validate that base issue exists
+if ! gh issue view "$BASE_ISSUE" --repo "$REPO" &>/dev/null; then
+  echo "Error: issue #$BASE_ISSUE does not exist in $REPO" >&2
+  exit 1
+fi
+
+# Validate that all duplicate issues exist
+for dup in "${DUPLICATES[@]}"; do
+  if ! gh issue view "$dup" --repo "$REPO" &>/dev/null; then
+    echo "Error: issue #$dup does not exist in $REPO" >&2
+    exit 1
+  fi
+done
+
+# Build comment body
+COUNT=${#DUPLICATES[@]}
+if [[ $COUNT -eq 1 ]]; then
+  HEADER="Found 1 possible duplicate issue:"
+else
+  HEADER="Found $COUNT possible duplicate issues:"
+fi
+
+BODY="$HEADER"$'\n\n'
+INDEX=1
+for dup in "${DUPLICATES[@]}"; do
+  BODY+="$INDEX. https://github.com/$REPO/issues/$dup"$'\n'
+  ((INDEX++))
+done
+
+BODY+=$'\n'"This issue will be automatically closed as a duplicate in 3 days."$'\n\n'
+BODY+="- If your issue is a duplicate, please close it and 👍 the existing issue instead"$'\n'
+BODY+="- To prevent auto-closure, add a comment or 👎 this comment"$'\n\n'
+BODY+="🤖 Generated with [Claude Code](https://claude.ai/code)"
+
+# Post the comment
+gh issue comment "$BASE_ISSUE" --repo "$REPO" --body "$BODY"
+
+echo "Posted duplicate comment on issue #$BASE_ISSUE"

scripts/edit-issue-labels.sh

@@ -0,0 +1,84 @@
+#!/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

@@ -0,0 +1,96 @@
+#!/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

scripts/issue-lifecycle.ts

@@ -0,0 +1,38 @@
+// Single source of truth for issue lifecycle labels, timeouts, and messages.
+
+export const lifecycle = [
+  {
+    label: "invalid",
+    days: 3,
+    reason: "this doesn't appear to be about Claude Code",
+    nudge: "This doesn't appear to be about [Claude Code](https://github.com/anthropics/claude-code). For general Anthropic support, visit [support.anthropic.com](https://support.anthropic.com).",
+  },
+  {
+    label: "needs-repro",
+    days: 7,
+    reason: "we still need reproduction steps to investigate",
+    nudge: "We weren't able to reproduce this. Could you provide steps to trigger the issue — what you ran, what happened, and what you expected?",
+  },
+  {
+    label: "needs-info",
+    days: 7,
+    reason: "we still need a bit more information to move forward",
+    nudge: "We need more information to continue investigating. Can you make sure to include your Claude Code version (`claude --version`), OS, and any error messages or logs?",
+  },
+  {
+    label: "stale",
+    days: 14,
+    reason: "inactive for too long",
+    nudge: "This issue has been automatically marked as stale due to inactivity.",
+  },
+  {
+    label: "autoclose",
+    days: 14,
+    reason: "inactive for too long",
+    nudge: "This issue has been marked for automatic closure.",
+  },
+] as const;
+
+export type LifecycleLabel = (typeof lifecycle)[number]["label"];
+
+export const STALE_UPVOTE_THRESHOLD = 10;

scripts/lifecycle-comment.ts

@@ -0,0 +1,53 @@
+#!/usr/bin/env bun
+
+// Posts a comment when a lifecycle label is applied to an issue,
+// giving the author a heads-up and a chance to respond before auto-close.
+
+import { lifecycle } from "./issue-lifecycle.ts";
+
+const DRY_RUN = process.argv.includes("--dry-run");
+const token = process.env.GITHUB_TOKEN;
+const repo = process.env.GITHUB_REPOSITORY; // owner/repo
+const label = process.env.LABEL;
+const issueNumber = process.env.ISSUE_NUMBER;
+
+if (!DRY_RUN && !token) throw new Error("GITHUB_TOKEN required");
+if (!repo) throw new Error("GITHUB_REPOSITORY required");
+if (!label) throw new Error("LABEL required");
+if (!issueNumber) throw new Error("ISSUE_NUMBER required");
+
+const entry = lifecycle.find((l) => l.label === label);
+if (!entry) {
+  console.log(`No lifecycle entry for label "${label}", skipping`);
+  process.exit(0);
+}
+
+const body = `${entry.nudge} This issue will be closed automatically if there's no activity within ${entry.days} days.`;
+
+// --
+
+if (DRY_RUN) {
+  console.log(`Would comment on #${issueNumber} for label "${label}":\n\n${body}`);
+  process.exit(0);
+}
+
+const response = await fetch(
+  `https://api.github.com/repos/${repo}/issues/${issueNumber}/comments`,
+  {
+    method: "POST",
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "Content-Type": "application/json",
+      "User-Agent": "lifecycle-comment",
+    },
+    body: JSON.stringify({ body }),
+  }
+);
+
+if (!response.ok) {
+  const text = await response.text();
+  throw new Error(`GitHub API ${response.status}: ${text}`);
+}
+
+console.log(`Commented on #${issueNumber} for label "${label}"`);

scripts/sweep.ts

@@ -0,0 +1,168 @@
+#!/usr/bin/env bun
+
+import { lifecycle, STALE_UPVOTE_THRESHOLD } from "./issue-lifecycle.ts";
+
+// --
+
+const NEW_ISSUE = "https://github.com/anthropics/claude-code/issues/new/choose";
+const DRY_RUN = process.argv.includes("--dry-run");
+
+const CLOSE_MESSAGE = (reason: string) =>
+  `Closing for now — ${reason}. Please [open a new issue](${NEW_ISSUE}) if this is still relevant.`;
+
+// --
+
+async function githubRequest<T>(
+  endpoint: string,
+  method = "GET",
+  body?: unknown
+): Promise<T> {
+  const token = process.env.GITHUB_TOKEN;
+  if (!token) throw new Error("GITHUB_TOKEN required");
+
+  const response = await fetch(`https://api.github.com${endpoint}`, {
+    method,
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "User-Agent": "sweep",
+      ...(body && { "Content-Type": "application/json" }),
+    },
+    ...(body && { body: JSON.stringify(body) }),
+  });
+
+  if (!response.ok) {
+    if (response.status === 404) return {} as T;
+    const text = await response.text();
+    throw new Error(`GitHub API ${response.status}: ${text}`);
+  }
+
+  return response.json();
+}
+
+// --
+
+async function markStale(owner: string, repo: string) {
+  const staleDays = lifecycle.find((l) => l.label === "stale")!.days;
+  const cutoff = new Date();
+  cutoff.setDate(cutoff.getDate() - staleDays);
+
+  let labeled = 0;
+
+  console.log(`\n=== marking stale (${staleDays}d inactive) ===`);
+
+  for (let page = 1; page <= 10; page++) {
+    const issues = await githubRequest<any[]>(
+      `/repos/${owner}/${repo}/issues?state=open&sort=updated&direction=asc&per_page=100&page=${page}`
+    );
+    if (issues.length === 0) break;
+
+    for (const issue of issues) {
+      if (issue.pull_request) continue;
+      if (issue.locked) continue;
+      if (issue.assignees?.length > 0) continue;
+
+      const updatedAt = new Date(issue.updated_at);
+      if (updatedAt > cutoff) return labeled;
+
+      const alreadyStale = issue.labels?.some(
+        (l: any) => l.name === "stale" || l.name === "autoclose"
+      );
+      if (alreadyStale) continue;
+
+      const thumbsUp = issue.reactions?.["+1"] ?? 0;
+      if (thumbsUp >= STALE_UPVOTE_THRESHOLD) continue;
+
+      const base = `/repos/${owner}/${repo}/issues/${issue.number}`;
+
+      if (DRY_RUN) {
+        const age = Math.floor((Date.now() - updatedAt.getTime()) / 86400000);
+        console.log(`#${issue.number}: would label stale (${age}d inactive) — ${issue.title}`);
+      } else {
+        await githubRequest(`${base}/labels`, "POST", { labels: ["stale"] });
+        console.log(`#${issue.number}: labeled stale — ${issue.title}`);
+      }
+      labeled++;
+    }
+  }
+
+  return labeled;
+}
+
+async function closeExpired(owner: string, repo: string) {
+  let closed = 0;
+
+  for (const { label, days, reason } of lifecycle) {
+    const cutoff = new Date();
+    cutoff.setDate(cutoff.getDate() - days);
+    console.log(`\n=== ${label} (${days}d timeout) ===`);
+
+    for (let page = 1; page <= 10; page++) {
+      const issues = await githubRequest<any[]>(
+        `/repos/${owner}/${repo}/issues?state=open&labels=${label}&sort=updated&direction=asc&per_page=100&page=${page}`
+      );
+      if (issues.length === 0) break;
+
+      for (const issue of issues) {
+        if (issue.pull_request) continue;
+        if (issue.locked) continue;
+
+        const thumbsUp = issue.reactions?.["+1"] ?? 0;
+        if (thumbsUp >= STALE_UPVOTE_THRESHOLD) continue;
+
+        const base = `/repos/${owner}/${repo}/issues/${issue.number}`;
+
+        const events = await githubRequest<any[]>(`${base}/events?per_page=100`);
+
+        const labeledAt = events
+          .filter((e) => e.event === "labeled" && e.label?.name === label)
+          .map((e) => new Date(e.created_at))
+          .pop();
+
+        if (!labeledAt || labeledAt > cutoff) continue;
+
+        // Skip if a non-bot user commented after the label was applied.
+        // The triage workflow should remove lifecycle labels on human
+        // activity, but check here too as a safety net.
+        const comments = await githubRequest<any[]>(
+          `${base}/comments?since=${labeledAt.toISOString()}&per_page=100`
+        );
+        const hasHumanComment = comments.some(
+          (c) => c.user && c.user.type !== "Bot"
+        );
+        if (hasHumanComment) {
+          console.log(
+            `#${issue.number}: skipping (human activity after ${label} label)`
+          );
+          continue;
+        }
+
+        if (DRY_RUN) {
+          const age = Math.floor((Date.now() - labeledAt.getTime()) / 86400000);
+          console.log(`#${issue.number}: would close (${label}, ${age}d old) — ${issue.title}`);
+        } else {
+          await githubRequest(`${base}/comments`, "POST", { body: CLOSE_MESSAGE(reason) });
+          await githubRequest(base, "PATCH", { state: "closed", state_reason: "not_planned" });
+          console.log(`#${issue.number}: closed (${label})`);
+        }
+        closed++;
+      }
+    }
+  }
+
+  return closed;
+}
+
+// --
+
+const owner = process.env.GITHUB_REPOSITORY_OWNER;
+const repo = process.env.GITHUB_REPOSITORY_NAME;
+if (!owner || !repo)
+  throw new Error("GITHUB_REPOSITORY_OWNER and GITHUB_REPOSITORY_NAME required");
+
+if (DRY_RUN) console.log("DRY RUN — no changes will be made\n");
+
+const labeled = await markStale(owner, repo);
+const closed = await closeExpired(owner, repo);
+
+console.log(`\nDone: ${labeled} ${DRY_RUN ? "would be labeled" : "labeled"} stale, ${closed} ${DRY_RUN ? "would be closed" : "closed"}`);