feat: Add explanatory-output-style and learning-output-style plugins to marketplace

Added two missing plugins to the marketplace.json:
- explanatory-output-style: Adds educational insights about implementation choices
- learning-output-style: Interactive learning mode that requests code contributions

Both plugins are categorized under "learning" to help users discover educational tools.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-Authored-By: Claude <noreply@anthropic.com>

.claude-plugin/marketplace.json

@@ -0,0 +1,95 @@
+{
+  "$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
+  "name": "claude-code-plugins",
+  "version": "1.0.0",
+  "description": "Bundled plugins for Claude Code including Agent SDK development tools, PR review toolkit, and commit workflows",
+  "owner": {
+    "name": "Anthropic",
+    "email": "support@anthropic.com"
+  },
+  "plugins": [
+    {
+      "name": "agent-sdk-dev",
+      "description": "Development kit for working with the Claude Agent SDK",
+      "source": "./plugins/agent-sdk-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": "commit-commands",
+      "description": "Commands for git commit workflows including commit, push, and PR creation",
+      "version": "1.0.0",
+      "author": {
+        "name": "Anthropic",
+        "email": "support@anthropic.com"
+      },
+      "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)",
+      "version": "1.0.0",
+      "author": {
+        "name": "Dickson Tsai",
+        "email": "dickson@anthropic.com"
+      },
+      "source": "./plugins/explanatory-output-style",
+      "category": "learning"
+    },
+    {
+      "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"
+    }
+  ]
+}

.claude/commands/commit-push-pr.md

@@ -0,0 +1,19 @@
+---
+allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr create:*)
+description: Commit, push, and open a PR
+---
+
+## Context
+
+- Current git status: !`git status`
+- Current git diff (staged and unstaged changes): !`git diff HEAD`
+- Current branch: !`git branch --show-current`
+
+## Your task
+
+Based on the above changes:
+1. Create a new branch if on main
+2. Create a single commit with an appropriate message
+3. Push the branch to origin
+4. Create a pull request using `gh pr create`
+5. You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.

.claude/commands/dedupe.md

@@ -0,0 +1,38 @@
+---
+allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh api:*), Bash(gh issue comment:*)
+description: Find duplicate GitHub issues
+---
+
+Find up to 3 likely duplicate issues for a given GitHub issue.
+
+To do this, follow these steps precisely:
+
+1. Use an agent to check if the Github issue (a) is closed, (b) does not need to be deduped (eg. because it is broad product feedback without a specific solution, or positive feedback), or (c) already has a duplicates comment that you made earlier. If so, do not proceed.
+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)
+
+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.)
+- 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

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

.devcontainer/Dockerfile

@@ -3,8 +3,11 @@ FROM node:20
 ARG TZ
 ENV TZ="$TZ"
 
+ARG CLAUDE_CODE_VERSION=latest
+
 # Install basic development tools and iptables/ipset
-RUN apt update && apt install -y less \
+RUN apt-get update && apt-get install -y --no-install-recommends \
+  less \
   git \
   procps \
   sudo \
@@ -19,7 +22,10 @@ RUN apt update && apt install -y less \
   iproute2 \
   dnsutils \
   aggregate \
-  jq
+  jq \
+  nano \
+  vim \
+  && apt-get clean && rm -rf /var/lib/apt/lists/*
 
 # Ensure default node user has access to /usr/local/share
 RUN mkdir -p /usr/local/share/npm-global && \
@@ -42,10 +48,11 @@ RUN mkdir -p /workspace /home/node/.claude && \
 
 WORKDIR /workspace
 
+ARG GIT_DELTA_VERSION=0.18.2
 RUN ARCH=$(dpkg --print-architecture) && \
-  wget "https://github.com/dandavison/delta/releases/download/0.18.2/git-delta_0.18.2_${ARCH}.deb" && \
-  sudo dpkg -i "git-delta_0.18.2_${ARCH}.deb" && \
-  rm "git-delta_0.18.2_${ARCH}.deb"
+  wget "https://github.com/dandavison/delta/releases/download/${GIT_DELTA_VERSION}/git-delta_${GIT_DELTA_VERSION}_${ARCH}.deb" && \
+  sudo dpkg -i "git-delta_${GIT_DELTA_VERSION}_${ARCH}.deb" && \
+  rm "git-delta_${GIT_DELTA_VERSION}_${ARCH}.deb"
 
 # Set up non-root user
 USER node
@@ -54,11 +61,16 @@ USER node
 ENV NPM_CONFIG_PREFIX=/usr/local/share/npm-global
 ENV PATH=$PATH:/usr/local/share/npm-global/bin
 
-# Set the default shell to bash rather than sh
-ENV SHELL /bin/zsh
+# Set the default shell to zsh rather than sh
+ENV SHELL=/bin/zsh
+
+# Set the default editor and visual
+ENV EDITOR=nano
+ENV VISUAL=nano
 
 # Default powerline10k theme
-RUN sh -c "$(wget -O- https://github.com/deluan/zsh-in-docker/releases/download/v1.2.0/zsh-in-docker.sh)" -- \
+ARG ZSH_IN_DOCKER_VERSION=1.2.0
+RUN sh -c "$(wget -O- https://github.com/deluan/zsh-in-docker/releases/download/v${ZSH_IN_DOCKER_VERSION}/zsh-in-docker.sh)" -- \
   -p git \
   -p fzf \
   -a "source /usr/share/doc/fzf/examples/key-bindings.zsh" \
@@ -67,7 +79,8 @@ RUN sh -c "$(wget -O- https://github.com/deluan/zsh-in-docker/releases/download/
   -x
 
 # Install Claude
-RUN npm install -g @anthropic-ai/claude-code
+RUN npm install -g @anthropic-ai/claude-code@${CLAUDE_CODE_VERSION}
+
 
 # Copy and set up firewall script
 COPY init-firewall.sh /usr/local/bin/

.devcontainer/devcontainer.json

@@ -3,7 +3,10 @@
   "build": {
     "dockerfile": "Dockerfile",
     "args": {
-      "TZ": "${localEnv:TZ:America/Los_Angeles}"
+      "TZ": "${localEnv:TZ:America/Los_Angeles}",
+      "CLAUDE_CODE_VERSION": "latest",
+      "GIT_DELTA_VERSION": "0.18.2",
+      "ZSH_IN_DOCKER_VERSION": "1.2.0"
     }
   },
   "runArgs": [
@@ -13,6 +16,7 @@
   "customizations": {
     "vscode": {
       "extensions": [
+        "anthropic.claude-code",
         "dbaeumer.vscode-eslint",
         "esbenp.prettier-vscode",
         "eamodio.gitlens"
@@ -38,15 +42,16 @@
   },
   "remoteUser": "node",
   "mounts": [
-    "source=claude-code-bashhistory,target=/commandhistory,type=volume",
-    "source=claude-code-config,target=/home/node/.claude,type=volume"
+    "source=claude-code-bashhistory-${devcontainerId},target=/commandhistory,type=volume",
+    "source=claude-code-config-${devcontainerId},target=/home/node/.claude,type=volume"
   ],
-  "remoteEnv": {
+  "containerEnv": {
     "NODE_OPTIONS": "--max-old-space-size=4096",
     "CLAUDE_CONFIG_DIR": "/home/node/.claude",
     "POWERLEVEL9K_DISABLE_GITSTATUS": "true"
   },
   "workspaceMount": "source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=delegated",
   "workspaceFolder": "/workspace",
-  "postCreateCommand": "sudo /usr/local/bin/init-firewall.sh"
+  "postStartCommand": "sudo /usr/local/bin/init-firewall.sh",
+  "waitFor": "postStartCommand"
 }

.devcontainer/init-firewall.sh

@@ -2,6 +2,9 @@
 set -euo pipefail  # Exit on error, undefined vars, and pipeline failures
 IFS=$'\n\t'       # Stricter word splitting
 
+# 1. Extract Docker DNS info BEFORE any flushing
+DOCKER_DNS_RULES=$(iptables-save -t nat | grep "127\.0\.0\.11" || true)
+
 # Flush existing rules and delete existing ipsets
 iptables -F
 iptables -X
@@ -11,6 +14,16 @@ iptables -t mangle -F
 iptables -t mangle -X
 ipset destroy allowed-domains 2>/dev/null || true
 
+# 2. Selectively restore ONLY internal Docker DNS resolution
+if [ -n "$DOCKER_DNS_RULES" ]; then
+    echo "Restoring Docker DNS rules..."
+    iptables -t nat -N DOCKER_OUTPUT 2>/dev/null || true
+    iptables -t nat -N DOCKER_POSTROUTING 2>/dev/null || true
+    echo "$DOCKER_DNS_RULES" | xargs -L 1 iptables -t nat
+else
+    echo "No Docker DNS rules to restore"
+fi
+
 # First allow DNS and localhost before any restrictions
 # Allow outbound DNS
 iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
@@ -56,9 +69,12 @@ for domain in \
     "api.anthropic.com" \
     "sentry.io" \
     "statsig.anthropic.com" \
-    "statsig.com"; do
+    "statsig.com" \
+    "marketplace.visualstudio.com" \
+    "vscode.blob.core.windows.net" \
+    "update.code.visualstudio.com"; do
     echo "Resolving $domain..."
-    ips=$(dig +short A "$domain")
+    ips=$(dig +noall +answer A "$domain" | awk '$4 == "A" {print $5}')
     if [ -z "$ips" ]; then
         echo "ERROR: Failed to resolve $domain"
         exit 1
@@ -88,7 +104,6 @@ echo "Host network detected as: $HOST_NETWORK"
 iptables -A INPUT -s "$HOST_NETWORK" -j ACCEPT
 iptables -A OUTPUT -d "$HOST_NETWORK" -j ACCEPT
 
-# Set default policies to DROP first
 # Set default policies to DROP first
 iptables -P INPUT DROP
 iptables -P FORWARD DROP
@@ -101,6 +116,9 @@ iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
 # Then allow only specific outbound traffic to allowed domains
 iptables -A OUTPUT -m set --match-set allowed-domains dst -j ACCEPT
 
+# Explicitly REJECT all other outbound traffic for immediate feedback
+iptables -A OUTPUT -j REJECT --reject-with icmp-admin-prohibited
+
 echo "Firewall configuration complete"
 echo "Verifying firewall rules..."
 if curl --connect-timeout 5 https://example.com >/dev/null 2>&1; then

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,34 +0,0 @@
----
-name: Bug report
-about: Create a report to help us improve
-title: '[BUG] '
-labels: bug
-assignees: ''
----
-
-## Environment
-- Platform (select one):
-  - [ ] Anthropic API
-  - [ ] AWS Bedrock
-  - [ ] Google Vertex AI
-  - [ ] Other: <!-- specify -->
-- Claude CLI version: <!-- output of `claude --version` -->
-- Operating System: <!-- e.g. macOS 14.3, Windows 11, Ubuntu 22.04 -->
-- Terminal:  <!-- e.g. iTerm2, Terminal App -->
-
-## Bug Description
-<!-- A clear and concise description of the bug -->
-
-## Steps to Reproduce
-1. <!-- First step -->
-2. <!-- Second step -->
-3. <!-- And so on... -->
-
-## Expected Behavior
-<!-- What you expected to happen -->
-
-## Actual Behavior
-<!-- What actually happened -->
-
-## Additional Context
-<!-- Add any other context about the problem here, such as screenshots, logs, etc. -->

.github/ISSUE_TEMPLATE/bug_report.yml

@@ -0,0 +1,188 @@
+name: 🐛 Bug Report
+description: Report a bug or unexpected behavior in Claude Code
+title: "[BUG] "
+labels:
+  - bug
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Thanks for taking the time to report this bug! Please fill out the sections below to help us understand and fix the issue.
+        
+        Before submitting, please check:
+        - You're using the [latest version](https://www.npmjs.com/package/@anthropic-ai/claude-code?activeTab=versions) of Claude Code (`claude --version`) 
+        - This issue hasn't already been reported by searching [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug).
+        - This is a bug, not a feature request or support question
+        
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Preflight Checklist
+      description: Please confirm before submitting
+      options:
+        - label: I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
+          required: true
+        - label: This is a single bug report (please file separate reports for different bugs)
+          required: true
+        - label: I am using the latest version of Claude Code
+          required: true
+          
+  - type: textarea
+    id: actual
+    attributes:
+      label: What's Wrong?
+      description: Describe what's happening that shouldn't be
+      placeholder: |
+        When I try to create a Python file, Claude shows an error "EACCES: permission denied" and the file isn't created.
+        
+        The command fails immediately after accepting the file write permission...
+    validations:
+      required: true
+      
+  - type: textarea
+    id: expected
+    attributes:
+      label: What Should Happen?
+      description: Describe the expected behavior
+      placeholder: Claude should create a Python script file successfully without errors
+    validations:
+      required: true
+      
+  - type: textarea
+    id: error_output
+    attributes:
+      label: Error Messages/Logs
+      description: If you see any error messages, paste them here
+      placeholder: |
+        Paste any error output, stack traces, or relevant logs here.
+        This will be automatically formatted as code.
+      render: shell
+    validations:
+      required: false
+      
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Steps to Reproduce
+      description: |
+        Please provide clear, numbered steps that anyone can follow to reproduce the issue.
+        **Important**: Include any necessary code, file contents, or context needed to reproduce the bug.
+        If the issue involves specific files or code, please create a minimal example.
+      placeholder: |
+        1. Create a file `test.py` with this content:
+           ```python
+           def hello():
+               print("test")
+           ```
+        2. Run `claude "add type hints to test.py"`
+        3. When prompted for file access, accept
+        4. Error appears: "Unable to parse..."
+        
+        Note: The bug only happens with Python files containing...
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: model
+    attributes:
+      label: Claude Model
+      description: Which model were you using? (Run `/model` to check)
+      options:
+        - Sonnet (default)
+        - Opus
+        - Not sure / Multiple models
+        - Other
+    validations:
+      required: false
+      
+  - type: dropdown
+    id: regression
+    attributes:
+      label: Is this a regression?
+      description: Did this work in a previous version? 
+      options:
+        - "Yes, this worked in a previous version"
+        - "No, this never worked"
+        - "I don't know"
+    validations:
+      required: true
+      
+  - type: input
+    id: working_version
+    attributes:
+      label: Last Working Version
+      description: If this is a regression, which version last worked? This helps expedite a fix.
+      placeholder: "e.g., 1.0.100"
+    validations:
+      required: false
+      
+  - type: input
+    id: version
+    attributes:
+      label: Claude Code Version
+      description: Run `claude --version` and paste the output
+      placeholder: "e.g., 1.0.123 (Claude Code)"
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: platform
+    attributes:
+      label: Platform
+      description: Which API platform are you using?
+      options:
+        - Anthropic API
+        - AWS Bedrock
+        - Google Vertex AI
+        - Other
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: os
+    attributes:
+      label: Operating System
+      options:
+        - macOS
+        - Windows
+        - Ubuntu/Debian Linux
+        - Other Linux
+        - Other
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: terminal
+    attributes:
+      label: Terminal/Shell
+      description: Which terminal are you using?
+      options:
+        - Terminal.app (macOS)
+        - Warp
+        - Cursor
+        - iTerm2
+        - IntelliJ IDEA terminal
+        - VS Code integrated terminal
+        - PyCharm terminal
+        - Windows Terminal        
+        - PowerShell
+        - WSL (Windows Subsystem for Linux)
+        - Xterm
+        - Non-interactive/CI environment
+        - Other
+    validations:
+      required: true
+      
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Information
+      description: |
+        Anything else that might help us understand the issue?
+        - Screenshots (drag and drop images here)
+        - Configuration files
+        - Related files or code
+        - Links to repositories demonstrating the issue
+      placeholder: Any additional context, screenshots, or information...
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,14 @@
+blank_issues_enabled: false
+contact_links:
+  - name: 💬 Discord Community
+    url: https://anthropic.com/discord
+    about: Get help, ask questions, and chat with other Claude Code users
+  - name: 📖 Documentation
+    url: https://docs.claude.com/en/docs/claude-code
+    about: Read the official documentation and guides
+  - name: 🎓 Getting Started Guide
+    url: https://docs.claude.com/en/docs/claude-code/quickstart
+    about: New to Claude Code? Start here
+  - name: 🔧 Troubleshooting Guide
+    url: https://docs.claude.com/en/docs/claude-code/troubleshooting
+    about: Common issues and how to fix them

.github/ISSUE_TEMPLATE/documentation.yml

@@ -0,0 +1,117 @@
+name: 📚 Documentation Issue
+description: Report missing, unclear, or incorrect documentation
+title: "[DOCS] "
+labels:
+  - documentation
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ## Help us improve our documentation!
+        
+        Good documentation is crucial for a great developer experience. Please let us know what's missing or confusing.
+        
+  - type: dropdown
+    id: doc_type
+    attributes:
+      label: Documentation Type
+      description: What kind of documentation issue is this?
+      options:
+        - Missing documentation (feature not documented)
+        - Unclear/confusing documentation
+        - Incorrect/outdated documentation
+        - Typo or formatting issue
+        - Missing code examples
+        - Broken links
+        - Other
+    validations:
+      required: true
+      
+  - type: input
+    id: location
+    attributes:
+      label: Documentation Location
+      description: Where did you encounter this issue? Provide a URL if possible
+      placeholder: "e.g., https://docs.anthropic.com/en/docs/claude-code/getting-started"
+    validations:
+      required: false
+      
+  - type: input
+    id: section
+    attributes:
+      label: Section/Topic
+      description: Which specific section or topic needs improvement?
+      placeholder: "e.g., MCP Server Configuration section"
+    validations:
+      required: true
+      
+  - type: textarea
+    id: current
+    attributes:
+      label: Current Documentation
+      description: |
+        What does the documentation currently say? 
+        Quote the specific text if applicable.
+      placeholder: |
+        The docs currently say:
+        "To configure MCP servers, add them to your configuration..."
+        
+        But it doesn't explain...
+    validations:
+      required: false
+      
+  - type: textarea
+    id: issue
+    attributes:
+      label: What's Wrong or Missing?
+      description: Explain what's incorrect, unclear, or missing
+      placeholder: |
+        The documentation doesn't explain how to:
+        - Configure multiple MCP servers
+        - Handle authentication
+        - Debug connection issues
+        
+        The example code doesn't work because...
+    validations:
+      required: true
+      
+  - type: textarea
+    id: suggested
+    attributes:
+      label: Suggested Improvement
+      description: How should the documentation be improved? Provide suggested text if possible
+      placeholder: |
+        The documentation should include:
+        
+        1. A complete example showing...
+        2. Explanation of common errors like...
+        3. Step-by-step guide for...
+        
+        Suggested text:
+        "To configure multiple MCP servers, create an array in your settings..."
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: impact
+    attributes:
+      label: Impact
+      description: How much does this documentation issue affect users?
+      options:
+        - High - Prevents users from using a feature
+        - Medium - Makes feature difficult to understand
+        - Low - Minor confusion or inconvenience
+    validations:
+      required: true
+          
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: |
+        - Screenshots showing the issue
+        - Links to related documentation
+        - Examples from other projects that do this well
+      placeholder: Any additional information that would help...
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -0,0 +1,132 @@
+name: ✨ Feature Request
+description: Suggest a new feature or enhancement for Claude Code
+title: "[FEATURE] "
+labels:
+  - enhancement
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ## Thanks for suggesting a feature!
+        
+        We love hearing ideas from our community. Please help us understand your use case by filling out the sections below.
+        Before submitting, please check if this feature has already been requested.
+        
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Preflight Checklist
+      options:
+        - label: I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet
+          required: true
+        - label: This is a single feature request (not multiple features)
+          required: true
+          
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem Statement
+      description: |
+        What problem are you trying to solve? Why do you need this feature?
+        Focus on the problem, not the solution. Help us understand your workflow.
+      placeholder: |
+        I often need to work with multiple projects simultaneously, but Claude Code doesn't support...
+        
+        When I'm debugging code, I find it difficult to...
+        
+        The current workflow requires me to manually...
+    validations:
+      required: true
+      
+  - type: textarea
+    id: solution
+    attributes:
+      label: Proposed Solution
+      description: |
+        How would you like this to work? Describe the ideal user experience.
+        Be specific about how you'd interact with this feature.
+      placeholder: |
+        I'd like to be able to run `claude --workspace project1,project2` to...
+        
+        There should be a command or setting that allows...
+        
+        The interface should show...
+    validations:
+      required: true
+      
+  - type: textarea
+    id: alternatives
+    attributes:
+      label: Alternative Solutions
+      description: |
+        What alternatives have you considered or tried?
+        Are there workarounds you're currently using?
+      placeholder: |
+        I've tried using multiple terminal windows but...
+        
+        Currently I work around this by...
+        
+        Other tools solve this by...
+    validations:
+      required: false
+      
+  - type: dropdown
+    id: priority
+    attributes:
+      label: Priority
+      description: How important is this feature to your workflow?
+      options:
+        - Critical - Blocking my work
+        - High - Significant impact on productivity
+        - Medium - Would be very helpful
+        - Low - Nice to have
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: category
+    attributes:
+      label: Feature Category
+      description: What area does this feature relate to?
+      options:
+        - CLI commands and flags
+        - Interactive mode (TUI)
+        - File operations
+        - API and model interactions
+        - MCP server integration
+        - Performance and speed
+        - Configuration and settings
+        - Developer tools/SDK
+        - Documentation
+        - Other
+    validations:
+      required: true
+      
+  - type: textarea
+    id: use_case
+    attributes:
+      label: Use Case Example
+      description: |
+        Provide a concrete, real-world example of when you'd use this feature.
+        Walk us through a scenario step-by-step.
+      placeholder: |
+        Example scenario:
+        1. I'm working on a React app with a Node.js backend
+        2. I need to make changes to both frontend and backend
+        3. With this feature, I could...
+        4. This would save me time because...
+    validations:
+      required: false
+      
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: |
+        - Screenshots or mockups of the proposed feature
+        - Links to similar features in other tools
+        - Technical considerations or constraints
+        - Any other relevant information
+      placeholder: Add any other context, mockups, or examples here...
+    validations:
+      required: false

.github/ISSUE_TEMPLATE/model_behavior.yml

@@ -0,0 +1,220 @@
+name: 🤖 Model Behavior Issue
+description: Report unexpected Claude model behavior, incorrect actions, or permission violations
+title: "[MODEL] "
+labels:
+  - model
+body:
+  - type: markdown
+    attributes:
+      value: |
+        ## Report Unexpected Model Behavior
+        
+        Use this template when Claude does something unexpected, makes unwanted changes, or behaves inconsistently with your instructions.
+        
+        **This is for:** Unexpected actions, file modifications outside scope, ignoring instructions, making assumptions
+        **NOT for:** Crashes, API errors, or installation issues (use Bug Report instead)
+        
+  - type: checkboxes
+    id: preflight
+    attributes:
+      label: Preflight Checklist
+      description: Please confirm before submitting
+      options:
+        - label: I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Amodel) for similar behavior reports
+          required: true
+        - label: This report does NOT contain sensitive information (API keys, passwords, etc.)
+          required: true
+          
+  - type: dropdown
+    id: behavior_type
+    attributes:
+      label: Type of Behavior Issue
+      description: What category best describes the unexpected behavior?
+      options:
+        - Claude modified files I didn't ask it to modify
+        - Claude accessed files outside the working directory
+        - Claude ignored my instructions or configuration
+        - Claude reverted/undid previous changes without asking
+        - Claude made incorrect assumptions about my project
+        - Claude refused a reasonable request
+        - Claude's behavior changed between sessions
+        - Subagent behaved unexpectedly
+        - Other unexpected behavior
+    validations:
+      required: true
+      
+  - type: textarea
+    id: what_you_asked
+    attributes:
+      label: What You Asked Claude to Do
+      description: Provide the exact prompt or command you gave
+      placeholder: |
+        I asked: "Update the README.md file to add installation instructions"
+        
+        Or I ran: `claude "fix the bug in auth.js"`
+    validations:
+      required: true
+      
+  - type: textarea
+    id: what_claude_did
+    attributes:
+      label: What Claude Actually Did
+      description: Describe step-by-step what Claude did instead
+      placeholder: |
+        1. Claude read README.md
+        2. Instead of updating it, Claude deleted the entire file
+        3. Created a new README from scratch with different content
+        4. Also modified package.json without being asked
+        5. Changed .gitignore file
+    validations:
+      required: true
+      
+  - type: textarea
+    id: expected_behavior
+    attributes:
+      label: Expected Behavior
+      description: What should Claude have done?
+      placeholder: |
+        Claude should have:
+        1. Read the existing README.md
+        2. Added an "Installation" section
+        3. Only modified that single file
+        4. Not touched any other files
+    validations:
+      required: true
+      
+  - type: textarea
+    id: files_affected
+    attributes:
+      label: Files Affected
+      description: |
+        List all files that were accessed or modified (even if you didn't expect them to be)
+      placeholder: |
+        Modified:
+        - README.md (deleted and recreated)
+        - package.json (version bumped - not requested)
+        - .gitignore (added entries - not requested)
+        
+        Read (unexpectedly):
+        - /Users/me/.ssh/config
+        - ../../../parent-directory/secrets.env
+      render: shell
+    validations:
+      required: false
+      
+  - type: dropdown
+    id: permission_mode
+    attributes:
+      label: Permission Mode
+      description: What permission settings were active?
+      options:
+        - Accept Edits was ON (auto-accepting changes)
+        - Accept Edits was OFF (manual approval required)
+        - I don't know / Not sure
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: reproducible
+    attributes:
+      label: Can You Reproduce This?
+      description: Does this happen consistently?
+      options:
+        - Yes, every time with the same prompt
+        - Sometimes (intermittent)
+        - No, only happened once
+        - Haven't tried to reproduce
+    validations:
+      required: true
+      
+  - type: textarea
+    id: reproduction_steps
+    attributes:
+      label: Steps to Reproduce
+      description: If reproducible, provide minimal steps
+      placeholder: |
+        1. Create a new directory with a simple README.md
+        2. Ask Claude Code to "improve the README"
+        3. Claude will delete and recreate the file instead of editing
+    validations:
+      required: false
+      
+  - type: dropdown
+    id: model
+    attributes:
+      label: Claude Model
+      description: Which model were you using? (Run `/model` to check)
+      options:
+        - Sonnet
+        - Opus
+        - Haiku
+        - Not sure
+        - Other
+    validations:
+      required: true
+      
+  - type: textarea
+    id: conversation_log
+    attributes:
+      label: Relevant Conversation
+      description: |
+        Include relevant parts of Claude's responses, especially where it explains what it's doing
+      placeholder: |
+        Claude said: "I'll help you update the README. Let me first delete the old one and create a fresh version..."
+        
+        [Then proceeded to delete without asking for confirmation]
+      render: markdown
+    validations:
+      required: false
+      
+  - type: dropdown
+    id: impact
+    attributes:
+      label: Impact
+      description: How severe was the impact of this behavior?
+      options:
+        - Critical - Data loss or corrupted project
+        - High - Significant unwanted changes
+        - Medium - Extra work to undo changes
+        - Low - Minor inconvenience
+    validations:
+      required: true
+      
+  - type: input
+    id: version
+    attributes:
+      label: Claude Code Version
+      description: Run `claude --version` and paste the output
+      placeholder: "e.g., 1.0.123 (Claude Code)"
+    validations:
+      required: true
+      
+  - type: dropdown
+    id: platform
+    attributes:
+      label: Platform
+      description: Which API platform are you using?
+      options:
+        - Anthropic API
+        - AWS Bedrock
+        - Google Vertex AI
+        - Other
+    validations:
+      required: true
+      
+  - type: textarea
+    id: additional
+    attributes:
+      label: Additional Context
+      description: |
+        - Any patterns you've noticed
+        - Similar behavior in other sessions
+        - Specific file types or project structures that trigger this
+        - Screenshots if relevant
+      placeholder: |
+        This seems to happen more often with:
+        - Python projects
+        - When there are multiple similar files
+        - After long conversations
+    validations:
+      required: false

.github/workflows/auto-close-duplicates.yml

@@ -0,0 +1,31 @@
+name: Auto-close duplicate issues
+description: Auto-closes issues that are duplicates of existing issues
+on:
+  schedule:
+    - cron: "0 9 * * *"
+  workflow_dispatch:
+
+jobs:
+  auto-close-duplicates:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      contents: read
+      issues: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+
+      - name: Auto-close duplicate issues
+        run: bun run scripts/auto-close-duplicates.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          GITHUB_REPOSITORY_OWNER: ${{ github.repository_owner }}
+          GITHUB_REPOSITORY_NAME: ${{ github.event.repository.name }}
+          STATSIG_API_KEY: ${{ secrets.STATSIG_API_KEY }}

.github/workflows/backfill-duplicate-comments.yml

@@ -0,0 +1,44 @@
+name: Backfill Duplicate Comments
+description: Triggers duplicate detection for old issues that don't have duplicate comments
+
+on:
+  workflow_dispatch:
+    inputs:
+      days_back:
+        description: 'How many days back to look for old issues'
+        required: false
+        default: '90'
+        type: string
+      dry_run:
+        description: 'Dry run mode (true to only log what would be done)'
+        required: false
+        default: 'true'
+        type: choice
+        options:
+          - 'true'
+          - 'false'
+
+jobs:
+  backfill-duplicate-comments:
+    runs-on: ubuntu-latest
+    timeout-minutes: 30
+    permissions:
+      contents: read
+      issues: read
+      actions: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+      
+      - name: Setup Bun
+        uses: oven-sh/setup-bun@v2
+        with:
+          bun-version: latest
+      
+      - name: Backfill duplicate comments
+        run: bun run scripts/backfill-duplicate-comments.ts
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+          DAYS_BACK: ${{ inputs.days_back }}
+          DRY_RUN: ${{ inputs.dry_run }}

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

@@ -0,0 +1,81 @@
+name: Claude Issue Dedupe
+description: Automatically dedupe GitHub issues using Claude Code
+on:
+  issues:
+    types: [opened]
+  workflow_dispatch:
+    inputs:
+      issue_number:
+        description: 'Issue number to process for duplicate detection'
+        required: true
+        type: string
+
+jobs:
+  claude-dedupe-issues:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      contents: read
+      issues: write
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Run Claude Code slash command
+        uses: anthropics/claude-code-base-action@beta
+        with:
+          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()
+        env:
+          STATSIG_API_KEY: ${{ secrets.STATSIG_API_KEY }}
+        run: |
+          ISSUE_NUMBER=${{ github.event.issue.number || inputs.issue_number }}
+          REPO=${{ github.repository }}
+          
+          if [ -z "$STATSIG_API_KEY" ]; then
+            echo "STATSIG_API_KEY not found, skipping Statsig logging"
+            exit 0
+          fi
+          
+          # Prepare the event payload
+          EVENT_PAYLOAD=$(jq -n \
+            --arg issue_number "$ISSUE_NUMBER" \
+            --arg repo "$REPO" \
+            --arg triggered_by "${{ github.event_name }}" \
+            '{
+              events: [{
+                eventName: "github_duplicate_comment_added",
+                value: 1,
+                metadata: {
+                  repository: $repo,
+                  issue_number: ($issue_number | tonumber),
+                  triggered_by: $triggered_by,
+                  workflow_run_id: "${{ github.run_id }}"
+                },
+                time: (now | floor | tostring)
+              }]
+            }')
+          
+          # Send to Statsig API
+          echo "Logging duplicate comment event to Statsig for issue #${ISSUE_NUMBER}"
+          
+          RESPONSE=$(curl -s -w "\n%{http_code}" -X POST https://events.statsigapi.net/v1/log_event \
+            -H "Content-Type: application/json" \
+            -H "STATSIG-API-KEY: ${STATSIG_API_KEY}" \
+            -d "$EVENT_PAYLOAD")
+          
+          HTTP_CODE=$(echo "$RESPONSE" | tail -n1)
+          BODY=$(echo "$RESPONSE" | head -n-1)
+          
+          if [ "$HTTP_CODE" -eq 200 ] || [ "$HTTP_CODE" -eq 202 ]; then
+            echo "Successfully logged duplicate comment event for issue #${ISSUE_NUMBER}"
+          else
+            echo "Failed to log duplicate comment event for issue #${ISSUE_NUMBER}. HTTP ${HTTP_CODE}: ${BODY}"
+          fi

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

@@ -0,0 +1,107 @@
+name: Claude Issue Triage
+description: Automatically triage GitHub issues using Claude Code
+on:
+  issues:
+    types: [opened]
+
+jobs:
+  triage-issue:
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    permissions:
+      contents: read
+      issues: write
+
+    steps:
+      - 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
+        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"
+          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 }}

.github/workflows/claude.yml

@@ -0,0 +1,38 @@
+name: Claude Code
+
+on:
+  issue_comment:
+    types: [created]
+  pull_request_review_comment:
+    types: [created]
+  issues:
+    types: [opened, assigned]
+  pull_request_review:
+    types: [submitted]
+
+jobs:
+  claude:
+    if: |
+      (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@claude')) ||
+      (github.event_name == 'pull_request_review_comment' && contains(github.event.comment.body, '@claude')) ||
+      (github.event_name == 'pull_request_review' && contains(github.event.review.body, '@claude')) ||
+      (github.event_name == 'issues' && (contains(github.event.issue.body, '@claude') || contains(github.event.issue.title, '@claude')))
+    runs-on: ubuntu-latest
+    permissions:
+      contents: read
+      pull-requests: read
+      issues: read
+      id-token: write
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683  # v4
+        with:
+          fetch-depth: 1
+
+      - name: Run Claude Code
+        id: claude
+        uses: anthropics/claude-code-action@beta
+        with:
+          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
+          claude_args: "--model claude-sonnet-4-5-20250929"
+

.github/workflows/issue-opened-dispatch.yml

@@ -0,0 +1,28 @@
+name: Issue Opened Dispatch
+
+on:
+  issues:
+    types: [opened]
+
+permissions:
+  issues: read
+  actions: write
+
+jobs:
+  notify:
+    runs-on: ubuntu-latest
+    timeout-minutes: 1
+    steps:
+      - name: Process new issue
+        env:
+          ISSUE_URL: ${{ github.event.issue.html_url }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+          ISSUE_TITLE: ${{ github.event.issue.title }}
+          TARGET_REPO: ${{ secrets.ISSUE_OPENED_DISPATCH_TARGET_REPO }}
+          GH_TOKEN: ${{ secrets.ISSUE_OPENED_DISPATCH_TOKEN }}
+        run: |
+          gh api repos/${TARGET_REPO}/dispatches \
+            -f event_type=issue_opened \
+            -f client_payload[issue_url]="${ISSUE_URL}" || {
+              exit 0
+            }

.github/workflows/lock-closed-issues.yml

@@ -0,0 +1,92 @@
+name: "Lock Stale Issues"
+
+on:
+  schedule:
+    # 8am Pacific = 1pm UTC (2pm UTC during DST)
+    - cron: "0 14 * * *"
+  workflow_dispatch:
+
+permissions:
+  issues: write
+
+concurrency:
+  group: lock-threads
+
+jobs:
+  lock-closed-issues:
+    runs-on: ubuntu-latest
+    steps:
+      - name: Lock closed issues after 7 days of inactivity
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const sevenDaysAgo = new Date();
+            sevenDaysAgo.setDate(sevenDaysAgo.getDate() - 7);
+
+            const lockComment = `This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.`;
+
+            let page = 1;
+            let hasMore = true;
+            let totalLocked = 0;
+
+            while (hasMore) {
+              // Get closed issues (pagination)
+              const { data: issues } = await github.rest.issues.listForRepo({
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                state: 'closed',
+                sort: 'updated',
+                direction: 'asc',
+                per_page: 100,
+                page: page
+              });
+              
+              if (issues.length === 0) {
+                hasMore = false;
+                break;
+              }
+              
+              for (const issue of issues) {
+                // Skip if already locked
+                if (issue.locked) continue;
+                
+                // Skip pull requests
+                if (issue.pull_request) continue;
+                
+                // Check if updated more than 7 days ago
+                const updatedAt = new Date(issue.updated_at);
+                if (updatedAt > sevenDaysAgo) {
+                  // Since issues are sorted by updated_at ascending, 
+                  // once we hit a recent issue, all remaining will be recent too
+                  hasMore = false;
+                  break;
+                }
+                
+                try {
+                  // Add comment before locking
+                  await github.rest.issues.createComment({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: issue.number,
+                    body: lockComment
+                  });
+                  
+                  // Lock the issue
+                  await github.rest.issues.lock({
+                    owner: context.repo.owner,
+                    repo: context.repo.repo,
+                    issue_number: issue.number,
+                    lock_reason: 'resolved'
+                  });
+                  
+                  totalLocked++;
+                  console.log(`Locked issue #${issue.number}: ${issue.title}`);
+                } catch (error) {
+                  console.error(`Failed to lock issue #${issue.number}: ${error.message}`);
+                }
+              }
+              
+              page++;
+            }
+
+            console.log(`Total issues locked: ${totalLocked}`);

.github/workflows/log-issue-events.yml

@@ -0,0 +1,40 @@
+name: Log Issue Events to Statsig
+
+on:
+  issues:
+    types: [opened, closed]
+
+jobs:
+  log-to-statsig:
+    runs-on: ubuntu-latest
+    permissions:
+      issues: read
+    steps:
+      - name: Log issue creation to Statsig
+        env:
+          STATSIG_API_KEY: ${{ secrets.STATSIG_API_KEY }}
+          ISSUE_NUMBER: ${{ github.event.issue.number }}
+          REPO: ${{ github.repository }}
+          ISSUE_TITLE: ${{ github.event.issue.title }}
+          AUTHOR: ${{ github.event.issue.user.login }}
+          CREATED_AT: ${{ github.event.issue.created_at }}
+        run: |
+          # All values are now safely passed via environment variables
+          # No direct templating in the shell script to prevent injection attacks
+          
+          curl -X POST "https://events.statsigapi.net/v1/log_event" \
+            -H "Content-Type: application/json" \
+            -H "statsig-api-key: $STATSIG_API_KEY" \
+            -d '{
+              "events": [{
+                "eventName": "github_issue_created",
+                "metadata": {
+                  "issue_number": "'"$ISSUE_NUMBER"'",
+                  "repository": "'"$REPO"'",
+                  "title": "'"$(echo "$ISSUE_TITLE" | sed "s/\"/\\\\\"/g")"'",
+                  "author": "'"$AUTHOR"'",
+                  "created_at": "'"$CREATED_AT"'"
+                },
+                "time": '"$(date +%s)000"'
+              }]
+            }'

.github/workflows/oncall-triage.yml

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

.gitignore

@@ -0,0 +1,2 @@
+.DS_Store
+

CHANGELOG.md

@@ -0,0 +1,884 @@
+# Changelog
+
+## 2.0.31
+
+- Windows: native installation uses shift+tab as shortcut for mode switching, instead of alt+m
+- Vertex: add support for Web Search on supported models
+- VSCode: Adding the respectGitIgnore configuration to include .gitignored files in file searches (defaults to true)
+- Fixed a bug with subagents and MCP servers related to "Tool names must be unique" error
+- Fixed issue causing `/compact` to fail with `prompt_too_long` by making it respect existing compact boundaries
+- Fixed plugin uninstall not removing plugins
+
+## 2.0.30
+
+- Added helpful hint to run `security unlock-keychain` when encountering API key errors on macOS with locked keychain
+- Added `allowUnsandboxedCommands` sandbox setting to disable the dangerouslyDisableSandbox escape hatch at policy level
+- Added `disallowedTools` field to custom agent definitions for explicit tool blocking
+- Added prompt-based stop hooks
+- VSCode: Added respectGitIgnore configuration to include .gitignored files in file searches (defaults to true)
+- Enabled SSE MCP servers on native build
+- Deprecated output styles. Review options in `/output-style` and use --system-prompt-file, --system-prompt, --append-system-prompt, CLAUDE.md, or plugins instead
+- Removed support for custom ripgrep configuration, resolving an issue where Search returns no results and config discovery fails
+- Fixed Explore agent creating unwanted .md investigation files during codebase exploration
+- Fixed a bug where `/context` would sometimes fail with "max_tokens must be greater than thinking.budget_tokens" error message
+- Fixed `--mcp-config` flag to correctly override file-based MCP configurations
+- Fixed bug that saved session permissions to local settings
+- Fixed MCP tools not being available to sub-agents
+- Fixed hooks and plugins not executing when using --dangerously-skip-permissions flag
+- Fixed delay when navigating through typeahead suggestions with arrow keys
+- VSCode: Restored selection indicator in input footer showing current file or code selection status
+
+## 2.0.28
+
+- Plan mode: introduced new Plan subagent
+- Subagents: claude can now choose to resume subagents
+- Subagents: claude can dynamically choose the model used by its subagents
+- SDK: added --max-budget-usd flag
+- Discovery of custom slash commands, subagents, and output styles no longer respects .gitignore
+- Stop `/terminal-setup` from adding backslash to `Shift + Enter` in VS Code
+- Add branch and tag support for git-based plugins and marketplaces using fragment syntax (e.g., `owner/repo#branch`)
+- Fixed a bug where macOS permission prompts would show up upon initial launch when launching from home directory
+- Various other bug fixes
+
+## 2.0.27
+
+- New UI for permission prompts
+- Added current branch filtering and search to session resume screen for easier navigation
+- Fixed directory @-mention causing "No assistant message found" error
+- VSCode Extension: Add config setting to include .gitignored files in file searches
+- VSCode Extension: Bug fixes for unrelated 'Warmup' conversations, and configuration/settings occasionally being reset to defaults
+
+## 2.0.25
+
+- Removed legacy SDK entrypoint. Please migrate to @anthropic-ai/claude-agent-sdk for future SDK updates: https://docs.claude.com/en/docs/claude-code/sdk/migration-guide
+
+## 2.0.24
+
+- Fixed a bug where project-level skills were not loading when --setting-sources 'project' was specified
+- Claude Code Web: Support for Web -> CLI teleport
+- Sandbox: Releasing a sandbox mode for the BashTool on Linux & Mac
+- Bedrock: Display awsAuthRefresh output when auth is required
+
+## 2.0.22
+
+- Fixed content layout shift when scrolling through slash commands
+- IDE: Add toggle to enable/disable thinking.
+- Fix bug causing duplicate permission prompts with parallel tool calls
+- Add support for enterprise managed MCP allowlist and denylist
+
+## 2.0.21
+
+- Support MCP `structuredContent` field in tool responses
+- Added an interactive question tool
+- Claude will now ask you questions more often in plan mode
+- Added Haiku 4.5 as a model option for Pro users
+- Fixed an issue where queued commands don't have access to previous messages' output
+
+## 2.0.20
+
+- Added support for Claude Skills
+
+## 2.0.19
+
+- Auto-background long-running bash commands instead of killing them. Customize with BASH_DEFAULT_TIMEOUT_MS
+- Fixed a bug where Haiku was unnecessarily called in print mode
+
+## 2.0.17
+
+- Added Haiku 4.5 to model selector!
+- Haiku 4.5 automatically uses Sonnet in plan mode, and Haiku for execution (i.e. SonnetPlan by default)
+- 3P (Bedrock and Vertex) are not automatically upgraded yet. Manual upgrading can be done through setting `ANTHROPIC_DEFAULT_HAIKU_MODEL`
+- Introducing the Explore subagent. Powered by Haiku it'll search through your codebase efficiently to save context!
+- OTEL: support HTTP_PROXY and HTTPS_PROXY
+- `CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC` now disables release notes fetching
+
+## 2.0.15
+
+- Fixed bug with resuming where previously created files needed to be read again before writing
+- Fixed bug with `-p` mode where @-mentioned files needed to be read again before writing
+
+## 2.0.14
+
+- Fix @-mentioning MCP servers to toggle them on/off
+- Improve permission checks for bash with inline env vars
+- Fix ultrathink + thinking toggle
+- Reduce unnecessary logins
+- Document --system-prompt
+- Several improvements to rendering
+- Plugins UI polish
+
+## 2.0.13
+
+- Fixed `/plugin` not working on native build
+
+## 2.0.12
+
+- **Plugin System Released**: Extend Claude Code with custom commands, agents, hooks, and MCP servers from marketplaces
+- `/plugin install`, `/plugin enable/disable`, `/plugin marketplace` commands for plugin management
+- Repository-level plugin configuration via `extraKnownMarketplaces` for team collaboration
+- `/plugin validate` command for validating plugin structure and configuration
+- Plugin announcement blog post at https://www.anthropic.com/news/claude-code-plugins
+- Plugin documentation available at https://docs.claude.com/en/docs/claude-code/plugins
+- Comprehensive error messages and diagnostics via `/doctor` command
+- Avoid flickering in `/model` selector
+- Improvements to `/help`
+- Avoid mentioning hooks in `/resume` summaries
+- Changes to the "verbose" setting in `/config` now persist across sessions
+
+## 2.0.11
+
+- Reduced system prompt size by 1.4k tokens
+- IDE: Fixed keyboard shortcuts and focus issues for smoother interaction
+- Fixed Opus fallback rate limit errors appearing incorrectly
+- Fixed /add-dir command selecting wrong default tab
+
+## 2.0.10
+
+- Rewrote terminal renderer for buttery smooth UI
+- Enable/disable MCP servers by @mentioning, or in /mcp
+- Added tab completion for shell commands in bash mode
+- PreToolUse hooks can now modify tool inputs
+- Press Ctrl-G to edit your prompt in your system's configured text editor
+- Fixes for bash permission checks with environment variables in the command
+
+## 2.0.9
+
+- Fix regression where bash backgrounding stopped working
+
+## 2.0.8
+
+- Update Bedrock default Sonnet model to `global.anthropic.claude-sonnet-4-5-20250929-v1:0`
+- IDE: Add drag-and-drop support for files and folders in chat
+- /context: Fix counting for thinking blocks
+- Improve message rendering for users with light themes on dark terminals
+- Remove deprecated .claude.json allowedTools, ignorePatterns, env, and todoFeatureEnabled config options (instead, configure these in your settings.json)
+
+## 2.0.5
+
+- IDE: Fix IME unintended message submission with Enter and Tab
+- IDE: Add "Open in Terminal" link in login screen
+- Fix unhandled OAuth expiration 401 API errors
+- SDK: Added SDKUserMessageReplay.isReplay to prevent duplicate messages
+
+## 2.0.1
+
+- Skip Sonnet 4.5 default model setting change for Bedrock and Vertex
+- Various bug fixes and presentation improvements
+
+## 2.0.0
+
+- New native VS Code extension
+- Fresh coat of paint throughout the whole app
+- /rewind a conversation to undo code changes
+- /usage command to see plan limits
+- Tab to toggle thinking (sticky across sessions)
+- Ctrl-R to search history
+- Unshipped claude config command
+- Hooks: Reduced PostToolUse 'tool_use' ids were found without 'tool_result' blocks errors
+- SDK: The Claude Code SDK is now the Claude Agent SDK
+- Add subagents dynamically with `--agents` flag
+
+## 1.0.126
+
+- Enable /context command for Bedrock and Vertex
+- Add mTLS support for HTTP-based OpenTelemetry exporters
+
+## 1.0.124
+
+- Set `CLAUDE_BASH_NO_LOGIN` environment variable to 1 or true to to skip login shell for BashTool
+- Fix Bedrock and Vertex environment variables evaluating all strings as truthy
+- No longer inform Claude of the list of allowed tools when permission is denied
+- Fixed security vulnerability in Bash tool permission checks
+- Improved VSCode extension performance for large files
+
+## 1.0.123
+
+- Bash permission rules now support output redirections when matching (e.g., `Bash(python:*)` matches `python script.py > output.txt`)
+- Fixed thinking mode triggering on negation phrases like "don't think"
+- Fixed rendering performance degradation during token streaming
+- Added SlashCommand tool, which enables Claude to invoke your slash commands. https://docs.claude.com/en/docs/claude-code/slash-commands#SlashCommand-tool
+- Enhanced BashTool environment snapshot logging
+- Fixed a bug where resuming a conversation in headless mode would sometimes enable thinking unnecessarily
+- Migrated --debug logging to a file, to enable easy tailing & filtering
+
+## 1.0.120
+
+- Fix input lag during typing, especially noticeable with large prompts
+- Improved VSCode extension command registry and sessions dialog user experience
+- Enhanced sessions dialog responsiveness and visual feedback
+- Fixed IDE compatibility issue by removing worktree support check
+- Fixed security vulnerability where Bash tool permission checks could be bypassed using prefix matching
+
+## 1.0.119
+
+- Fix Windows issue where process visually freezes on entering interactive mode
+- Support dynamic headers for MCP servers via headersHelper configuration
+- Fix thinking mode not working in headless sessions
+- Fix slash commands now properly update allowed tools instead of replacing them
+
+## 1.0.117
+
+- Add Ctrl-R history search to recall previous commands like bash/zsh
+- Fix input lag while typing, especially on Windows
+- Add sed command to auto-allowed commands in acceptEdits mode
+- Fix Windows PATH comparison to be case-insensitive for drive letters
+- Add permissions management hint to /add-dir output
+
+## 1.0.115
+
+- Improve thinking mode display with enhanced visual effects
+- Type /t to temporarily disable thinking mode in your prompt
+- Improve path validation for glob and grep tools
+- Show condensed output for post-tool hooks to reduce visual clutter
+- Fix visual feedback when loading state completes
+- Improve UI consistency for permission request dialogs
+
+## 1.0.113
+
+- Deprecated piped input in interactive mode
+- Move Ctrl+R keybinding for toggling transcript to Ctrl+O
+
+## 1.0.112
+
+- Transcript mode (Ctrl+R): Added the model used to generate each assistant message
+- Addressed issue where some Claude Max users were incorrectly recognized as Claude Pro users
+- Hooks: Added systemMessage support for SessionEnd hooks
+- Added `spinnerTipsEnabled` setting to disable spinner tips
+- IDE: Various improvements and bug fixes
+
+## 1.0.111
+
+- /model now validates provided model names
+- Fixed Bash tool crashes caused by malformed shell syntax parsing
+
+## 1.0.110
+
+- /terminal-setup command now supports WezTerm
+- MCP: OAuth tokens now proactively refresh before expiration
+- Fixed reliability issues with background Bash processes
+
+## 1.0.109
+
+- SDK: Added partial message streaming support via `--include-partial-messages` CLI flag
+
+## 1.0.106
+
+- Windows: Fixed path permission matching to consistently use POSIX format (e.g., `Read(//c/Users/...)`)
+
+## 1.0.97
+
+- Settings: /doctor now validates permission rule syntax and suggests corrections
+
+## 1.0.94
+
+- Vertex: add support for global endpoints for supported models
+- /memory command now allows direct editing of all imported memory files
+- SDK: Add custom tools as callbacks
+- Added /todos command to list current todo items
+
+## 1.0.93
+
+- Windows: Add alt + v shortcut for pasting images from clipboard
+- Support NO_PROXY environment variable to bypass proxy for specified hostnames and IPs
+
+## 1.0.90
+
+- Settings file changes take effect immediately - no restart required
+
+## 1.0.88
+
+- Fixed issue causing "OAuth authentication is currently not supported"
+- Status line input now includes `exceeds_200k_tokens`
+- Fixed incorrect usage tracking in /cost.
+- Introduced `ANTHROPIC_DEFAULT_SONNET_MODEL` and `ANTHROPIC_DEFAULT_OPUS_MODEL` for controlling model aliases opusplan, opus, and sonnet.
+- Bedrock: Updated default Sonnet model to Sonnet 4
+
+## 1.0.86
+
+- Added /context to help users self-serve debug context issues
+- SDK: Added UUID support for all SDK messages
+- SDK: Added `--replay-user-messages` to replay user messages back to stdout
+
+## 1.0.85
+
+- Status line input now includes session cost info
+- Hooks: Introduced SessionEnd hook
+
+## 1.0.84
+
+- Fix tool_use/tool_result id mismatch error when network is unstable
+- Fix Claude sometimes ignoring real-time steering when wrapping up a task
+- @-mention: Add ~/.claude/\* files to suggestions for easier agent, output style, and slash command editing
+- Use built-in ripgrep by default; to opt out of this behavior, set USE_BUILTIN_RIPGREP=0
+
+## 1.0.83
+
+- @-mention: Support files with spaces in path
+- New shimmering spinner
+
+## 1.0.82
+
+- SDK: Add request cancellation support
+- SDK: New additionalDirectories option to search custom paths, improved slash command processing
+- Settings: Validation prevents invalid fields in .claude/settings.json files
+- MCP: Improve tool name consistency
+- Bash: Fix crash when Claude tries to automatically read large files
+
+## 1.0.81
+
+- Released output styles, including new built-in educational output styles "Explanatory" and "Learning". Docs: https://docs.claude.com/en/docs/claude-code/output-styles
+- Agents: Fix custom agent loading when agent files are unparsable
+
+## 1.0.80
+
+- UI improvements: Fix text contrast for custom subagent colors and spinner rendering issues
+
+## 1.0.77
+
+- Bash tool: Fix heredoc and multiline string escaping, improve stderr redirection handling
+- SDK: Add session support and permission denial tracking
+- Fix token limit errors in conversation summarization
+- Opus Plan Mode: New setting in `/model` to run Opus only in plan mode, Sonnet otherwise
+
+## 1.0.73
+
+- MCP: Support multiple config files with `--mcp-config file1.json file2.json`
+- MCP: Press Esc to cancel OAuth authentication flows
+- Bash: Improved command validation and reduced false security warnings
+- UI: Enhanced spinner animations and status line visual hierarchy
+- Linux: Added support for Alpine and musl-based distributions (requires separate ripgrep installation)
+
+## 1.0.72
+
+- Ask permissions: have Claude Code always ask for confirmation to use specific tools with /permissions
+
+## 1.0.71
+
+- Background commands: (Ctrl-b) to run any Bash command in the background so Claude can keep working (great for dev servers, tailing logs, etc.)
+- Customizable status line: add your terminal prompt to Claude Code with /statusline
+
+## 1.0.70
+
+- Performance: Optimized message rendering for better performance with large contexts
+- Windows: Fixed native file search, ripgrep, and subagent functionality
+- Added support for @-mentions in slash command arguments
+
+## 1.0.69
+
+- Upgraded Opus to version 4.1
+
+## 1.0.68
+
+- Fix incorrect model names being used for certain commands like `/pr-comments`
+- Windows: improve permissions checks for allow / deny tools and project trust. This may create a new project entry in `.claude.json` - manually merge the history field if desired.
+- Windows: improve sub-process spawning to eliminate "No such file or directory" when running commands like pnpm
+- Enhanced /doctor command with CLAUDE.md and MCP tool context for self-serve debugging
+- SDK: Added canUseTool callback support for tool confirmation
+- Added `disableAllHooks` setting
+- Improved file suggestions performance in large repos
+
+## 1.0.65
+
+- IDE: Fixed connection stability issues and error handling for diagnostics
+- Windows: Fixed shell environment setup for users without .bashrc files
+
+## 1.0.64
+
+- Agents: Added model customization support - you can now specify which model an agent should use
+- Agents: Fixed unintended access to the recursive agent tool
+- Hooks: Added systemMessage field to hook JSON output for displaying warnings and context
+- SDK: Fixed user input tracking across multi-turn conversations
+- Added hidden files to file search and @-mention suggestions
+
+## 1.0.63
+
+- Windows: Fixed file search, @agent mentions, and custom slash commands functionality
+
+## 1.0.62
+
+- Added @-mention support with typeahead for custom agents. @<your-custom-agent> to invoke it
+- Hooks: Added SessionStart hook for new session initialization
+- /add-dir command now supports typeahead for directory paths
+- Improved network connectivity check reliability
+
+## 1.0.61
+
+- Transcript mode (Ctrl+R): Changed Esc to exit transcript mode rather than interrupt
+- Settings: Added `--settings` flag to load settings from a JSON file
+- Settings: Fixed resolution of settings files paths that are symlinks
+- OTEL: Fixed reporting of wrong organization after authentication changes
+- Slash commands: Fixed permissions checking for allowed-tools with Bash
+- IDE: Added support for pasting images in VSCode MacOS using ⌘+V
+- IDE: Added `CLAUDE_CODE_AUTO_CONNECT_IDE=false` for disabling IDE auto-connection
+- Added `CLAUDE_CODE_SHELL_PREFIX` for wrapping Claude and user-provided shell commands run by Claude Code
+
+## 1.0.60
+
+- You can now create custom subagents for specialized tasks! Run /agents to get started
+
+## 1.0.59
+
+- SDK: Added tool confirmation support with canUseTool callback
+- SDK: Allow specifying env for spawned process
+- Hooks: Exposed PermissionDecision to hooks (including "ask")
+- Hooks: UserPromptSubmit now supports additionalContext in advanced JSON output
+- Fixed issue where some Max users that specified Opus would still see fallback to Sonnet
+
+## 1.0.58
+
+- Added support for reading PDFs
+- MCP: Improved server health status display in 'claude mcp list'
+- Hooks: Added CLAUDE_PROJECT_DIR env var for hook commands
+
+## 1.0.57
+
+- Added support for specifying a model in slash commands
+- Improved permission messages to help Claude understand allowed tools
+- Fix: Remove trailing newlines from bash output in terminal wrapping
+
+## 1.0.56
+
+- Windows: Enabled shift+tab for mode switching on versions of Node.js that support terminal VT mode
+- Fixes for WSL IDE detection
+- Fix an issue causing awsRefreshHelper changes to .aws directory not to be picked up
+
+## 1.0.55
+
+- Clarified knowledge cutoff for Opus 4 and Sonnet 4 models
+- Windows: fixed Ctrl+Z crash
+- SDK: Added ability to capture error logging
+- Add --system-prompt-file option to override system prompt in print mode
+
+## 1.0.54
+
+- Hooks: Added UserPromptSubmit hook and the current working directory to hook inputs
+- Custom slash commands: Added argument-hint to frontmatter
+- Windows: OAuth uses port 45454 and properly constructs browser URL
+- Windows: mode switching now uses alt + m, and plan mode renders properly
+- Shell: Switch to in-memory shell snapshot to fix file-related errors
+
+## 1.0.53
+
+- Updated @-mention file truncation from 100 lines to 2000 lines
+- Add helper script settings for AWS token refresh: awsAuthRefresh (for foreground operations like aws sso login) and awsCredentialExport (for background operation with STS-like response).
+
+## 1.0.52
+
+- Added support for MCP server instructions
+
+## 1.0.51
+
+- Added support for native Windows (requires Git for Windows)
+- Added support for Bedrock API keys through environment variable AWS_BEARER_TOKEN_BEDROCK
+- Settings: /doctor can now help you identify and fix invalid setting files
+- `--append-system-prompt` can now be used in interactive mode, not just --print/-p.
+- Increased auto-compact warning threshold from 60% to 80%
+- Fixed an issue with handling user directories with spaces for shell snapshots
+- OTEL resource now includes os.type, os.version, host.arch, and wsl.version (if running on Windows Subsystem for Linux)
+- Custom slash commands: Fixed user-level commands in subdirectories
+- Plan mode: Fixed issue where rejected plan from sub-task would get discarded
+
+## 1.0.48
+
+- Fixed a bug in v1.0.45 where the app would sometimes freeze on launch
+- Added progress messages to Bash tool based on the last 5 lines of command output
+- Added expanding variables support for MCP server configuration
+- Moved shell snapshots from /tmp to ~/.claude for more reliable Bash tool calls
+- Improved IDE extension path handling when Claude Code runs in WSL
+- Hooks: Added a PreCompact hook
+- Vim mode: Added c, f/F, t/T
+
+## 1.0.45
+
+- Redesigned Search (Grep) tool with new tool input parameters and features
+- Disabled IDE diffs for notebook files, fixing "Timeout waiting after 1000ms" error
+- Fixed config file corruption issue by enforcing atomic writes
+- Updated prompt input undo to Ctrl+\_ to avoid breaking existing Ctrl+U behavior, matching zsh's undo shortcut
+- Stop Hooks: Fixed transcript path after /clear and fixed triggering when loop ends with tool call
+- Custom slash commands: Restored namespacing in command names based on subdirectories. For example, .claude/commands/frontend/component.md is now /frontend:component, not /component.
+
+## 1.0.44
+
+- New /export command lets you quickly export a conversation for sharing
+- MCP: resource_link tool results are now supported
+- MCP: tool annotations and tool titles now display in /mcp view
+- Changed Ctrl+Z to suspend Claude Code. Resume by running `fg`. Prompt input undo is now Ctrl+U.
+
+## 1.0.43
+
+- Fixed a bug where the theme selector was saving excessively
+- Hooks: Added EPIPE system error handling
+
+## 1.0.42
+
+- Added tilde (`~`) expansion support to `/add-dir` command
+
+## 1.0.41
+
+- Hooks: Split Stop hook triggering into Stop and SubagentStop
+- Hooks: Enabled optional timeout configuration for each command
+- Hooks: Added "hook_event_name" to hook input
+- Fixed a bug where MCP tools would display twice in tool list
+- New tool parameters JSON for Bash tool in `tool_decision` event
+
+## 1.0.40
+
+- Fixed a bug causing API connection errors with UNABLE_TO_GET_ISSUER_CERT_LOCALLY if `NODE_EXTRA_CA_CERTS` was set
+
+## 1.0.39
+
+- New Active Time metric in OpenTelemetry logging
+
+## 1.0.38
+
+- Released hooks. Special thanks to community input in https://github.com/anthropics/claude-code/issues/712. Docs: https://docs.claude.com/en/docs/claude-code/hooks
+
+## 1.0.37
+
+- Remove ability to set `Proxy-Authorization` header via ANTHROPIC_AUTH_TOKEN or apiKeyHelper
+
+## 1.0.36
+
+- Web search now takes today's date into context
+- Fixed a bug where stdio MCP servers were not terminating properly on exit
+
+## 1.0.35
+
+- Added support for MCP OAuth Authorization Server discovery
+
+## 1.0.34
+
+- Fixed a memory leak causing a MaxListenersExceededWarning message to appear
+
+## 1.0.33
+
+- Improved logging functionality with session ID support
+- Added prompt input undo functionality (Ctrl+Z and vim 'u' command)
+- Improvements to plan mode
+
+## 1.0.32
+
+- Updated loopback config for litellm
+- Added forceLoginMethod setting to bypass login selection screen
+
+## 1.0.31
+
+- Fixed a bug where ~/.claude.json would get reset when file contained invalid JSON
+
+## 1.0.30
+
+- Custom slash commands: Run bash output, @-mention files, enable thinking with thinking keywords
+- Improved file path autocomplete with filename matching
+- Added timestamps in Ctrl-r mode and fixed Ctrl-c handling
+- Enhanced jq regex support for complex filters with pipes and select
+
+## 1.0.29
+
+- Improved CJK character support in cursor navigation and rendering
+
+## 1.0.28
+
+- Slash commands: Fix selector display during history navigation
+- Resizes images before upload to prevent API size limit errors
+- Added XDG_CONFIG_HOME support to configuration directory
+- Performance optimizations for memory usage
+- New attributes (terminal.type, language) in OpenTelemetry logging
+
+## 1.0.27
+
+- Streamable HTTP MCP servers are now supported
+- Remote MCP servers (SSE and HTTP) now support OAuth
+- MCP resources can now be @-mentioned
+- /resume slash command to switch conversations within Claude Code
+
+## 1.0.25
+
+- Slash commands: moved "project" and "user" prefixes to descriptions
+- Slash commands: improved reliability for command discovery
+- Improved support for Ghostty
+- Improved web search reliability
+
+## 1.0.24
+
+- Improved /mcp output
+- Fixed a bug where settings arrays got overwritten instead of merged
+
+## 1.0.23
+
+- Released TypeScript SDK: import @anthropic-ai/claude-code to get started
+- Released Python SDK: pip install claude-code-sdk to get started
+
+## 1.0.22
+
+- SDK: Renamed `total_cost` to `total_cost_usd`
+
+## 1.0.21
+
+- Improved editing of files with tab-based indentation
+- Fix for tool_use without matching tool_result errors
+- Fixed a bug where stdio MCP server processes would linger after quitting Claude Code
+
+## 1.0.18
+
+- Added --add-dir CLI argument for specifying additional working directories
+- Added streaming input support without require -p flag
+- Improved startup performance and session storage performance
+- Added CLAUDE_BASH_MAINTAIN_PROJECT_WORKING_DIR environment variable to freeze working directory for bash commands
+- Added detailed MCP server tools display (/mcp)
+- MCP authentication and permission improvements
+- Added auto-reconnection for MCP SSE connections on disconnect
+- Fixed issue where pasted content was lost when dialogs appeared
+
+## 1.0.17
+
+- We now emit messages from sub-tasks in -p mode (look for the parent_tool_use_id property)
+- Fixed crashes when the VS Code diff tool is invoked multiple times quickly
+- MCP server list UI improvements
+- Update Claude Code process title to display "claude" instead of "node"
+
+## 1.0.11
+
+- Claude Code can now also be used with a Claude Pro subscription
+- Added /upgrade for smoother switching to Claude Max plans
+- Improved UI for authentication from API keys and Bedrock/Vertex/external auth tokens
+- Improved shell configuration error handling
+- Improved todo list handling during compaction
+
+## 1.0.10
+
+- Added markdown table support
+- Improved streaming performance
+
+## 1.0.8
+
+- Fixed Vertex AI region fallback when using CLOUD_ML_REGION
+- Increased default otel interval from 1s -> 5s
+- Fixed edge cases where MCP_TIMEOUT and MCP_TOOL_TIMEOUT weren't being respected
+- Fixed a regression where search tools unnecessarily asked for permissions
+- Added support for triggering thinking non-English languages
+- Improved compacting UI
+
+## 1.0.7
+
+- Renamed /allowed-tools -> /permissions
+- Migrated allowedTools and ignorePatterns from .claude.json -> settings.json
+- Deprecated claude config commands in favor of editing settings.json
+- Fixed a bug where --dangerously-skip-permissions sometimes didn't work in --print mode
+- Improved error handling for /install-github-app
+- Bugfixes, UI polish, and tool reliability improvements
+
+## 1.0.6
+
+- Improved edit reliability for tab-indented files
+- Respect CLAUDE_CONFIG_DIR everywhere
+- Reduced unnecessary tool permission prompts
+- Added support for symlinks in @file typeahead
+- Bugfixes, UI polish, and tool reliability improvements
+
+## 1.0.4
+
+- Fixed a bug where MCP tool errors weren't being parsed correctly
+
+## 1.0.1
+
+- Added `DISABLE_INTERLEAVED_THINKING` to give users the option to opt out of interleaved thinking.
+- Improved model references to show provider-specific names (Sonnet 3.7 for Bedrock, Sonnet 4 for Console)
+- Updated documentation links and OAuth process descriptions
+
+## 1.0.0
+
+- Claude Code is now generally available
+- Introducing Sonnet 4 and Opus 4 models
+
+## 0.2.125
+
+- Breaking change: Bedrock ARN passed to `ANTHROPIC_MODEL` or `ANTHROPIC_SMALL_FAST_MODEL` should no longer contain an escaped slash (specify `/` instead of `%2F`)
+- Removed `DEBUG=true` in favor of `ANTHROPIC_LOG=debug`, to log all requests
+
+## 0.2.117
+
+- Breaking change: --print JSON output now returns nested message objects, for forwards-compatibility as we introduce new metadata fields
+- Introduced settings.cleanupPeriodDays
+- Introduced CLAUDE_CODE_API_KEY_HELPER_TTL_MS env var
+- Introduced --debug mode
+
+## 0.2.108
+
+- You can now send messages to Claude while it works to steer Claude in real-time
+- Introduced BASH_DEFAULT_TIMEOUT_MS and BASH_MAX_TIMEOUT_MS env vars
+- Fixed a bug where thinking was not working in -p mode
+- Fixed a regression in /cost reporting
+- Deprecated MCP wizard interface in favor of other MCP commands
+- Lots of other bugfixes and improvements
+
+## 0.2.107
+
+- CLAUDE.md files can now import other files. Add @path/to/file.md to ./CLAUDE.md to load additional files on launch
+
+## 0.2.106
+
+- MCP SSE server configs can now specify custom headers
+- Fixed a bug where MCP permission prompt didn't always show correctly
+
+## 0.2.105
+
+- Claude can now search the web
+- Moved system & account status to /status
+- Added word movement keybindings for Vim
+- Improved latency for startup, todo tool, and file edits
+
+## 0.2.102
+
+- Improved thinking triggering reliability
+- Improved @mention reliability for images and folders
+- You can now paste multiple large chunks into one prompt
+
+## 0.2.100
+
+- Fixed a crash caused by a stack overflow error
+- Made db storage optional; missing db support disables --continue and --resume
+
+## 0.2.98
+
+- Fixed an issue where auto-compact was running twice
+
+## 0.2.96
+
+- Claude Code can now also be used with a Claude Max subscription (https://claude.ai/upgrade)
+
+## 0.2.93
+
+- Resume conversations from where you left off from with "claude --continue" and "claude --resume"
+- Claude now has access to a Todo list that helps it stay on track and be more organized
+
+## 0.2.82
+
+- Added support for --disallowedTools
+- Renamed tools for consistency: LSTool -> LS, View -> Read, etc.
+
+## 0.2.75
+
+- Hit Enter to queue up additional messages while Claude is working
+- Drag in or copy/paste image files directly into the prompt
+- @-mention files to directly add them to context
+- Run one-off MCP servers with `claude --mcp-config <path-to-file>`
+- Improved performance for filename auto-complete
+
+## 0.2.74
+
+- Added support for refreshing dynamically generated API keys (via apiKeyHelper), with a 5 minute TTL
+- Task tool can now perform writes and run bash commands
+
+## 0.2.72
+
+- Updated spinner to indicate tokens loaded and tool usage
+
+## 0.2.70
+
+- Network commands like curl are now available for Claude to use
+- Claude can now run multiple web queries in parallel
+- Pressing ESC once immediately interrupts Claude in Auto-accept mode
+
+## 0.2.69
+
+- Fixed UI glitches with improved Select component behavior
+- Enhanced terminal output display with better text truncation logic
+
+## 0.2.67
+
+- Shared project permission rules can be saved in .claude/settings.json
+
+## 0.2.66
+
+- Print mode (-p) now supports streaming output via --output-format=stream-json
+- Fixed issue where pasting could trigger memory or bash mode unexpectedly
+
+## 0.2.63
+
+- Fixed an issue where MCP tools were loaded twice, which caused tool call errors
+
+## 0.2.61
+
+- Navigate menus with vim-style keys (j/k) or bash/emacs shortcuts (Ctrl+n/p) for faster interaction
+- Enhanced image detection for more reliable clipboard paste functionality
+- Fixed an issue where ESC key could crash the conversation history selector
+
+## 0.2.59
+
+- Copy+paste images directly into your prompt
+- Improved progress indicators for bash and fetch tools
+- Bugfixes for non-interactive mode (-p)
+
+## 0.2.54
+
+- Quickly add to Memory by starting your message with '#'
+- Press ctrl+r to see full output for long tool results
+- Added support for MCP SSE transport
+
+## 0.2.53
+
+- New web fetch tool lets Claude view URLs that you paste in
+- Fixed a bug with JPEG detection
+
+## 0.2.50
+
+- New MCP "project" scope now allows you to add MCP servers to .mcp.json files and commit them to your repository
+
+## 0.2.49
+
+- Previous MCP server scopes have been renamed: previous "project" scope is now "local" and "global" scope is now "user"
+
+## 0.2.47
+
+- Press Tab to auto-complete file and folder names
+- Press Shift + Tab to toggle auto-accept for file edits
+- Automatic conversation compaction for infinite conversation length (toggle with /config)
+
+## 0.2.44
+
+- Ask Claude to make a plan with thinking mode: just say 'think' or 'think harder' or even 'ultrathink'
+
+## 0.2.41
+
+- MCP server startup timeout can now be configured via MCP_TIMEOUT environment variable
+- MCP server startup no longer blocks the app from starting up
+
+## 0.2.37
+
+- New /release-notes command lets you view release notes at any time
+- `claude config add/remove` commands now accept multiple values separated by commas or spaces
+
+## 0.2.36
+
+- Import MCP servers from Claude Desktop with `claude mcp add-from-claude-desktop`
+- Add MCP servers as JSON strings with `claude mcp add-json <n> <json>`
+
+## 0.2.34
+
+- Vim bindings for text input - enable with /vim or /config
+
+## 0.2.32
+
+- Interactive MCP setup wizard: Run "claude mcp add" to add MCP servers with a step-by-step interface
+- Fix for some PersistentShell issues
+
+## 0.2.31
+
+- Custom slash commands: Markdown files in .claude/commands/ directories now appear as custom slash commands to insert prompts into your conversation
+- MCP debug mode: Run with --mcp-debug flag to get more information about MCP server errors
+
+## 0.2.30
+
+- Added ANSI color theme for better terminal compatibility
+- Fixed issue where slash command arguments weren't being sent properly
+- (Mac-only) API keys are now stored in macOS Keychain
+
+## 0.2.26
+
+- New /approved-tools command for managing tool permissions
+- Word-level diff display for improved code readability
+- Fuzzy matching for slash commands
+
+## 0.2.21
+
+- Fuzzy matching for /commands

LICENSE.md

@@ -1,3 +1 @@
-Claude Code is a Beta research preview per our [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms). When you use Claude Code, we collect Feedback, which includes usage data such as code acceptance or rejections, as well as associated conversation data. We may use this Feedback to improve our products, although we will not train models using your Feedback from Claude Code.
-
 © Anthropic PBC. All rights reserved. Use is subject to Anthropic's [Commercial Terms of Service](https://www.anthropic.com/legal/commercial-terms).

README.md

@@ -1,57 +1,44 @@
-# Claude Code (Research Preview)
+# Claude Code
 
 ![](https://img.shields.io/badge/Node.js-18%2B-brightgreen?style=flat-square) [![npm]](https://www.npmjs.com/package/@anthropic-ai/claude-code)
 
 [npm]: https://img.shields.io/npm/v/@anthropic-ai/claude-code.svg?style=flat-square
 
-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.
+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.
 
-Some of its key capabilities include:
+**Learn more in the [official documentation](https://docs.anthropic.com/en/docs/claude-code/overview)**.
 
-- Edit files and fix bugs across your codebase
-- Answer questions about your code's architecture and logic
-- Execute and fix tests, lint, and other commands
-- Search through git history, resolve merge conflicts, and create commits and PRs
-
-**Learn more in the [official documentation](https://docs.anthropic.com/en/docs/agents/claude-code/introduction)**.
+<img src="./demo.gif" />
 
 ## Get started
 
-1. If you are new to Node.js and Node Package Manager (`npm`), then it is recommended that you configure an NPM prefix for your user.
-   Instructions on how to do this can be found [here](https://docs.anthropic.com/en/docs/agents-and-tools/claude-code/overview#recommended-create-a-new-user-writable-npm-prefix).
+1. Install Claude Code:
 
-   *Important* We recommend installing this package as a non-privileged user, not as an administrative user like `root`.
-   Installing as a non-privileged user helps maintain your system's security and stability.
+```sh
+npm install -g @anthropic-ai/claude-code
+```
 
-2. Install Claude Code:
-   
-   ```sh
-   npm install -g @anthropic-ai/claude-code
-   ```
+2. Navigate to your project directory and run `claude`.
 
-3. Navigate to your project directory and run <code>claude</code>.
+## Plugins
 
-4. Complete the one-time OAuth process with your Anthropic Console account.
+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.
 
-### Research Preview
+## Reporting Bugs
 
-We're launching Claude Code as a beta product in research preview to learn directly from developers about their experiences collaborating with AI agents. Our aim is to learn more about how developers prefer to collaborate with AI tools, which development workflows benefit most from working with the agent, and how we can make the agent experience more intuitive.
+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).
 
-This is an early version of the product experience, and it's likely to evolve as we learn more about developer preferences. Claude Code is an early look into what's possible with agentic coding, and we know there are areas to improve. We plan to enhance tool execution reliability, support for long-running commands, terminal rendering, and Claude's self-knowledge of its capabilities -- as well as many other product experiences -- over the coming weeks.
+## Connect on Discord
 
-### Reporting Bugs
+Join the [Claude Developers Discord](https://anthropic.com/discord) to connect with other developers using Claude Code. Get help, share feedback, and discuss your projects with the community.
 
-We welcome feedback during this beta period. Use the `/bug` command to report issues directly within Claude Code, or file a [GitHub issue](https://github.com/anthropics/claude-code/issues).
-
-### Data collection, usage, and retention
+## Data collection, usage, and retention
 
 When you use Claude Code, we collect feedback, which includes usage data (such as code acceptance or rejections), associated conversation data, and user feedback submitted via the `/bug` command.
 
-#### How we use your data
+### How we use your data
 
-We may use feedback to improve our products and services, but we will not train generative models using your feedback from Claude Code. Given their potentially sensitive nature, we store user feedback transcripts for only 30 days.
-
-If you choose to send us feedback about Claude Code, such as transcripts of your usage, Anthropic may use that feedback to debug related issues and improve Claude Code's functionality (e.g., to reduce the risk of similar bugs occurring in the future).
+See our [data usage policies](https://docs.anthropic.com/en/docs/claude-code/data-usage).
 
 ### Privacy safeguards
 

Script/run_devcontainer_claude_code.ps1

@@ -0,0 +1,152 @@
+<#
+.SYNOPSIS
+    Automates the setup and connection to a DevContainer environment using either Docker or Podman on Windows.
+
+.DESCRIPTION
+    This script automates the process of initializing, starting, and connecting to a DevContainer
+    using either Docker or Podman as the container backend. It must be executed from the root
+    directory of your project and assumes the script is located in a 'Script' subdirectory.
+
+.PARAMETER Backend
+    Specifies the container backend to use. Valid values are 'docker' or 'podman'.
+
+.EXAMPLE
+    .\Script\run_devcontainer_claude_code.ps1 -Backend docker
+    Uses Docker as the container backend.
+
+.EXAMPLE
+    .\Script\run_devcontainer_claude_code.ps1 -Backend podman
+    Uses Podman as the container backend.
+
+.NOTES
+    Project Structure:
+    Project/
+    ├── .devcontainer/
+    └── Script/
+        └── run_devcontainer_claude_code.ps1
+#>
+
+[CmdletBinding()]
+param(
+    [Parameter(Mandatory=$true)]
+    [ValidateSet('docker','podman')]
+    [string]$Backend
+)
+
+# Notify script start
+Write-Host "--- DevContainer Startup & Connection Script ---"
+Write-Host "Using backend: $($Backend)"
+
+# --- Prerequisite Check ---
+Write-Host "Checking for required commands..."
+try {
+    if (-not (Get-Command $Backend -ErrorAction SilentlyContinue)) {
+        throw "Required command '$($Backend)' not found."
+    }
+    Write-Host "- $($Backend) command found."
+    if (-not (Get-Command devcontainer -ErrorAction SilentlyContinue)) {
+        throw "Required command 'devcontainer' not found."
+    }
+    Write-Host "- devcontainer command found."
+}
+catch {
+    Write-Error "A required command is not installed or not in your PATH. $($_.Exception.Message)"
+    Write-Error "Please ensure both '$Backend' and 'devcontainer' are installed and accessible in your system's PATH."
+    exit 1
+}
+
+
+# --- Backend-Specific Initialization ---
+if ($Backend -eq 'podman') {
+    Write-Host "--- Podman Backend Initialization ---"
+
+    # --- Step 1a: Initialize Podman machine ---
+    Write-Host "Initializing Podman machine 'claudeVM'..."
+    try {
+        & podman machine init claudeVM
+        Write-Host "Podman machine 'claudeVM' initialized or already exists."
+    } catch {
+        Write-Error "Failed to initialize Podman machine: $($_.Exception.Message)"
+        exit 1 # Exit script on error
+    }
+
+    # --- Step 1b: Start Podman machine ---
+    Write-Host "Starting Podman machine 'claudeVM'..."
+    try {
+        & podman machine start claudeVM -q
+        Write-Host "Podman machine started or already running."
+    } catch {
+        Write-Error "Failed to start Podman machine: $($_.Exception.Message)"
+        exit 1
+    }
+
+    # --- Step 2: Set default connection ---
+    Write-Host "Setting default Podman connection to 'claudeVM'..."
+    try {
+        & podman system connection default claudeVM
+        Write-Host "Default connection set."
+    } catch {
+        Write-Warning "Failed to set default Podman connection (may be already set or machine issue): $($_.Exception.Message)"
+    }
+
+} elseif ($Backend -eq 'docker') {
+    Write-Host "--- Docker Backend Initialization ---"
+
+    # --- Step 1 & 2: Check Docker Desktop ---
+    Write-Host "Checking if Docker Desktop is running and docker command is available..."
+    try {
+        docker info | Out-Null
+        Write-Host "Docker Desktop (daemon) is running."
+    } catch {
+        Write-Error "Docker Desktop is not running or docker command not found."
+        Write-Error "Please ensure Docker Desktop is running."
+        exit 1
+    }
+}
+
+# --- Step 3: Bring up DevContainer ---
+Write-Host "Bringing up DevContainer in the current folder..."
+try {
+    $arguments = @('up', '--workspace-folder', '.')
+    if ($Backend -eq 'podman') {
+        $arguments += '--docker-path', 'podman'
+    }
+    & devcontainer @arguments
+    Write-Host "DevContainer startup process completed."
+} catch {
+    Write-Error "Failed to bring up DevContainer: $($_.Exception.Message)"
+    exit 1
+}
+
+# --- Step 4: Get DevContainer ID ---
+Write-Host "Finding the DevContainer ID..."
+$currentFolder = (Get-Location).Path
+
+try {
+    $containerId = (& $Backend ps --filter "label=devcontainer.local_folder=$currentFolder" --format '{{.ID}}').Trim()
+} catch {
+    $displayCommand = "$Backend ps --filter `"label=devcontainer.local_folder=$currentFolder`" --format '{{.ID}}'"
+    Write-Error "Failed to get container ID (Command: $displayCommand): $($_.Exception.Message)"
+    exit 1
+}
+
+if (-not $containerId) {
+    Write-Error "Could not find DevContainer ID for the current folder ('$currentFolder')."
+    Write-Error "Please check if 'devcontainer up' was successful and the container is running."
+    exit 1
+}
+Write-Host "Found container ID: $containerId"
+
+# --- Step 5 & 6: Execute command and enter interactive shell inside container ---
+Write-Host "Executing 'claude' command and then starting zsh session inside container $($containerId)..."
+try {
+    & $Backend exec -it $containerId zsh -c 'claude; exec zsh'
+    Write-Host "Interactive session ended."
+} catch {
+    $displayCommand = "$Backend exec -it $containerId zsh -c 'claude; exec zsh'"
+    Write-Error "Failed to execute command inside container (Command: $displayCommand): $($_.Exception.Message)"
+    exit 1
+}
+
+# Notify script completion
+Write-Host "--- Script completed ---"

examples/hooks/bash_command_validator_example.py

@@ -0,0 +1,83 @@
+#!/usr/bin/env python3
+"""
+Claude Code Hook: Bash Command Validator
+=========================================
+This hook runs as a PreToolUse hook for the Bash tool.
+It validates bash commands against a set of rules before execution.
+In this case it changes grep calls to using rg.
+
+Read more about hooks here: https://docs.anthropic.com/en/docs/claude-code/hooks
+
+Make sure to change your path to your actual script.
+
+{
+  "hooks": {
+    "PreToolUse": [
+      {
+        "matcher": "Bash",
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 /path/to/claude-code/examples/hooks/bash_command_validator_example.py"
+          }
+        ]
+      }
+    ]
+  }
+}
+
+"""
+
+import json
+import re
+import sys
+
+# Define validation rules as a list of (regex pattern, message) tuples
+_VALIDATION_RULES = [
+    (
+        r"^grep\b(?!.*\|)",
+        "Use 'rg' (ripgrep) instead of 'grep' for better performance and features",
+    ),
+    (
+        r"^find\s+\S+\s+-name\b",
+        "Use 'rg --files | rg pattern' or 'rg --files -g pattern' instead of 'find -name' for better performance",
+    ),
+]
+
+
+def _validate_command(command: str) -> list[str]:
+    issues = []
+    for pattern, message in _VALIDATION_RULES:
+        if re.search(pattern, command):
+            issues.append(message)
+    return issues
+
+
+def main():
+    try:
+        input_data = json.load(sys.stdin)
+    except json.JSONDecodeError as e:
+        print(f"Error: Invalid JSON input: {e}", file=sys.stderr)
+        # Exit code 1 shows stderr to the user but not to Claude
+        sys.exit(1)
+
+    tool_name = input_data.get("tool_name", "")
+    if tool_name != "Bash":
+        sys.exit(0)
+
+    tool_input = input_data.get("tool_input", {})
+    command = tool_input.get("command", "")
+
+    if not command:
+        sys.exit(0)
+
+    issues = _validate_command(command)
+    if issues:
+        for message in issues:
+            print(f"• {message}", file=sys.stderr)
+        # Exit code 2 blocks tool call and shows stderr to Claude
+        sys.exit(2)
+
+
+if __name__ == "__main__":
+    main()

plugins/README.md

@@ -0,0 +1,103 @@
+# Claude Code Plugins
+
+This directory contains some official Claude Code plugins that extend functionality through custom commands, agents, and workflows. These are examples of what's possible with the Claude Code plugin system—many more plugins are available through community marketplaces.
+
+## What are Claude Code Plugins?
+
+Claude Code plugins are extensions that enhance Claude Code with custom slash commands, specialized agents, hooks, and MCP servers. Plugins can be shared across projects and teams, providing consistent tooling and workflows.
+
+Learn more in the [official plugins documentation](https://docs.claude.com/en/docs/claude-code/plugins).
+
+## 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
+
+## Installation
+
+These plugins are included in the Claude Code repository. To use them in your own projects:
+
+1. Install Claude Code globally:
+```bash
+npm install -g @anthropic-ai/claude-code
+```
+
+2. Navigate to your project and run Claude Code:
+```bash
+claude
+```
+
+3. Use the `/plugin` command to install plugins from marketplaces, or configure them in your project's `.claude/settings.json`.
+
+For detailed plugin installation and configuration, see the [official documentation](https://docs.claude.com/en/docs/claude-code/plugins).
+
+## Plugin Structure
+
+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)
+└── README.md                # Plugin documentation
+```
+
+## Contributing
+
+When adding new plugins to this directory:
+
+1. Follow the standard plugin structure
+2. Include a comprehensive README.md
+3. Add plugin metadata in `.claude-plugin/plugin.json`
+4. Document all commands and agents
+5. Provide usage examples
+
+## Learn More
+
+- [Claude Code Documentation](https://docs.claude.com/en/docs/claude-code/overview)
+- [Plugin System Documentation](https://docs.claude.com/en/docs/claude-code/plugins)
+- [Agent SDK Documentation](https://docs.claude.com/en/api/agent-sdk/overview)

plugins/agent-sdk-dev/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "agent-sdk-dev",
+  "description": "Claude Agent SDK Development Plugin",
+  "version": "1.0.0",
+  "author": {
+    "name": "Ashwin Bhat",
+    "email": "ashwin@anthropic.com"
+  }
+}

plugins/agent-sdk-dev/README.md

@@ -0,0 +1,208 @@
+# Agent SDK Development Plugin
+
+A comprehensive plugin for creating and verifying Claude Agent SDK applications in Python and TypeScript.
+
+## Overview
+
+The Agent SDK Development Plugin streamlines the entire lifecycle of building Agent SDK applications, from initial scaffolding to verification against best practices. It helps you quickly start new projects with the latest SDK versions and ensures your applications follow official documentation patterns.
+
+## Features
+
+### Command: `/new-sdk-app`
+
+Interactive command that guides you through creating a new Claude Agent SDK application.
+
+**What it does:**
+- Asks clarifying questions about your project (language, name, agent type, starting point)
+- Checks for and installs the latest SDK version
+- Creates all necessary project files and configuration
+- Sets up proper environment files (.env.example, .gitignore)
+- Provides a working example tailored to your use case
+- Runs type checking (TypeScript) or syntax validation (Python)
+- Automatically verifies the setup using the appropriate verifier agent
+
+**Usage:**
+```bash
+/new-sdk-app my-project-name
+```
+
+Or simply:
+```bash
+/new-sdk-app
+```
+
+The command will interactively ask you:
+1. Language choice (TypeScript or Python)
+2. Project name (if not provided)
+3. Agent type (coding, business, custom)
+4. Starting point (minimal, basic, or specific example)
+5. Tooling preferences (npm/yarn/pnpm or pip/poetry)
+
+**Example:**
+```bash
+/new-sdk-app customer-support-agent
+# → Creates a new Agent SDK project for a customer support agent
+# → Sets up TypeScript or Python environment
+# → Installs latest SDK version
+# → Verifies the setup automatically
+```
+
+### Agent: `agent-sdk-verifier-py`
+
+Thoroughly verifies Python Agent SDK applications for correct setup and best practices.
+
+**Verification checks:**
+- SDK installation and version
+- Python environment setup (requirements.txt, pyproject.toml)
+- Correct SDK usage and patterns
+- Agent initialization and configuration
+- Environment and security (.env, API keys)
+- Error handling and functionality
+- Documentation completeness
+
+**When to use:**
+- After creating a new Python SDK project
+- After modifying an existing Python SDK application
+- Before deploying a Python SDK application
+
+**Usage:**
+The agent runs automatically after `/new-sdk-app` creates a Python project, or you can trigger it by asking:
+```
+"Verify my Python Agent SDK application"
+"Check if my SDK app follows best practices"
+```
+
+**Output:**
+Provides a comprehensive report with:
+- Overall status (PASS / PASS WITH WARNINGS / FAIL)
+- Critical issues that prevent functionality
+- Warnings about suboptimal patterns
+- List of passed checks
+- Specific recommendations with SDK documentation references
+
+### Agent: `agent-sdk-verifier-ts`
+
+Thoroughly verifies TypeScript Agent SDK applications for correct setup and best practices.
+
+**Verification checks:**
+- SDK installation and version
+- TypeScript configuration (tsconfig.json)
+- Correct SDK usage and patterns
+- Type safety and imports
+- Agent initialization and configuration
+- Environment and security (.env, API keys)
+- Error handling and functionality
+- Documentation completeness
+
+**When to use:**
+- After creating a new TypeScript SDK project
+- After modifying an existing TypeScript SDK application
+- Before deploying a TypeScript SDK application
+
+**Usage:**
+The agent runs automatically after `/new-sdk-app` creates a TypeScript project, or you can trigger it by asking:
+```
+"Verify my TypeScript Agent SDK application"
+"Check if my SDK app follows best practices"
+```
+
+**Output:**
+Provides a comprehensive report with:
+- Overall status (PASS / PASS WITH WARNINGS / FAIL)
+- Critical issues that prevent functionality
+- Warnings about suboptimal patterns
+- List of passed checks
+- Specific recommendations with SDK documentation references
+
+## Workflow Example
+
+Here's a typical workflow using this plugin:
+
+1. **Create a new project:**
+```bash
+/new-sdk-app code-reviewer-agent
+```
+
+2. **Answer the interactive questions:**
+```
+Language: TypeScript
+Agent type: Coding agent (code review)
+Starting point: Basic agent with common features
+```
+
+3. **Automatic verification:**
+The command automatically runs `agent-sdk-verifier-ts` to ensure everything is correctly set up.
+
+4. **Start developing:**
+```bash
+# Set your API key
+echo "ANTHROPIC_API_KEY=your_key_here" > .env
+
+# Run your agent
+npm start
+```
+
+5. **Verify after changes:**
+```
+"Verify my SDK application"
+```
+
+## Installation
+
+This plugin is included in the Claude Code repository. To use it:
+
+1. Ensure Claude Code is installed
+2. The plugin commands and agents are automatically available
+
+## Best Practices
+
+- **Always use the latest SDK version**: `/new-sdk-app` checks for and installs the latest version
+- **Verify before deploying**: Run the verifier agent before deploying to production
+- **Keep API keys secure**: Never commit `.env` files or hardcode API keys
+- **Follow SDK documentation**: The verifier agents check against official patterns
+- **Type check TypeScript projects**: Run `npx tsc --noEmit` regularly
+- **Test your agents**: Create test cases for your agent's functionality
+
+## Resources
+
+- [Agent SDK Overview](https://docs.claude.com/en/api/agent-sdk/overview)
+- [TypeScript SDK Reference](https://docs.claude.com/en/api/agent-sdk/typescript)
+- [Python SDK Reference](https://docs.claude.com/en/api/agent-sdk/python)
+- [Agent SDK Examples](https://docs.claude.com/en/api/agent-sdk/examples)
+
+## Troubleshooting
+
+### Type errors in TypeScript project
+
+**Issue**: TypeScript project has type errors after creation
+
+**Solution**:
+- The `/new-sdk-app` command runs type checking automatically
+- If errors persist, check that you're using the latest SDK version
+- Verify your `tsconfig.json` matches SDK requirements
+
+### Python import errors
+
+**Issue**: Cannot import from `claude_agent_sdk`
+
+**Solution**:
+- Ensure you've installed dependencies: `pip install -r requirements.txt`
+- Activate your virtual environment if using one
+- Check that the SDK is installed: `pip show claude-agent-sdk`
+
+### Verification fails with warnings
+
+**Issue**: Verifier agent reports warnings
+
+**Solution**:
+- Review the specific warnings in the report
+- Check the SDK documentation references provided
+- Warnings don't prevent functionality but indicate areas for improvement
+
+## Author
+
+Ashwin Bhat (ashwin@anthropic.com)
+
+## Version
+
+1.0.0

plugins/agent-sdk-dev/agents/agent-sdk-verifier-py.md

@@ -0,0 +1,140 @@
+---
+name: agent-sdk-verifier-py
+description: Use this agent to verify that a Python Agent SDK application is properly configured, follows SDK best practices and documentation recommendations, and is ready for deployment or testing. This agent should be invoked after a Python Agent SDK app has been created or modified.
+model: sonnet
+---
+
+You are a Python Agent SDK application verifier. Your role is to thoroughly inspect Python Agent SDK applications for correct SDK usage, adherence to official documentation recommendations, and readiness for deployment.
+
+## Verification Focus
+
+Your verification should prioritize SDK functionality and best practices over general code style. Focus on:
+
+1. **SDK Installation and Configuration**:
+
+   - Verify `claude-agent-sdk` is installed (check requirements.txt, pyproject.toml, or pip list)
+   - Check that the SDK version is reasonably current (not ancient)
+   - Validate Python version requirements are met (typically Python 3.8+)
+   - Confirm virtual environment is recommended/documented if applicable
+
+2. **Python Environment Setup**:
+
+   - Check for requirements.txt or pyproject.toml
+   - Verify dependencies are properly specified
+   - Ensure Python version constraints are documented if needed
+   - Validate that the environment can be reproduced
+
+3. **SDK Usage and Patterns**:
+
+   - Verify correct imports from `claude_agent_sdk` (or appropriate SDK module)
+   - Check that agents are properly initialized according to SDK docs
+   - Validate that agent configuration follows SDK patterns (system prompts, models, etc.)
+   - Ensure SDK methods are called correctly with proper parameters
+   - Check for proper handling of agent responses (streaming vs single mode)
+   - Verify permissions are configured correctly if used
+   - Validate MCP server integration if present
+
+4. **Code Quality**:
+
+   - Check for basic syntax errors
+   - Verify imports are correct and available
+   - Ensure proper error handling
+   - Validate that the code structure makes sense for the SDK
+
+5. **Environment and Security**:
+
+   - Check that `.env.example` exists with `ANTHROPIC_API_KEY`
+   - Verify `.env` is in `.gitignore`
+   - Ensure API keys are not hardcoded in source files
+   - Validate proper error handling around API calls
+
+6. **SDK Best Practices** (based on official docs):
+
+   - System prompts are clear and well-structured
+   - Appropriate model selection for the use case
+   - Permissions are properly scoped if used
+   - Custom tools (MCP) are correctly integrated if present
+   - Subagents are properly configured if used
+   - Session handling is correct if applicable
+
+7. **Functionality Validation**:
+
+   - Verify the application structure makes sense for the SDK
+   - Check that agent initialization and execution flow is correct
+   - Ensure error handling covers SDK-specific errors
+   - Validate that the app follows SDK documentation patterns
+
+8. **Documentation**:
+   - Check for README or basic documentation
+   - Verify setup instructions are present (including virtual environment setup)
+   - Ensure any custom configurations are documented
+   - Confirm installation instructions are clear
+
+## What NOT to Focus On
+
+- General code style preferences (PEP 8 formatting, naming conventions, etc.)
+- Python-specific style choices (snake_case vs camelCase debates)
+- Import ordering preferences
+- General Python best practices unrelated to SDK usage
+
+## Verification Process
+
+1. **Read the relevant files**:
+
+   - requirements.txt or pyproject.toml
+   - Main application files (main.py, app.py, src/\*, etc.)
+   - .env.example and .gitignore
+   - Any configuration files
+
+2. **Check SDK Documentation Adherence**:
+
+   - Use WebFetch to reference the official Python SDK docs: https://docs.claude.com/en/api/agent-sdk/python
+   - Compare the implementation against official patterns and recommendations
+   - Note any deviations from documented best practices
+
+3. **Validate Imports and Syntax**:
+
+   - Check that all imports are correct
+   - Look for obvious syntax errors
+   - Verify SDK is properly imported
+
+4. **Analyze SDK Usage**:
+   - Verify SDK methods are used correctly
+   - Check that configuration options match SDK documentation
+   - Validate that patterns follow official examples
+
+## Verification Report Format
+
+Provide a comprehensive report:
+
+**Overall Status**: PASS | PASS WITH WARNINGS | FAIL
+
+**Summary**: Brief overview of findings
+
+**Critical Issues** (if any):
+
+- Issues that prevent the app from functioning
+- Security problems
+- SDK usage errors that will cause runtime failures
+- Syntax errors or import problems
+
+**Warnings** (if any):
+
+- Suboptimal SDK usage patterns
+- Missing SDK features that would improve the app
+- Deviations from SDK documentation recommendations
+- Missing documentation or setup instructions
+
+**Passed Checks**:
+
+- What is correctly configured
+- SDK features properly implemented
+- Security measures in place
+
+**Recommendations**:
+
+- Specific suggestions for improvement
+- References to SDK documentation
+- Next steps for enhancement
+
+Be thorough but constructive. Focus on helping the developer build a functional, secure, and well-configured Agent SDK application that follows official patterns.

plugins/agent-sdk-dev/agents/agent-sdk-verifier-ts.md

@@ -0,0 +1,145 @@
+---
+name: agent-sdk-verifier-ts
+description: Use this agent to verify that a TypeScript Agent SDK application is properly configured, follows SDK best practices and documentation recommendations, and is ready for deployment or testing. This agent should be invoked after a TypeScript Agent SDK app has been created or modified.
+model: sonnet
+---
+
+You are a TypeScript Agent SDK application verifier. Your role is to thoroughly inspect TypeScript Agent SDK applications for correct SDK usage, adherence to official documentation recommendations, and readiness for deployment.
+
+## Verification Focus
+
+Your verification should prioritize SDK functionality and best practices over general code style. Focus on:
+
+1. **SDK Installation and Configuration**:
+
+   - Verify `@anthropic-ai/claude-agent-sdk` is installed
+   - Check that the SDK version is reasonably current (not ancient)
+   - Confirm package.json has `"type": "module"` for ES modules support
+   - Validate that Node.js version requirements are met (check package.json engines field if present)
+
+2. **TypeScript Configuration**:
+
+   - Verify tsconfig.json exists and has appropriate settings for the SDK
+   - Check module resolution settings (should support ES modules)
+   - Ensure target is modern enough for the SDK
+   - Validate that compilation settings won't break SDK imports
+
+3. **SDK Usage and Patterns**:
+
+   - Verify correct imports from `@anthropic-ai/claude-agent-sdk`
+   - Check that agents are properly initialized according to SDK docs
+   - Validate that agent configuration follows SDK patterns (system prompts, models, etc.)
+   - Ensure SDK methods are called correctly with proper parameters
+   - Check for proper handling of agent responses (streaming vs single mode)
+   - Verify permissions are configured correctly if used
+   - Validate MCP server integration if present
+
+4. **Type Safety and Compilation**:
+
+   - Run `npx tsc --noEmit` to check for type errors
+   - Verify that all SDK imports have correct type definitions
+   - Ensure the code compiles without errors
+   - Check that types align with SDK documentation
+
+5. **Scripts and Build Configuration**:
+
+   - Verify package.json has necessary scripts (build, start, typecheck)
+   - Check that scripts are correctly configured for TypeScript/ES modules
+   - Validate that the application can be built and run
+
+6. **Environment and Security**:
+
+   - Check that `.env.example` exists with `ANTHROPIC_API_KEY`
+   - Verify `.env` is in `.gitignore`
+   - Ensure API keys are not hardcoded in source files
+   - Validate proper error handling around API calls
+
+7. **SDK Best Practices** (based on official docs):
+
+   - System prompts are clear and well-structured
+   - Appropriate model selection for the use case
+   - Permissions are properly scoped if used
+   - Custom tools (MCP) are correctly integrated if present
+   - Subagents are properly configured if used
+   - Session handling is correct if applicable
+
+8. **Functionality Validation**:
+
+   - Verify the application structure makes sense for the SDK
+   - Check that agent initialization and execution flow is correct
+   - Ensure error handling covers SDK-specific errors
+   - Validate that the app follows SDK documentation patterns
+
+9. **Documentation**:
+   - Check for README or basic documentation
+   - Verify setup instructions are present if needed
+   - Ensure any custom configurations are documented
+
+## What NOT to Focus On
+
+- General code style preferences (formatting, naming conventions, etc.)
+- Whether developers use `type` vs `interface` or other TypeScript style choices
+- Unused variable naming conventions
+- General TypeScript best practices unrelated to SDK usage
+
+## Verification Process
+
+1. **Read the relevant files**:
+
+   - package.json
+   - tsconfig.json
+   - Main application files (index.ts, src/\*, etc.)
+   - .env.example and .gitignore
+   - Any configuration files
+
+2. **Check SDK Documentation Adherence**:
+
+   - Use WebFetch to reference the official TypeScript SDK docs: https://docs.claude.com/en/api/agent-sdk/typescript
+   - Compare the implementation against official patterns and recommendations
+   - Note any deviations from documented best practices
+
+3. **Run Type Checking**:
+
+   - Execute `npx tsc --noEmit` to verify no type errors
+   - Report any compilation issues
+
+4. **Analyze SDK Usage**:
+   - Verify SDK methods are used correctly
+   - Check that configuration options match SDK documentation
+   - Validate that patterns follow official examples
+
+## Verification Report Format
+
+Provide a comprehensive report:
+
+**Overall Status**: PASS | PASS WITH WARNINGS | FAIL
+
+**Summary**: Brief overview of findings
+
+**Critical Issues** (if any):
+
+- Issues that prevent the app from functioning
+- Security problems
+- SDK usage errors that will cause runtime failures
+- Type errors or compilation failures
+
+**Warnings** (if any):
+
+- Suboptimal SDK usage patterns
+- Missing SDK features that would improve the app
+- Deviations from SDK documentation recommendations
+- Missing documentation
+
+**Passed Checks**:
+
+- What is correctly configured
+- SDK features properly implemented
+- Security measures in place
+
+**Recommendations**:
+
+- Specific suggestions for improvement
+- References to SDK documentation
+- Next steps for enhancement
+
+Be thorough but constructive. Focus on helping the developer build a functional, secure, and well-configured Agent SDK application that follows official patterns.

plugins/agent-sdk-dev/commands/new-sdk-app.md

@@ -0,0 +1,176 @@
+---
+description: Create and setup a new Claude Agent SDK application
+argument-hint: [project-name]
+---
+
+You are tasked with helping the user create a new Claude Agent SDK application. Follow these steps carefully:
+
+## Reference Documentation
+
+Before starting, review the official documentation to ensure you provide accurate and up-to-date guidance. Use WebFetch to read these pages:
+
+1. **Start with the overview**: https://docs.claude.com/en/api/agent-sdk/overview
+2. **Based on the user's language choice, read the appropriate SDK reference**:
+   - TypeScript: https://docs.claude.com/en/api/agent-sdk/typescript
+   - Python: https://docs.claude.com/en/api/agent-sdk/python
+3. **Read relevant guides mentioned in the overview** such as:
+   - Streaming vs Single Mode
+   - Permissions
+   - Custom Tools
+   - MCP integration
+   - Subagents
+   - Sessions
+   - Any other relevant guides based on the user's needs
+
+**IMPORTANT**: Always check for and use the latest versions of packages. Use WebSearch or WebFetch to verify current versions before installation.
+
+## Gather Requirements
+
+IMPORTANT: Ask these questions one at a time. Wait for the user's response before asking the next question. This makes it easier for the user to respond.
+
+Ask the questions in this order (skip any that the user has already provided via arguments):
+
+1. **Language** (ask first): "Would you like to use TypeScript or Python?"
+
+   - Wait for response before continuing
+
+2. **Project name** (ask second): "What would you like to name your project?"
+
+   - If $ARGUMENTS is provided, use that as the project name and skip this question
+   - Wait for response before continuing
+
+3. **Agent type** (ask third, but skip if #2 was sufficiently detailed): "What kind of agent are you building? Some examples:
+
+   - Coding agent (SRE, security review, code review)
+   - Business agent (customer support, content creation)
+   - Custom agent (describe your use case)"
+   - Wait for response before continuing
+
+4. **Starting point** (ask fourth): "Would you like:
+
+   - A minimal 'Hello World' example to start
+   - A basic agent with common features
+   - A specific example based on your use case"
+   - Wait for response before continuing
+
+5. **Tooling choice** (ask fifth): Let the user know what tools you'll use, and confirm with them that these are the tools they want to use (for example, they may prefer pnpm or bun over npm). Respect the user's preferences when executing on the requirements.
+
+After all questions are answered, proceed to create the setup plan.
+
+## Setup Plan
+
+Based on the user's answers, create a plan that includes:
+
+1. **Project initialization**:
+
+   - Create project directory (if it doesn't exist)
+   - Initialize package manager:
+     - TypeScript: `npm init -y` and setup `package.json` with type: "module" and scripts (include a "typecheck" script)
+     - Python: Create `requirements.txt` or use `poetry init`
+   - Add necessary configuration files:
+     - TypeScript: Create `tsconfig.json` with proper settings for the SDK
+     - Python: Optionally create config files if needed
+
+2. **Check for Latest Versions**:
+
+   - BEFORE installing, use WebSearch or check npm/PyPI to find the latest version
+   - For TypeScript: Check https://www.npmjs.com/package/@anthropic-ai/claude-agent-sdk
+   - For Python: Check https://pypi.org/project/claude-agent-sdk/
+   - Inform the user which version you're installing
+
+3. **SDK Installation**:
+
+   - TypeScript: `npm install @anthropic-ai/claude-agent-sdk@latest` (or specify latest version)
+   - Python: `pip install claude-agent-sdk` (pip installs latest by default)
+   - After installation, verify the installed version:
+     - TypeScript: Check package.json or run `npm list @anthropic-ai/claude-agent-sdk`
+     - Python: Run `pip show claude-agent-sdk`
+
+4. **Create starter files**:
+
+   - TypeScript: Create an `index.ts` or `src/index.ts` with a basic query example
+   - Python: Create a `main.py` with a basic query example
+   - Include proper imports and basic error handling
+   - Use modern, up-to-date syntax and patterns from the latest SDK version
+
+5. **Environment setup**:
+
+   - Create a `.env.example` file with `ANTHROPIC_API_KEY=your_api_key_here`
+   - Add `.env` to `.gitignore`
+   - Explain how to get an API key from https://console.anthropic.com/
+
+6. **Optional: Create .claude directory structure**:
+   - Offer to create `.claude/` directory for agents, commands, and settings
+   - Ask if they want any example subagents or slash commands
+
+## Implementation
+
+After gathering requirements and getting user confirmation on the plan:
+
+1. Check for latest package versions using WebSearch or WebFetch
+2. Execute the setup steps
+3. Create all necessary files
+4. Install dependencies (always use latest stable versions)
+5. Verify installed versions and inform the user
+6. Create a working example based on their agent type
+7. Add helpful comments in the code explaining what each part does
+8. **VERIFY THE CODE WORKS BEFORE FINISHING**:
+   - For TypeScript:
+     - Run `npx tsc --noEmit` to check for type errors
+     - Fix ALL type errors until types pass completely
+     - Ensure imports and types are correct
+     - Only proceed when type checking passes with no errors
+   - For Python:
+     - Verify imports are correct
+     - Check for basic syntax errors
+   - **DO NOT consider the setup complete until the code verifies successfully**
+
+## Verification
+
+After all files are created and dependencies are installed, use the appropriate verifier agent to validate that the Agent SDK application is properly configured and ready for use:
+
+1. **For TypeScript projects**: Launch the **agent-sdk-verifier-ts** agent to validate the setup
+2. **For Python projects**: Launch the **agent-sdk-verifier-py** agent to validate the setup
+3. The agent will check SDK usage, configuration, functionality, and adherence to official documentation
+4. Review the verification report and address any issues
+
+## Getting Started Guide
+
+Once setup is complete and verified, provide the user with:
+
+1. **Next steps**:
+
+   - How to set their API key
+   - How to run their agent:
+     - TypeScript: `npm start` or `node --loader ts-node/esm index.ts`
+     - Python: `python main.py`
+
+2. **Useful resources**:
+
+   - Link to TypeScript SDK reference: https://docs.claude.com/en/api/agent-sdk/typescript
+   - Link to Python SDK reference: https://docs.claude.com/en/api/agent-sdk/python
+   - Explain key concepts: system prompts, permissions, tools, MCP servers
+
+3. **Common next steps**:
+   - How to customize the system prompt
+   - How to add custom tools via MCP
+   - How to configure permissions
+   - How to create subagents
+
+## Important Notes
+
+- **ALWAYS USE LATEST VERSIONS**: Before installing any packages, check for the latest versions using WebSearch or by checking npm/PyPI directly
+- **VERIFY CODE RUNS CORRECTLY**:
+  - For TypeScript: Run `npx tsc --noEmit` and fix ALL type errors before finishing
+  - For Python: Verify syntax and imports are correct
+  - Do NOT consider the task complete until the code passes verification
+- Verify the installed version after installation and inform the user
+- Check the official documentation for any version-specific requirements (Node.js version, Python version, etc.)
+- Always check if directories/files already exist before creating them
+- Use the user's preferred package manager (npm, yarn, pnpm for TypeScript; pip, poetry for Python)
+- Ensure all code examples are functional and include proper error handling
+- Use modern syntax and patterns that are compatible with the latest SDK version
+- Make the experience interactive and educational
+- **ASK QUESTIONS ONE AT A TIME** - Do not ask multiple questions in a single response
+
+Begin by asking the FIRST requirement question only. Wait for the user's answer before proceeding to the next question.

plugins/code-review/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "code-review",
+  "description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring",
+  "version": "1.0.0",
+  "author": {
+    "name": "Boris Cherny",
+    "email": "boris@anthropic.com"
+  }
+}
+

plugins/code-review/README.md

@@ -0,0 +1,246 @@
+# Code Review Plugin
+
+Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives.
+
+## Overview
+
+The Code Review Plugin automates pull request review by launching multiple agents in parallel to independently audit changes from different perspectives. It uses confidence scoring to filter out false positives, ensuring only high-quality, actionable feedback is posted.
+
+## Commands
+
+### `/code-review`
+
+Performs automated code review on a pull request using multiple specialized agents.
+
+**What it does:**
+1. Checks if review is needed (skips closed, draft, trivial, or already-reviewed PRs)
+2. Gathers relevant CLAUDE.md guideline files from the repository
+3. Summarizes the pull request changes
+4. Launches 4 parallel agents to independently review:
+   - **Agents #1 & #2**: Audit for CLAUDE.md compliance
+   - **Agent #3**: Scan for obvious bugs in changes
+   - **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
+
+**Usage:**
+```bash
+/code-review
+```
+
+**Example workflow:**
+```bash
+# On a PR branch, run:
+/code-review
+
+# 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
+```
+
+**Features:**
+- Multiple independent agents for comprehensive review
+- Confidence-based scoring reduces false positives (threshold: 80)
+- CLAUDE.md compliance checking with explicit guideline verification
+- Bug detection focused on changes (not pre-existing issues)
+- Historical context analysis via git blame
+- Automatic skipping of closed, draft, or already-reviewed PRs
+- Links directly to code with full SHA and line ranges
+
+**Review comment format:**
+```markdown
+## Code review
+
+Found 3 issues:
+
+1. Missing error handling for OAuth callback (CLAUDE.md says "Always handle OAuth errors")
+
+https://github.com/owner/repo/blob/abc123.../src/auth.ts#L67-L72
+
+2. Memory leak: OAuth state not cleaned up (bug due to missing cleanup in finally block)
+
+https://github.com/owner/repo/blob/abc123.../src/auth.ts#L88-L95
+
+3. Inconsistent naming pattern (src/conventions/CLAUDE.md says "Use camelCase for functions")
+
+https://github.com/owner/repo/blob/abc123.../src/utils.ts#L23-L28
+```
+
+**Confidence scoring:**
+- **0**: Not confident, false positive
+- **25**: Somewhat confident, might be real
+- **50**: Moderately confident, real but minor
+- **75**: Highly confident, real and important
+- **100**: Absolutely certain, definitely real
+
+**False positives filtered:**
+- Pre-existing issues not introduced in PR
+- Code that looks like a bug but isn't
+- Pedantic nitpicks
+- Issues linters will catch
+- General quality issues (unless in CLAUDE.md)
+- Issues with lint ignore comments
+
+## Installation
+
+This plugin is included in the Claude Code repository. The command is automatically available when using Claude Code.
+
+## Best Practices
+
+### Using `/code-review`
+- Maintain clear CLAUDE.md files for better compliance checking
+- Trust the 80+ confidence threshold - false positives are filtered
+- Run on all non-trivial pull requests
+- Review agent findings as a starting point for human review
+- Update CLAUDE.md based on recurring review patterns
+
+### When to use
+- All pull requests with meaningful changes
+- PRs touching critical code paths
+- PRs from multiple contributors
+- PRs where guideline compliance matters
+
+### When not to use
+- Closed or draft PRs (automatically skipped anyway)
+- Trivial automated PRs (automatically skipped)
+- Urgent hotfixes requiring immediate merge
+- PRs already reviewed (automatically skipped)
+
+## Workflow Integration
+
+### Standard PR review workflow:
+```bash
+# Create PR with changes
+/code-review
+
+# Review the automated feedback
+# Make any necessary fixes
+# Merge when ready
+```
+
+### As part of CI/CD:
+```bash
+# Trigger on PR creation or update
+# Automatically posts review comments
+# Skip if review already exists
+```
+
+## Requirements
+
+- Git repository with GitHub integration
+- GitHub CLI (`gh`) installed and authenticated
+- CLAUDE.md files (optional but recommended for guideline checking)
+
+## Troubleshooting
+
+### Review takes too long
+
+**Issue**: Agents are slow on large PRs
+
+**Solution**:
+- Normal for large changes - agents run in parallel
+- 4 independent agents ensure thoroughness
+- Consider splitting large PRs into smaller ones
+
+### Too many false positives
+
+**Issue**: Review flags issues that aren't real
+
+**Solution**:
+- Default threshold is 80 (already filters most false positives)
+- Make CLAUDE.md more specific about what matters
+- Consider if the flagged issue is actually valid
+
+### No review comment posted
+
+**Issue**: `/code-review` runs but no comment appears
+
+**Solution**:
+Check if:
+- PR is closed (reviews skipped)
+- PR is draft (reviews skipped)
+- PR is trivial/automated (reviews skipped)
+- PR already has review (reviews skipped)
+- No issues scored ≥80 (no comment needed)
+
+### Link formatting broken
+
+**Issue**: Code links don't render correctly in GitHub
+
+**Solution**:
+Links must follow this exact format:
+```
+https://github.com/owner/repo/blob/[full-sha]/path/file.ext#L[start]-L[end]
+```
+- Must use full SHA (not abbreviated)
+- Must use `#L` notation
+- Must include line range with at least 1 line of context
+
+### GitHub CLI not working
+
+**Issue**: `gh` commands fail
+
+**Solution**:
+- Install GitHub CLI: `brew install gh` (macOS) or see [GitHub CLI installation](https://cli.github.com/)
+- Authenticate: `gh auth login`
+- Verify repository has GitHub remote
+
+## Tips
+
+- **Write specific CLAUDE.md files**: Clear guidelines = better reviews
+- **Include context in PRs**: Helps agents understand intent
+- **Use confidence scores**: Issues ≥80 are usually correct
+- **Iterate on guidelines**: Update CLAUDE.md based on patterns
+- **Review automatically**: Set up as part of PR workflow
+- **Trust the filtering**: Threshold prevents noise
+
+## Configuration
+
+### Adjusting confidence threshold
+
+The default threshold is 80. To adjust, modify the command file at `commands/code-review.md`:
+```markdown
+Filter out any issues with a score less than 80.
+```
+
+Change `80` to your preferred threshold (0-100).
+
+### Customizing review focus
+
+Edit `commands/code-review.md` to add or modify agent tasks:
+- Add security-focused agents
+- Add performance analysis agents
+- Add accessibility checking agents
+- Add documentation quality checks
+
+## Technical Details
+
+### Agent architecture
+- **2x CLAUDE.md compliance agents**: Redundancy for guideline checks
+- **1x bug detector**: Focused on obvious bugs in changes only
+- **1x history analyzer**: Context from git blame and history
+- **Nx confidence scorers**: One per issue for independent scoring
+
+### Scoring system
+- Each issue independently scored 0-100
+- Scoring considers evidence strength and verification
+- Threshold (default 80) filters low-confidence issues
+- For CLAUDE.md issues: verifies guideline explicitly mentions it
+
+### GitHub integration
+Uses `gh` CLI for:
+- Viewing PR details and diffs
+- Fetching repository data
+- Reading git blame and history
+- Posting review comments
+
+## Author
+
+Boris Cherny (boris@anthropic.com)
+
+## Version
+
+1.0.0

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

@@ -0,0 +1,84 @@
+---
+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 review:*), Bash(gh pr list:*)
+description: Code review a pull request
+---
+
+Provide a code review for the given pull request.
+
+To do this, follow these steps precisely:
+
+1. Use an 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 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 an agent to view the pull request, and ask the agent to return a summary of the change
+4. Then, launch 4 parallel 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. Agents #1 and #2: Independently audit the changes to make sure they compily with the CLAUDE.md
+   b. Agent #3: 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 #5: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
+5. For each issue found in #4, launch a parallel 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. Finally, comment back on the pull request with a list of issues you found. 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
+
+Examples of false positives, for steps 4 and 5:
+
+- 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 will catch (no need to run the linter to verify)
+- General code quality issues (eg. lack of test coverage, general security issues), 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)
+
+Notes:
+
+- 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 comment, follow the following format precisely (assuming for this example that you found 3 issues):
+
+---
+
+## 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, 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:
+
+---
+
+## Auto 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
+  - Requires full git sha
+  - Repo name must match the repo you're code reviewing
+  - # sign after the file name
+  - Line range format is L[start]-L[end]
+  - Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to `L4-7`)

plugins/commit-commands/.claude-plugin/plugin.json

@@ -0,0 +1,10 @@
+{
+  "name": "commit-commands",
+  "description": "Streamline your git workflow with simple commands for committing, pushing, and creating pull requests",
+  "version": "1.0.0",
+  "author": {
+    "name": "Anthropic",
+    "email": "support@anthropic.com"
+  }
+}
+

plugins/commit-commands/README.md

@@ -0,0 +1,225 @@
+# Commit Commands Plugin
+
+Streamline your git workflow with simple commands for committing, pushing, and creating pull requests.
+
+## Overview
+
+The Commit Commands Plugin automates common git operations, reducing context switching and manual command execution. Instead of running multiple git commands, use a single slash command to handle your entire workflow.
+
+## Commands
+
+### `/commit`
+
+Creates a git commit with an automatically generated commit message based on staged and unstaged changes.
+
+**What it does:**
+1. Analyzes current git status
+2. Reviews both staged and unstaged changes
+3. Examines recent commit messages to match your repository's style
+4. Drafts an appropriate commit message
+5. Stages relevant files
+6. Creates the commit
+
+**Usage:**
+```bash
+/commit
+```
+
+**Example workflow:**
+```bash
+# Make some changes to your code
+# Then simply run:
+/commit
+
+# Claude will:
+# - Review your changes
+# - Stage the files
+# - Create a commit with an appropriate message
+# - Show you the commit status
+```
+
+**Features:**
+- Automatically drafts commit messages that match your repo's style
+- Follows conventional commit practices
+- Avoids committing files with secrets (.env, credentials.json)
+- Includes Claude Code attribution in commit message
+
+### `/commit-push-pr`
+
+Complete workflow command that commits, pushes, and creates a pull request in one step.
+
+**What it does:**
+1. Creates a new branch (if currently on main)
+2. Stages and commits changes with an appropriate message
+3. Pushes the branch to origin
+4. Creates a pull request using `gh pr create`
+5. Provides the PR URL
+
+**Usage:**
+```bash
+/commit-push-pr
+```
+
+**Example workflow:**
+```bash
+# Make your changes
+# Then run:
+/commit-push-pr
+
+# Claude will:
+# - Create a feature branch (if needed)
+# - Commit your changes
+# - Push to remote
+# - Open a PR with summary and test plan
+# - Give you the PR URL to review
+```
+
+**Features:**
+- Analyzes all commits in the branch (not just the latest)
+- Creates comprehensive PR descriptions with:
+  - Summary of changes (1-3 bullet points)
+  - Test plan checklist
+  - Claude Code attribution
+- Handles branch creation automatically
+- Uses GitHub CLI (`gh`) for PR creation
+
+**Requirements:**
+- GitHub CLI (`gh`) must be installed and authenticated
+- Repository must have a remote named `origin`
+
+### `/clean_gone`
+
+Cleans up local branches that have been deleted from the remote repository.
+
+**What it does:**
+1. Lists all local branches to identify [gone] status
+2. Identifies and removes worktrees associated with [gone] branches
+3. Deletes all branches marked as [gone]
+4. Provides feedback on removed branches
+
+**Usage:**
+```bash
+/clean_gone
+```
+
+**Example workflow:**
+```bash
+# After PRs are merged and remote branches are deleted
+/clean_gone
+
+# Claude will:
+# - Find all branches marked as [gone]
+# - Remove any associated worktrees
+# - Delete the stale local branches
+# - Report what was cleaned up
+```
+
+**Features:**
+- Handles both regular branches and worktree branches
+- Safely removes worktrees before deleting branches
+- Shows clear feedback about what was removed
+- Reports if no cleanup was needed
+
+**When to use:**
+- After merging and deleting remote branches
+- When your local branch list is cluttered with stale branches
+- During regular repository maintenance
+
+## Installation
+
+This plugin is included in the Claude Code repository. The commands are automatically available when using Claude Code.
+
+## Best Practices
+
+### Using `/commit`
+- Review the staged changes before committing
+- Let Claude analyze your changes and match your repo's commit style
+- Trust the automated message, but verify it's accurate
+- Use for routine commits during development
+
+### Using `/commit-push-pr`
+- Use when you're ready to create a PR
+- Ensure all your changes are complete and tested
+- Claude will analyze the full branch history for the PR description
+- Review the PR description and edit if needed
+- Use when you want to minimize context switching
+
+### Using `/clean_gone`
+- Run periodically to keep your branch list clean
+- Especially useful after merging multiple PRs
+- Safe to run - only removes branches already deleted remotely
+- Helps maintain a tidy local repository
+
+## Workflow Integration
+
+### Quick commit workflow:
+```bash
+# Write code
+/commit
+# Continue development
+```
+
+### Feature branch workflow:
+```bash
+# Develop feature across multiple commits
+/commit  # First commit
+# More changes
+/commit  # Second commit
+# Ready to create PR
+/commit-push-pr
+```
+
+### Maintenance workflow:
+```bash
+# After several PRs are merged
+/clean_gone
+# Clean workspace ready for next feature
+```
+
+## Requirements
+
+- Git must be installed and configured
+- For `/commit-push-pr`: GitHub CLI (`gh`) must be installed and authenticated
+- Repository must be a git repository with a remote
+
+## Troubleshooting
+
+### `/commit` creates empty commit
+
+**Issue**: No changes to commit
+
+**Solution**:
+- Ensure you have unstaged or staged changes
+- Run `git status` to verify changes exist
+
+### `/commit-push-pr` fails to create PR
+
+**Issue**: `gh pr create` command fails
+
+**Solution**:
+- Install GitHub CLI: `brew install gh` (macOS) or see [GitHub CLI installation](https://cli.github.com/)
+- Authenticate: `gh auth login`
+- Ensure repository has a GitHub remote
+
+### `/clean_gone` doesn't find branches
+
+**Issue**: No branches marked as [gone]
+
+**Solution**:
+- Run `git fetch --prune` to update remote tracking
+- Branches must be deleted from the remote to show as [gone]
+
+## Tips
+
+- **Combine with other tools**: Use `/commit` during development, then `/commit-push-pr` when ready
+- **Let Claude draft messages**: The commit message analysis learns from your repo's style
+- **Regular cleanup**: Run `/clean_gone` weekly to maintain a clean branch list
+- **Review before pushing**: Always review the commit message and changes before pushing
+
+## Author
+
+Anthropic (support@anthropic.com)
+
+## Version
+
+1.0.0

plugins/commit-commands/commands/clean_gone.md

@@ -0,0 +1,53 @@
+---
+description: Cleans up all git branches marked as [gone] (branches that have been deleted on the remote but still exist locally), including removing associated worktrees.
+---
+
+## Your Task
+
+You need to execute the following bash commands to clean up stale local branches that have been deleted from the remote repository.
+
+## Commands to Execute
+
+1. **First, list branches to identify any with [gone] status**
+   Execute this command:
+   ```bash
+   git branch -v
+   ```
+   
+   Note: Branches with a '+' prefix have associated worktrees and must have their worktrees removed before deletion.
+
+2. **Next, identify worktrees that need to be removed for [gone] branches**
+   Execute this command:
+   ```bash
+   git worktree list
+   ```
+
+3. **Finally, remove worktrees and delete [gone] branches (handles both regular and worktree branches)**
+   Execute this command:
+   ```bash
+   # Process all [gone] branches, removing '+' prefix if present
+   git branch -v | grep '\[gone\]' | sed 's/^[+* ]//' | awk '{print $1}' | while read branch; do
+     echo "Processing branch: $branch"
+     # Find and remove worktree if it exists
+     worktree=$(git worktree list | grep "\\[$branch\\]" | awk '{print $1}')
+     if [ ! -z "$worktree" ] && [ "$worktree" != "$(git rev-parse --show-toplevel)" ]; then
+       echo "  Removing worktree: $worktree"
+       git worktree remove --force "$worktree"
+     fi
+     # Delete the branch
+     echo "  Deleting branch: $branch"
+     git branch -D "$branch"
+   done
+   ```
+
+## Expected Behavior
+
+After executing these commands, you will:
+
+- See a list of all local branches with their status
+- Identify and remove any worktrees associated with [gone] branches
+- Delete all branches marked as [gone]
+- Provide feedback on which worktrees and branches were removed
+
+If no branches are marked as [gone], report that no cleanup was needed.
+

plugins/commit-commands/commands/commit-push-pr.md

@@ -0,0 +1,20 @@
+---
+allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr create:*)
+description: Commit, push, and open a PR
+---
+
+## Context
+
+- Current git status: !`git status`
+- Current git diff (staged and unstaged changes): !`git diff HEAD`
+- Current branch: !`git branch --show-current`
+
+## Your task
+
+Based on the above changes:
+
+1. Create a new branch if on main
+2. Create a single commit with an appropriate message
+3. Push the branch to origin
+4. Create a pull request using `gh pr create`
+5. You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.

plugins/commit-commands/commands/commit.md

@@ -0,0 +1,17 @@
+---
+allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
+description: Create a git commit
+---
+
+## Context
+
+- Current git status: !`git status`
+- Current git diff (staged and unstaged changes): !`git diff HEAD`
+- Current branch: !`git branch --show-current`
+- Recent commits: !`git log --oneline -10`
+
+## Your task
+
+Based on the above changes, create a single git commit.
+
+You have the capability to call multiple tools in a single response. Stage and create the commit using a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.

plugins/explanatory-output-style/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "explanatory-output-style",
+  "version": "1.0.0",
+  "description": "Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style)",
+  "author": {
+    "name": "Dickson Tsai",
+    "email": "dickson@anthropic.com"
+  }
+}

plugins/explanatory-output-style/README.md

@@ -0,0 +1,72 @@
+# Explanatory Output Style Plugin
+
+This plugin recreates the deprecated Explanatory output style as a SessionStart
+hook.
+
+WARNING: Do not install this plugin unless you are fine with incurring the token
+cost of this plugin's additional instructions and output.
+
+## What it does
+
+When enabled, this plugin automatically adds instructions at the start of each
+session that encourage Claude to:
+
+1. Provide educational insights about implementation choices
+2. Explain codebase patterns and decisions
+3. Balance task completion with learning opportunities
+
+## How it works
+
+The plugin uses a SessionStart hook to inject additional context into every
+session. This context instructs Claude to provide brief educational explanations
+before and after writing code, formatted as:
+
+```
+`★ Insight ─────────────────────────────────────`
+[2-3 key educational points]
+`─────────────────────────────────────────────────`
+```
+
+## Usage
+
+Once installed, the plugin activates automatically at the start of every
+session. No additional configuration is needed.
+
+The insights focus on:
+
+- Specific implementation choices for your codebase
+- Patterns and conventions in your code
+- Trade-offs and design decisions
+- Codebase-specific details rather than general programming concepts
+
+## Migration from Output Styles
+
+This plugin replaces the deprecated "Explanatory" output style setting. If you
+previously used:
+
+```json
+{
+  "outputStyle": "Explanatory"
+}
+```
+
+You can now achieve the same behavior by installing this plugin instead.
+
+More generally, this SessionStart hook pattern is roughly equivalent to
+CLAUDE.md, but it is more flexible and allows for distribution through plugins.
+
+Note: Output styles that involve tasks besides software development, are better
+expressed as
+[subagents](https://docs.claude.com/en/docs/claude-code/sub-agents), not as
+SessionStart hooks. Subagents change the system prompt while SessionStart hooks
+add to the default system prompt.
+
+## Managing changes
+
+- Disable the plugin - keep the code installed on your device
+- Uninstall the plugin - remove the code from your device
+- Update the plugin - create a local copy of this plugin to personalize this
+  plugin
+  - Hint: Ask Claude to read
+    https://docs.claude.com/en/docs/claude-code/plugins.md and set it up for
+    you!

plugins/explanatory-output-style/hooks-handlers/session-start.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+
+# Output the explanatory mode instructions as additionalContext
+# This mimics the deprecated Explanatory output style
+
+cat << 'EOF'
+{
+  "hookSpecificOutput": {
+    "hookEventName": "SessionStart",
+    "additionalContext": "You are in 'explanatory' output style mode, where you should provide educational insights about the codebase as you help with the user's task.\n\nYou should be clear and educational, providing helpful explanations while remaining focused on the task. Balance educational content with task completion. When providing insights, you may exceed typical length constraints, but remain focused and relevant.\n\n## Insights\nIn order to encourage learning, before and after writing code, always provide brief educational explanations about implementation choices using (with backticks):\n\"`★ Insight ─────────────────────────────────────`\n[2-3 key educational points]\n`─────────────────────────────────────────────────`\"\n\nThese insights should be included in the conversation, not in the codebase. You should generally focus on interesting insights that are specific to the codebase or the code you just wrote, rather than general programming concepts. Do not wait until the end to provide insights. Provide them as you write code."
+  }
+}
+EOF
+
+exit 0

plugins/explanatory-output-style/hooks/hooks.json

@@ -0,0 +1,15 @@
+{
+  "description": "Explanatory mode hook that adds educational insights instructions",
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks-handlers/session-start.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

plugins/feature-dev/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "feature-dev",
+  "version": "1.0.0",
+  "description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
+  "author": {
+    "name": "Sid Bidasaria",
+    "email": "sbidasaria@anthropic.com"
+  }
+}

plugins/feature-dev/README.md

@@ -0,0 +1,412 @@
+# Feature Development Plugin
+
+A comprehensive, structured workflow for feature development with specialized agents for codebase exploration, architecture design, and quality review.
+
+## Overview
+
+The Feature Development Plugin provides a systematic 7-phase approach to building new features. Instead of jumping straight into code, it guides you through understanding the codebase, asking clarifying questions, designing architecture, and ensuring quality—resulting in better-designed features that integrate seamlessly with your existing code.
+
+## Philosophy
+
+Building features requires more than just writing code. You need to:
+- **Understand the codebase** before making changes
+- **Ask questions** to clarify ambiguous requirements
+- **Design thoughtfully** before implementing
+- **Review for quality** after building
+
+This plugin embeds these practices into a structured workflow that runs automatically when you use the `/feature-dev` command.
+
+## Command: `/feature-dev`
+
+Launches a guided feature development workflow with 7 distinct phases.
+
+**Usage:**
+```bash
+/feature-dev Add user authentication with OAuth
+```
+
+Or simply:
+```bash
+/feature-dev
+```
+
+The command will guide you through the entire process interactively.
+
+## The 7-Phase Workflow
+
+### Phase 1: Discovery
+
+**Goal**: Understand what needs to be built
+
+**What happens:**
+- Clarifies the feature request if it's unclear
+- Asks what problem you're solving
+- Identifies constraints and requirements
+- Summarizes understanding and confirms with you
+
+**Example:**
+```
+You: /feature-dev Add caching
+Claude: Let me understand what you need...
+        - What should be cached? (API responses, computed values, etc.)
+        - What are your performance requirements?
+        - Do you have a preferred caching solution?
+```
+
+### Phase 2: Codebase Exploration
+
+**Goal**: Understand relevant existing code and patterns
+
+**What happens:**
+- Launches 2-3 `code-explorer` agents in parallel
+- Each agent explores different aspects (similar features, architecture, UI patterns)
+- Agents return comprehensive analyses with key files to read
+- Claude reads all identified files to build deep understanding
+- Presents comprehensive summary of findings
+
+**Agents launched:**
+- "Find features similar to [feature] and trace implementation"
+- "Map the architecture and abstractions for [area]"
+- "Analyze current implementation of [related feature]"
+
+**Example output:**
+```
+Found similar features:
+- User authentication (src/auth/): Uses JWT tokens, middleware pattern
+- Session management (src/session/): Redis-backed, 24hr expiry
+- API security (src/api/middleware/): Rate limiting, CORS
+
+Key files to understand:
+- src/auth/AuthService.ts:45 - Core authentication logic
+- src/middleware/authMiddleware.ts:12 - Request authentication
+- src/config/security.ts:8 - Security configuration
+```
+
+### Phase 3: Clarifying Questions
+
+**Goal**: Fill in gaps and resolve all ambiguities
+
+**What happens:**
+- Reviews codebase findings and feature request
+- Identifies underspecified aspects:
+  - Edge cases
+  - Error handling
+  - Integration points
+  - Backward compatibility
+  - Performance needs
+- Presents all questions in an organized list
+- **Waits for your answers before proceeding**
+
+**Example:**
+```
+Before designing the architecture, I need to clarify:
+
+1. OAuth provider: Which OAuth providers? (Google, GitHub, custom?)
+2. User data: Store OAuth tokens or just user profile?
+3. Existing auth: Replace current auth or add alongside?
+4. Sessions: Integrate with existing session management?
+5. Error handling: How to handle OAuth failures?
+```
+
+**Critical**: This phase ensures nothing is ambiguous before design begins.
+
+### Phase 4: Architecture Design
+
+**Goal**: Design multiple implementation approaches
+
+**What happens:**
+- Launches 2-3 `code-architect` agents with different focuses:
+  - **Minimal changes**: Smallest change, maximum reuse
+  - **Clean architecture**: Maintainability, elegant abstractions
+  - **Pragmatic balance**: Speed + quality
+- Reviews all approaches
+- Forms opinion on which fits best for this task
+- Presents comparison with trade-offs and recommendation
+- **Asks which approach you prefer**
+
+**Example output:**
+```
+I've designed 3 approaches:
+
+Approach 1: Minimal Changes
+- Extend existing AuthService with OAuth methods
+- Add new OAuth routes to existing auth router
+- Minimal refactoring required
+Pros: Fast, low risk
+Cons: Couples OAuth to existing auth, harder to test
+
+Approach 2: Clean Architecture
+- New OAuthService with dedicated interface
+- Separate OAuth router and middleware
+- Refactor AuthService to use common interface
+Pros: Clean separation, testable, maintainable
+Cons: More files, more refactoring
+
+Approach 3: Pragmatic Balance
+- New OAuthProvider abstraction
+- Integrate into existing AuthService
+- Minimal refactoring, good boundaries
+Pros: Balanced complexity and cleanliness
+Cons: Some coupling remains
+
+Recommendation: Approach 3 - gives you clean boundaries without
+excessive refactoring, and fits your existing architecture well.
+
+Which approach would you like to use?
+```
+
+### Phase 5: Implementation
+
+**Goal**: Build the feature
+
+**What happens:**
+- **Waits for explicit approval** before starting
+- Reads all relevant files identified in previous phases
+- Implements following chosen architecture
+- Follows codebase conventions strictly
+- Writes clean, well-documented code
+- Updates todos as progress is made
+
+**Notes:**
+- Implementation only starts after you approve
+- Follows patterns discovered in Phase 2
+- Uses architecture designed in Phase 4
+- Continuously tracks progress
+
+### Phase 6: Quality Review
+
+**Goal**: Ensure code is simple, DRY, elegant, and functionally correct
+
+**What happens:**
+- Launches 3 `code-reviewer` agents in parallel with different focuses:
+  - **Simplicity/DRY/Elegance**: Code quality and maintainability
+  - **Bugs/Correctness**: Functional correctness and logic errors
+  - **Conventions/Abstractions**: Project standards and patterns
+- Consolidates findings
+- Identifies highest severity issues
+- **Presents findings and asks what you want to do**:
+  - Fix now
+  - Fix later
+  - Proceed as-is
+- Addresses issues based on your decision
+
+**Example output:**
+```
+Code Review Results:
+
+High Priority Issues:
+1. Missing error handling in OAuth callback (src/auth/oauth.ts:67)
+2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89)
+
+Medium Priority:
+1. Could simplify token refresh logic (src/auth/oauth.ts:120)
+2. Consider extracting OAuth config validation
+
+All tests pass. Code follows project conventions.
+
+What would you like to do?
+```
+
+### Phase 7: Summary
+
+**Goal**: Document what was accomplished
+
+**What happens:**
+- Marks all todos complete
+- Summarizes:
+  - What was built
+  - Key decisions made
+  - Files modified
+  - Suggested next steps
+
+**Example:**
+```
+Feature Complete: OAuth Authentication
+
+What was built:
+- OAuth provider abstraction supporting Google and GitHub
+- OAuth routes and middleware integrated with existing auth
+- Token refresh and session integration
+- Error handling for all OAuth flows
+
+Key decisions:
+- Used pragmatic approach with OAuthProvider abstraction
+- Integrated with existing session management
+- Added OAuth state to prevent CSRF
+
+Files modified:
+- src/auth/OAuthProvider.ts (new)
+- src/auth/AuthService.ts
+- src/routes/auth.ts
+- src/middleware/authMiddleware.ts
+
+Suggested next steps:
+- Add tests for OAuth flows
+- Add more OAuth providers (Microsoft, Apple)
+- Update documentation
+```
+
+## Agents
+
+### `code-explorer`
+
+**Purpose**: Deeply analyzes existing codebase features by tracing execution paths
+
+**Focus areas:**
+- Entry points and call chains
+- Data flow and transformations
+- Architecture layers and patterns
+- Dependencies and integrations
+- Implementation details
+
+**When triggered:**
+- Automatically in Phase 2
+- Can be invoked manually when exploring code
+
+**Output:**
+- Entry points with file:line references
+- Step-by-step execution flow
+- Key components and responsibilities
+- Architecture insights
+- List of essential files to read
+
+### `code-architect`
+
+**Purpose**: Designs feature architectures and implementation blueprints
+
+**Focus areas:**
+- Codebase pattern analysis
+- Architecture decisions
+- Component design
+- Implementation roadmap
+- Data flow and build sequence
+
+**When triggered:**
+- Automatically in Phase 4
+- Can be invoked manually for architecture design
+
+**Output:**
+- Patterns and conventions found
+- Architecture decision with rationale
+- Complete component design
+- Implementation map with specific files
+- Build sequence with phases
+
+### `code-reviewer`
+
+**Purpose**: Reviews code for bugs, quality issues, and project conventions
+
+**Focus areas:**
+- Project guideline compliance (CLAUDE.md)
+- Bug detection
+- Code quality issues
+- Confidence-based filtering (only reports high-confidence issues ≥80)
+
+**When triggered:**
+- Automatically in Phase 6
+- Can be invoked manually after writing code
+
+**Output:**
+- Critical issues (confidence 75-100)
+- Important issues (confidence 50-74)
+- Specific fixes with file:line references
+- Project guideline references
+
+## Usage Patterns
+
+### Full workflow (recommended for new features):
+```bash
+/feature-dev Add rate limiting to API endpoints
+```
+
+Let the workflow guide you through all 7 phases.
+
+### Manual agent invocation:
+
+**Explore a feature:**
+```
+"Launch code-explorer to trace how authentication works"
+```
+
+**Design architecture:**
+```
+"Launch code-architect to design the caching layer"
+```
+
+**Review code:**
+```
+"Launch code-reviewer to check my recent changes"
+```
+
+## Best Practices
+
+1. **Use the full workflow for complex features**: The 7 phases ensure thorough planning
+2. **Answer clarifying questions thoughtfully**: Phase 3 prevents future confusion
+3. **Choose architecture deliberately**: Phase 4 gives you options for a reason
+4. **Don't skip code review**: Phase 6 catches issues before they reach production
+5. **Read the suggested files**: Phase 2 identifies key files—read them to understand context
+
+## When to Use This Plugin
+
+**Use for:**
+- New features that touch multiple files
+- Features requiring architectural decisions
+- Complex integrations with existing code
+- Features where requirements are somewhat unclear
+
+**Don't use for:**
+- Single-line bug fixes
+- Trivial changes
+- Well-defined, simple tasks
+- Urgent hotfixes
+
+## Requirements
+
+- Claude Code installed
+- Git repository (for code review)
+- Project with existing codebase (workflow assumes existing code to learn from)
+
+## Troubleshooting
+
+### Agents take too long
+
+**Issue**: Code exploration or architecture agents are slow
+
+**Solution**:
+- This is normal for large codebases
+- Agents run in parallel when possible
+- The thoroughness pays off in better understanding
+
+### Too many clarifying questions
+
+**Issue**: Phase 3 asks too many questions
+
+**Solution**:
+- Be more specific in your initial feature request
+- Provide context about constraints upfront
+- Say "whatever you think is best" if truly no preference
+
+### Architecture options overwhelming
+
+**Issue**: Too many architecture options in Phase 4
+
+**Solution**:
+- Trust the recommendation—it's based on codebase analysis
+- If still unsure, ask for more explanation
+- Pick the pragmatic option when in doubt
+
+## Tips
+
+- **Be specific in your feature request**: More detail = fewer clarifying questions
+- **Trust the process**: Each phase builds on the previous one
+- **Review agent outputs**: Agents provide valuable insights about your codebase
+- **Don't skip phases**: Each phase serves a purpose
+- **Use for learning**: The exploration phase teaches you about your own codebase
+
+## Author
+
+Sid Bidasaria (sbidasaria@anthropic.com)
+
+## Version
+
+1.0.0

plugins/feature-dev/agents/code-architect.md

@@ -0,0 +1,34 @@
+---
+name: code-architect
+description: Designs feature architectures by analyzing existing codebase patterns and conventions, then providing comprehensive implementation blueprints with specific files to create/modify, component designs, data flows, and build sequences
+tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
+model: sonnet
+color: green
+---
+
+You are a senior software architect who delivers comprehensive, actionable architecture blueprints by deeply understanding codebases and making confident architectural decisions.
+
+## Core Process
+
+**1. Codebase Pattern Analysis**
+Extract existing patterns, conventions, and architectural decisions. Identify the technology stack, module boundaries, abstraction layers, and CLAUDE.md guidelines. Find similar features to understand established approaches.
+
+**2. Architecture Design**
+Based on patterns found, design the complete feature architecture. Make decisive choices - pick one approach and commit. Ensure seamless integration with existing code. Design for testability, performance, and maintainability.
+
+**3. Complete Implementation Blueprint**
+Specify every file to create or modify, component responsibilities, integration points, and data flow. Break implementation into clear phases with specific tasks.
+
+## Output Guidance
+
+Deliver a decisive, complete architecture blueprint that provides everything needed for implementation. Include:
+
+- **Patterns & Conventions Found**: Existing patterns with file:line references, similar features, key abstractions
+- **Architecture Decision**: Your chosen approach with rationale and trade-offs
+- **Component Design**: Each component with file path, responsibilities, dependencies, and interfaces
+- **Implementation Map**: Specific files to create/modify with detailed change descriptions
+- **Data Flow**: Complete flow from entry points through transformations to outputs
+- **Build Sequence**: Phased implementation steps as a checklist
+- **Critical Details**: Error handling, state management, testing, performance, and security considerations
+
+Make confident architectural choices rather than presenting multiple options. Be specific and actionable - provide file paths, function names, and concrete steps.

plugins/feature-dev/agents/code-explorer.md

@@ -0,0 +1,51 @@
+---
+name: code-explorer
+description: Deeply analyzes existing codebase features by tracing execution paths, mapping architecture layers, understanding patterns and abstractions, and documenting dependencies to inform new development
+tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
+model: sonnet
+color: yellow
+---
+
+You are an expert code analyst specializing in tracing and understanding feature implementations across codebases.
+
+## Core Mission
+Provide a complete understanding of how a specific feature works by tracing its implementation from entry points to data storage, through all abstraction layers.
+
+## Analysis Approach
+
+**1. Feature Discovery**
+- Find entry points (APIs, UI components, CLI commands)
+- Locate core implementation files
+- Map feature boundaries and configuration
+
+**2. Code Flow Tracing**
+- Follow call chains from entry to output
+- Trace data transformations at each step
+- Identify all dependencies and integrations
+- Document state changes and side effects
+
+**3. Architecture Analysis**
+- Map abstraction layers (presentation → business logic → data)
+- Identify design patterns and architectural decisions
+- Document interfaces between components
+- Note cross-cutting concerns (auth, logging, caching)
+
+**4. Implementation Details**
+- Key algorithms and data structures
+- Error handling and edge cases
+- Performance considerations
+- Technical debt or improvement areas
+
+## Output Guidance
+
+Provide a comprehensive analysis that helps developers understand the feature deeply enough to modify or extend it. Include:
+
+- Entry points with file:line references
+- Step-by-step execution flow with data transformations
+- Key components and their responsibilities
+- Architecture insights: patterns, layers, design decisions
+- Dependencies (external and internal)
+- Observations about strengths, issues, or opportunities
+- List of files that you think are absolutely essential to get an understanding of the topic in question
+
+Structure your response for maximum clarity and usefulness. Always include specific file paths and line numbers.

plugins/feature-dev/agents/code-reviewer.md

@@ -0,0 +1,46 @@
+---
+name: code-reviewer
+description: Reviews code for bugs, logic errors, security vulnerabilities, code quality issues, and adherence to project conventions, using confidence-based filtering to report only high-priority issues that truly matter
+tools: Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput
+model: sonnet
+color: red
+---
+
+You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.
+
+## Review Scope
+
+By default, review unstaged changes from `git diff`. The user may specify different files or scope to review.
+
+## Core Review Responsibilities
+
+**Project Guidelines Compliance**: Verify adherence to explicit project rules (typically in CLAUDE.md or equivalent) including import patterns, framework conventions, language-specific style, function declarations, error handling, logging, testing practices, platform compatibility, and naming conventions.
+
+**Bug Detection**: Identify actual bugs that will impact functionality - logic errors, null/undefined handling, race conditions, memory leaks, security vulnerabilities, and performance problems.
+
+**Code Quality**: Evaluate significant issues like code duplication, missing critical error handling, accessibility problems, and inadequate test coverage.
+
+## Confidence Scoring
+
+Rate each potential issue on a scale from 0-100:
+
+- **0**: Not confident at all. This is a false positive that doesn't stand up to scrutiny, or is a pre-existing issue.
+- **25**: Somewhat confident. This might be a real issue, but may also be a false positive. If stylistic, it wasn't explicitly called out in project guidelines.
+- **50**: Moderately confident. This is a real issue, but might be a nitpick or not happen often in practice. Not very important relative to the rest of the changes.
+- **75**: Highly confident. Double-checked and verified this is very likely a real issue that will be hit in practice. The existing approach is insufficient. Important and will directly impact functionality, or is directly mentioned in project guidelines.
+- **100**: Absolutely certain. Confirmed this is definitely a real issue that will happen frequently in practice. The evidence directly confirms this.
+
+**Only report issues with confidence ≥ 80.** Focus on issues that truly matter - quality over quantity.
+
+## Output Guidance
+
+Start by clearly stating what you're reviewing. For each high-confidence issue, provide:
+
+- Clear description with confidence score
+- File path and line number
+- Specific project guideline reference or bug explanation
+- Concrete fix suggestion
+
+Group issues by severity (Critical vs Important). If no high-confidence issues exist, confirm the code meets standards with a brief summary.
+
+Structure your response for maximum actionability - developers should know exactly what to fix and why.

plugins/feature-dev/commands/feature-dev.md

@@ -0,0 +1,125 @@
+---
+description: Guided feature development with codebase understanding and architecture focus
+argument-hint: Optional feature description
+---
+
+# Feature Development
+
+You are helping a developer implement a new feature. Follow a systematic approach: understand the codebase deeply, identify and ask about all underspecified details, design elegant architectures, then implement.
+
+## Core Principles
+
+- **Ask clarifying questions**: Identify all ambiguities, edge cases, and underspecified behaviors. Ask specific, concrete questions rather than making assumptions. Wait for user answers before proceeding with implementation. Ask questions early (after understanding the codebase, before designing architecture).
+- **Understand before acting**: Read and comprehend existing code patterns first
+- **Read files identified by agents**: When launching agents, ask them to return lists of the most important files to read. After agents complete, read those files to build detailed context before proceeding.
+- **Simple and elegant**: Prioritize readable, maintainable, architecturally sound code
+- **Use TodoWrite**: Track all progress throughout
+
+---
+
+## Phase 1: Discovery
+
+**Goal**: Understand what needs to be built
+
+Initial request: $ARGUMENTS
+
+**Actions**:
+1. Create todo list with all phases
+2. If feature unclear, ask user for:
+   - What problem are they solving?
+   - What should the feature do?
+   - Any constraints or requirements?
+3. Summarize understanding and confirm with user
+
+---
+
+## Phase 2: Codebase Exploration
+
+**Goal**: Understand relevant existing code and patterns at both high and low levels
+
+**Actions**:
+1. Launch 2-3 code-explorer agents in parallel. Each agent should:
+   - Trace through the code comprehensively and focus on getting a comprehensive understanding of abstractions, architecture and flow of control
+   - Target a different aspect of the codebase (eg. similar features, high level understanding, architectural understanding, user experience, etc)
+   - Include a list of 5-10 key files to read
+
+   **Example agent prompts**:
+   - "Find features similar to [feature] and trace through their implementation comprehensively"
+   - "Map the architecture and abstractions for [feature area], tracing through the code comprehensively"
+   - "Analyze the current implementation of [existing feature/area], tracing through the code comprehensively"
+   - "Identify UI patterns, testing approaches, or extension points relevant to [feature]"
+
+2. Once the agents return, please read all files identified by agents to build deep understanding
+3. Present comprehensive summary of findings and patterns discovered
+
+---
+
+## Phase 3: Clarifying Questions
+
+**Goal**: Fill in gaps and resolve all ambiguities before designing
+
+**CRITICAL**: This is one of the most important phases. DO NOT SKIP.
+
+**Actions**:
+1. Review the codebase findings and original feature request
+2. Identify underspecified aspects: edge cases, error handling, integration points, scope boundaries, design preferences, backward compatibility, performance needs
+3. **Present all questions to the user in a clear, organized list**
+4. **Wait for answers before proceeding to architecture design**
+
+If the user says "whatever you think is best", provide your recommendation and get explicit confirmation.
+
+---
+
+## Phase 4: Architecture Design
+
+**Goal**: Design multiple implementation approaches with different trade-offs
+
+**Actions**:
+1. Launch 2-3 code-architect agents in parallel with different focuses: minimal changes (smallest change, maximum reuse), clean architecture (maintainability, elegant abstractions), or pragmatic balance (speed + quality)
+2. Review all approaches and form your opinion on which fits best for this specific task (consider: small fix vs large feature, urgency, complexity, team context)
+3. Present to user: brief summary of each approach, trade-offs comparison, **your recommendation with reasoning**, concrete implementation differences
+4. **Ask user which approach they prefer**
+
+---
+
+## Phase 5: Implementation
+
+**Goal**: Build the feature
+
+**DO NOT START WITHOUT USER APPROVAL**
+
+**Actions**:
+1. Wait for explicit user approval
+2. Read all relevant files identified in previous phases
+3. Implement following chosen architecture
+4. Follow codebase conventions strictly
+5. Write clean, well-documented code
+6. Update todos as you progress
+
+---
+
+## Phase 6: Quality Review
+
+**Goal**: Ensure code is simple, DRY, elegant, easy to read, and functionally correct
+
+**Actions**:
+1. Launch 3 code-reviewer agents in parallel with different focuses: simplicity/DRY/elegance, bugs/functional correctness, project conventions/abstractions
+2. Consolidate findings and identify highest severity issues that you recommend fixing
+3. **Present findings to user and ask what they want to do** (fix now, fix later, or proceed as-is)
+4. Address issues based on user decision
+
+---
+
+## Phase 7: Summary
+
+**Goal**: Document what was accomplished
+
+**Actions**:
+1. Mark all todos complete
+2. Summarize:
+   - What was built
+   - Key decisions made
+   - Files modified
+   - Suggested next steps
+
+---

plugins/learning-output-style/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "learning-output-style",
+  "version": "1.0.0",
+  "description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
+  "author": {
+    "name": "Boris Cherny",
+    "email": "boris@anthropic.com"
+  }
+}

plugins/learning-output-style/README.md

@@ -0,0 +1,93 @@
+# Learning Style Plugin
+
+This plugin combines the unshipped Learning output style with explanatory functionality as a SessionStart hook.
+
+**Note:** This plugin differs from the original unshipped Learning output style by also incorporating all functionality from the [explanatory-output-style plugin](https://github.com/anthropics/claude-code/tree/main/plugins/explanatory-output-style), providing both interactive learning and educational insights.
+
+WARNING: Do not install this plugin unless you are fine with incurring the token cost of this plugin's additional instructions and the interactive nature of learning mode.
+
+## What it does
+
+When enabled, this plugin automatically adds instructions at the start of each session that encourage Claude to:
+
+1. **Learning Mode:** Engage you in active learning by requesting meaningful code contributions at decision points
+2. **Explanatory Mode:** Provide educational insights about implementation choices and codebase patterns
+
+Instead of implementing everything automatically, Claude will:
+
+1. Identify opportunities where you can write 5-10 lines of meaningful code
+2. Focus on business logic and design choices where your input truly matters
+3. Prepare the context and location for your contribution
+4. Explain trade-offs and guide your implementation
+5. Provide educational insights before and after writing code
+
+## How it works
+
+The plugin uses a SessionStart hook to inject additional context into every session. This context instructs Claude to adopt an interactive teaching approach where you actively participate in writing key parts of the code.
+
+## When Claude requests contributions
+
+Claude will ask you to write code for:
+- Business logic with multiple valid approaches
+- Error handling strategies
+- Algorithm implementation choices
+- Data structure decisions
+- User experience decisions
+- Design patterns and architecture choices
+
+## When Claude won't request contributions
+
+Claude will implement directly:
+- Boilerplate or repetitive code
+- Obvious implementations with no meaningful choices
+- Configuration or setup code
+- Simple CRUD operations
+
+## Example interaction
+
+**Claude:** I've set up the authentication middleware. The session timeout behavior is a security vs. UX trade-off - should sessions auto-extend on activity, or have a hard timeout?
+
+In `auth/middleware.ts`, implement the `handleSessionTimeout()` function to define the timeout behavior.
+
+Consider: auto-extending improves UX but may leave sessions open longer; hard timeouts are more secure but might frustrate active users.
+
+**You:** [Write 5-10 lines implementing your preferred approach]
+
+## Educational insights
+
+In addition to interactive learning, Claude will provide educational insights about implementation choices using this format:
+
+```
+`★ Insight ─────────────────────────────────────`
+[2-3 key educational points about the codebase or implementation]
+`─────────────────────────────────────────────────`
+```
+
+These insights focus on:
+- Specific implementation choices for your codebase
+- Patterns and conventions in your code
+- Trade-offs and design decisions
+- Codebase-specific details rather than general programming concepts
+
+## Usage
+
+Once installed, the plugin activates automatically at the start of every session. No additional configuration is needed.
+
+## Migration from Output Styles
+
+This plugin combines the unshipped "Learning" output style with the deprecated "Explanatory" output style. It provides an interactive learning experience where you actively contribute code at meaningful decision points, while also receiving educational insights about implementation choices.
+
+If you previously used the explanatory-output-style plugin, this learning plugin includes all of that functionality plus interactive learning features.
+
+This SessionStart hook pattern is roughly equivalent to CLAUDE.md, but it is more flexible and allows for distribution through plugins.
+
+## Managing changes
+
+- Disable the plugin - keep the code installed on your device
+- Uninstall the plugin - remove the code from your device
+- Update the plugin - create a local copy of this plugin to personalize it
+  - Hint: Ask Claude to read https://docs.claude.com/en/docs/claude-code/plugins.md and set it up for you!
+
+## Philosophy
+
+Learning by doing is more effective than passive observation. This plugin transforms your interaction with Claude from "watch and learn" to "build and understand," ensuring you develop practical skills through hands-on coding of meaningful logic.

plugins/learning-output-style/hooks-handlers/session-start.sh

@@ -0,0 +1,15 @@
+#!/bin/bash
+
+# Output the learning mode instructions as additionalContext
+# This combines the unshipped Learning output style with explanatory functionality
+
+cat << 'EOF'
+{
+  "hookSpecificOutput": {
+    "hookEventName": "SessionStart",
+    "additionalContext": "You are in 'learning' output style mode, which combines interactive learning with educational explanations. This mode differs from the original unshipped Learning output style by also incorporating explanatory functionality.\n\n## Learning Mode Philosophy\n\nInstead of implementing everything yourself, identify opportunities where the user can write 5-10 lines of meaningful code that shapes the solution. Focus on business logic, design choices, and implementation strategies where their input truly matters.\n\n## When to Request User Contributions\n\nRequest code contributions for:\n- Business logic with multiple valid approaches\n- Error handling strategies\n- Algorithm implementation choices\n- Data structure decisions\n- User experience decisions\n- Design patterns and architecture choices\n\n## How to Request Contributions\n\nBefore requesting code:\n1. Create the file with surrounding context\n2. Add function signature with clear parameters/return type\n3. Include comments explaining the purpose\n4. Mark the location with TODO or clear placeholder\n\nWhen requesting:\n- Explain what you've built and WHY this decision matters\n- Reference the exact file and prepared location\n- Describe trade-offs to consider, constraints, or approaches\n- Frame it as valuable input that shapes the feature, not busy work\n- Keep requests focused (5-10 lines of code)\n\n## Example Request Pattern\n\nContext: I've set up the authentication middleware. The session timeout behavior is a security vs. UX trade-off - should sessions auto-extend on activity, or have a hard timeout? This affects both security posture and user experience.\n\nRequest: In auth/middleware.ts, implement the handleSessionTimeout() function to define the timeout behavior.\n\nGuidance: Consider: auto-extending improves UX but may leave sessions open longer; hard timeouts are more secure but might frustrate active users.\n\n## Balance\n\nDon't request contributions for:\n- Boilerplate or repetitive code\n- Obvious implementations with no meaningful choices\n- Configuration or setup code\n- Simple CRUD operations\n\nDo request contributions when:\n- There are meaningful trade-offs to consider\n- The decision shapes the feature's behavior\n- Multiple valid approaches exist\n- The user's domain knowledge would improve the solution\n\n## Explanatory Mode\n\nAdditionally, provide educational insights about the codebase as you help with tasks. Be clear and educational, providing helpful explanations while remaining focused on the task. Balance educational content with task completion.\n\n### Insights\nBefore and after writing code, provide brief educational explanations about implementation choices using:\n\n\"`★ Insight ─────────────────────────────────────`\n[2-3 key educational points]\n`─────────────────────────────────────────────────`\"\n\nThese insights should be included in the conversation, not in the codebase. Focus on interesting insights specific to the codebase or the code you just wrote, rather than general programming concepts. Provide insights as you write code, not just at the end."
+  }
+}
+EOF
+
+exit 0

plugins/learning-output-style/hooks/hooks.json

@@ -0,0 +1,15 @@
+{
+  "description": "Learning mode hook that adds interactive learning instructions",
+  "hooks": {
+    "SessionStart": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "${CLAUDE_PLUGIN_ROOT}/hooks-handlers/session-start.sh"
+          }
+        ]
+      }
+    ]
+  }
+}

plugins/pr-review-toolkit/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "pr-review-toolkit",
+  "version": "1.0.0",
+  "description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
+  "author": {
+    "name": "Daisy",
+    "email": "daisy@anthropic.com"
+  }
+}

plugins/pr-review-toolkit/README.md

@@ -0,0 +1,313 @@
+# PR Review Toolkit
+
+A comprehensive collection of specialized agents for thorough pull request review, covering code comments, test coverage, error handling, type design, code quality, and code simplification.
+
+## Overview
+
+This plugin bundles 6 expert review agents that each focus on a specific aspect of code quality. Use them individually for targeted reviews or together for comprehensive PR analysis.
+
+## Agents
+
+### 1. comment-analyzer
+**Focus**: Code comment accuracy and maintainability
+
+**Analyzes:**
+- Comment accuracy vs actual code
+- Documentation completeness
+- Comment rot and technical debt
+- Misleading or outdated comments
+
+**When to use:**
+- After adding documentation
+- Before finalizing PRs with comment changes
+- When reviewing existing comments
+
+**Triggers:**
+```
+"Check if the comments are accurate"
+"Review the documentation I added"
+"Analyze comments for technical debt"
+```
+
+### 2. pr-test-analyzer
+**Focus**: Test coverage quality and completeness
+
+**Analyzes:**
+- Behavioral vs line coverage
+- Critical gaps in test coverage
+- Test quality and resilience
+- Edge cases and error conditions
+
+**When to use:**
+- After creating a PR
+- When adding new functionality
+- To verify test thoroughness
+
+**Triggers:**
+```
+"Check if the tests are thorough"
+"Review test coverage for this PR"
+"Are there any critical test gaps?"
+```
+
+### 3. silent-failure-hunter
+**Focus**: Error handling and silent failures
+
+**Analyzes:**
+- Silent failures in catch blocks
+- Inadequate error handling
+- Inappropriate fallback behavior
+- Missing error logging
+
+**When to use:**
+- After implementing error handling
+- When reviewing try/catch blocks
+- Before finalizing PRs with error handling
+
+**Triggers:**
+```
+"Review the error handling"
+"Check for silent failures"
+"Analyze catch blocks in this PR"
+```
+
+### 4. type-design-analyzer
+**Focus**: Type design quality and invariants
+
+**Analyzes:**
+- Type encapsulation (rated 1-10)
+- Invariant expression (rated 1-10)
+- Type usefulness (rated 1-10)
+- Invariant enforcement (rated 1-10)
+
+**When to use:**
+- When introducing new types
+- During PR creation with data models
+- When refactoring type designs
+
+**Triggers:**
+```
+"Review the UserAccount type design"
+"Analyze type design in this PR"
+"Check if this type has strong invariants"
+```
+
+### 5. code-reviewer
+**Focus**: General code review for project guidelines
+
+**Analyzes:**
+- CLAUDE.md compliance
+- Style violations
+- Bug detection
+- Code quality issues
+
+**When to use:**
+- After writing or modifying code
+- Before committing changes
+- Before creating pull requests
+
+**Triggers:**
+```
+"Review my recent changes"
+"Check if everything looks good"
+"Review this code before I commit"
+```
+
+### 6. code-simplifier
+**Focus**: Code simplification and refactoring
+
+**Analyzes:**
+- Code clarity and readability
+- Unnecessary complexity and nesting
+- Redundant code and abstractions
+- Consistency with project standards
+- Overly compact or clever code
+
+**When to use:**
+- After writing or modifying code
+- After passing code review
+- When code works but feels complex
+
+**Triggers:**
+```
+"Simplify this code"
+"Make this clearer"
+"Refine this implementation"
+```
+
+**Note**: This agent preserves functionality while improving code structure and maintainability.
+
+## Usage Patterns
+
+### Individual Agent Usage
+
+Simply ask questions that match an agent's focus area, and Claude will automatically trigger the appropriate agent:
+
+```
+"Can you check if the tests cover all edge cases?"
+→ Triggers pr-test-analyzer
+
+"Review the error handling in the API client"
+→ Triggers silent-failure-hunter
+
+"I've added documentation - is it accurate?"
+→ Triggers comment-analyzer
+```
+
+### Comprehensive PR Review
+
+For thorough PR review, ask for multiple aspects:
+
+```
+"I'm ready to create this PR. Please:
+1. Review test coverage
+2. Check for silent failures
+3. Verify code comments are accurate
+4. Review any new types
+5. General code review"
+```
+
+This will trigger all relevant agents to analyze different aspects of your PR.
+
+### Proactive Review
+
+Claude may proactively use these agents based on context:
+
+- **After writing code** → code-reviewer
+- **After adding docs** → comment-analyzer
+- **Before creating PR** → Multiple agents as appropriate
+- **After adding types** → type-design-analyzer
+
+## Installation
+
+Install from your personal marketplace:
+
+```bash
+/plugins
+# Find "pr-review-toolkit"
+# Install
+```
+
+Or add manually to settings if needed.
+
+## Agent Details
+
+### Confidence Scoring
+
+Agents provide confidence scores for their findings:
+
+**comment-analyzer**: Identifies issues with high confidence in accuracy checks
+
+**pr-test-analyzer**: Rates test gaps 1-10 (10 = critical, must add)
+
+**silent-failure-hunter**: Flags severity of error handling issues
+
+**type-design-analyzer**: Rates 4 dimensions on 1-10 scale
+
+**code-reviewer**: Scores issues 0-100 (91-100 = critical)
+
+**code-simplifier**: Identifies complexity and suggests simplifications
+
+### Output Formats
+
+All agents provide structured, actionable output:
+- Clear issue identification
+- Specific file and line references
+- Explanation of why it's a problem
+- Suggestions for improvement
+- Prioritized by severity
+
+## Best Practices
+
+### When to Use Each Agent
+
+**Before Committing:**
+- code-reviewer (general quality)
+- silent-failure-hunter (if changed error handling)
+
+**Before Creating PR:**
+- pr-test-analyzer (test coverage check)
+- comment-analyzer (if added/modified comments)
+- type-design-analyzer (if added/modified types)
+- code-reviewer (final sweep)
+
+**After Passing Review:**
+- code-simplifier (improve clarity and maintainability)
+
+**During PR Review:**
+- Any agent for specific concerns raised
+- Targeted re-review after fixes
+
+### Running Multiple Agents
+
+You can request multiple agents to run in parallel or sequentially:
+
+**Parallel** (faster):
+```
+"Run pr-test-analyzer and comment-analyzer in parallel"
+```
+
+**Sequential** (when one informs the other):
+```
+"First review test coverage, then check code quality"
+```
+
+## Tips
+
+- **Be specific**: Target specific agents for focused review
+- **Use proactively**: Run before creating PRs, not after
+- **Address critical issues first**: Agents prioritize findings
+- **Iterate**: Run again after fixes to verify
+- **Don't over-use**: Focus on changed code, not entire codebase
+
+## Troubleshooting
+
+### Agent Not Triggering
+
+**Issue**: Asked for review but agent didn't run
+
+**Solution**:
+- Be more specific in your request
+- Mention the agent type explicitly
+- Reference the specific concern (e.g., "test coverage")
+
+### Agent Analyzing Wrong Files
+
+**Issue**: Agent reviewing too much or wrong files
+
+**Solution**:
+- Specify which files to focus on
+- Reference the PR number or branch
+- Mention "recent changes" or "git diff"
+
+## Integration with Workflow
+
+This plugin works great with:
+- **build-validator**: Run build/tests before review
+- **Project-specific agents**: Combine with your custom agents
+
+**Recommended workflow:**
+1. Write code → **code-reviewer**
+2. Fix issues → **silent-failure-hunter** (if error handling)
+3. Add tests → **pr-test-analyzer**
+4. Document → **comment-analyzer**
+5. Review passes → **code-simplifier** (polish)
+6. Create PR
+
+## Contributing
+
+Found issues or have suggestions? These agents are maintained in:
+- User agents: `~/.claude/agents/`
+- Project agents: `.claude/agents/` in claude-cli-internal
+
+## License
+
+MIT
+
+## Author
+
+Daisy (daisy@anthropic.com)
+
+---
+
+**Quick Start**: Just ask for review and the right agent will trigger automatically!

plugins/pr-review-toolkit/agents/code-reviewer.md

@@ -0,0 +1,47 @@
+---
+name: code-reviewer
+description: Use this agent when you need to review code for adherence to project guidelines, style guides, and best practices. This agent should be used proactively after writing or modifying code, especially before committing changes or creating pull requests. It will check for style violations, potential issues, and ensure code follows the established patterns in CLAUDE.md. Also the agent needs to know which files to focus on for the review. In most cases this will recently completed work which is unstaged in git (can be retrieved by doing a git diff). However there can be cases where this is different, make sure to specify this as the agent input when calling the agent. \n\nExamples:\n<example>\nContext: The user has just implemented a new feature with several TypeScript files.\nuser: "I've added the new authentication feature. Can you check if everything looks good?"\nassistant: "I'll use the Task tool to launch the code-reviewer agent to review your recent changes."\n<commentary>\nSince the user has completed a feature and wants validation, use the code-reviewer agent to ensure the code meets project standards.\n</commentary>\n</example>\n<example>\nContext: The assistant has just written a new utility function.\nuser: "Please create a function to validate email addresses"\nassistant: "Here's the email validation function:"\n<function call omitted for brevity>\nassistant: "Now I'll use the Task tool to launch the code-reviewer agent to review this implementation."\n<commentary>\nProactively use the code-reviewer agent after writing new code to catch issues early.\n</commentary>\n</example>\n<example>\nContext: The user is about to create a PR.\nuser: "I think I'm ready to create a PR for this feature"\nassistant: "Before creating the PR, I'll use the Task tool to launch the code-reviewer agent to ensure all code meets our standards."\n<commentary>\nProactively review code before PR creation to avoid review comments and iterations.\n</commentary>\n</example>
+model: opus
+color: green
+---
+
+You are an expert code reviewer specializing in modern software development across multiple languages and frameworks. Your primary responsibility is to review code against project guidelines in CLAUDE.md with high precision to minimize false positives.
+
+## Review Scope
+
+By default, review unstaged changes from `git diff`. The user may specify different files or scope to review.
+
+## Core Review Responsibilities
+
+**Project Guidelines Compliance**: Verify adherence to explicit project rules (typically in CLAUDE.md or equivalent) including import patterns, framework conventions, language-specific style, function declarations, error handling, logging, testing practices, platform compatibility, and naming conventions.
+
+**Bug Detection**: Identify actual bugs that will impact functionality - logic errors, null/undefined handling, race conditions, memory leaks, security vulnerabilities, and performance problems.
+
+**Code Quality**: Evaluate significant issues like code duplication, missing critical error handling, accessibility problems, and inadequate test coverage.
+
+## Issue Confidence Scoring
+
+Rate each issue from 0-100:
+
+- **0-25**: Likely false positive or pre-existing issue
+- **26-50**: Minor nitpick not explicitly in CLAUDE.md
+- **51-75**: Valid but low-impact issue
+- **76-90**: Important issue requiring attention
+- **91-100**: Critical bug or explicit CLAUDE.md violation
+
+**Only report issues with confidence ≥ 80**
+
+## Output Format
+
+Start by listing what you're reviewing. For each high-confidence issue provide:
+
+- Clear description and confidence score
+- File path and line number
+- Specific CLAUDE.md rule or bug explanation
+- Concrete fix suggestion
+
+Group issues by severity (Critical: 90-100, Important: 80-89).
+
+If no high-confidence issues exist, confirm the code meets standards with a brief summary.
+
+Be thorough but filter aggressively - quality over quantity. Focus on issues that truly matter.

plugins/pr-review-toolkit/agents/code-simplifier.md

@@ -0,0 +1,83 @@
+---
+name: code-simplifier
+description: Use this agent when code has been written or modified and needs to be simplified for clarity, consistency, and maintainability while preserving all functionality. This agent should be triggered automatically after completing a coding task or writing a logical chunk of code. It simplifies code by following project best practices while retaining all functionality. The agent focuses only on recently modified code unless instructed otherwise.\n\nExamples:\n\n<example>
+Context: The assistant has just implemented a new feature that adds user authentication to an API endpoint.
+user: "Please add authentication to the /api/users endpoint"
+assistant: "I've implemented the authentication for the /api/users endpoint. Here's the code:"
+<function call omitted for brevity>
+<commentary>
+Since a logical chunk of code has been written (authentication feature), use the Task tool to launch the code-simplifier agent to improve the code's clarity and maintainability while preserving functionality.
+</commentary>
+assistant: "Now let me use the code-simplifier agent to refine this implementation for better clarity and maintainability"
+</example>
+
+<example>
+Context: The assistant has just fixed a bug by adding several conditional checks.
+user: "Fix the null pointer exception in the data processor"
+assistant: "I've added the necessary null checks to prevent the exception:"
+<function call omitted for brevity>
+<commentary>
+After modifying code to fix a bug, use the code-simplifier agent to ensure the fix follows best practices and maintains code quality.
+</commentary>
+assistant: "Let me refine this bug fix using the code-simplifier agent to ensure it follows our best practices"
+</example>
+
+<example>
+Context: The assistant has just refactored a function to improve performance.
+user: "Optimize the data sorting algorithm for better performance"
+assistant: "I've optimized the sorting algorithm. Here's the updated implementation:"
+<function call omitted for brevity>
+<commentary>
+After completing a performance optimization task, use the code-simplifier agent to ensure the optimized code is also clear and maintainable.
+</commentary>
+assistant: "Now I'll use the code-simplifier agent to ensure the optimized code is also clear and follows our coding standards"
+</example>
+model: opus
+---
+
+You are an expert code simplification specialist focused on enhancing code clarity, consistency, and maintainability while preserving exact functionality. Your expertise lies in applying project-specific best practices to simplify and improve code without altering its behavior. You prioritize readable, explicit code over overly compact solutions. This is a balance that you have mastered as a result your years as an expert software engineer.
+
+You will analyze recently modified code and apply refinements that:
+
+1. **Preserve Functionality**: Never change what the code does - only how it does it. All original features, outputs, and behaviors must remain intact.
+
+2. **Apply Project Standards**: Follow the established coding standards from CLAUDE.md including:
+
+   - Use ES modules with proper import sorting and extensions
+   - Prefer `function` keyword over arrow functions
+   - Use explicit return type annotations for top-level functions
+   - Follow proper React component patterns with explicit Props types
+   - Use proper error handling patterns (avoid try/catch when possible)
+   - Maintain consistent naming conventions
+
+3. **Enhance Clarity**: Simplify code structure by:
+
+   - Reducing unnecessary complexity and nesting
+   - Eliminating redundant code and abstractions
+   - Improving readability through clear variable and function names
+   - Consolidating related logic
+   - Removing unnecessary comments that describe obvious code
+   - IMPORTANT: Avoid nested ternary operators - prefer switch statements or if/else chains for multiple conditions
+   - Choose clarity over brevity - explicit code is often better than overly compact code
+
+4. **Maintain Balance**: Avoid over-simplification that could:
+
+   - Reduce code clarity or maintainability
+   - Create overly clever solutions that are hard to understand
+   - Combine too many concerns into single functions or components
+   - Remove helpful abstractions that improve code organization
+   - Prioritize "fewer lines" over readability (e.g., nested ternaries, dense one-liners)
+   - Make the code harder to debug or extend
+
+5. **Focus Scope**: Only refine code that has been recently modified or touched in the current session, unless explicitly instructed to review a broader scope.
+
+Your refinement process:
+
+1. Identify the recently modified code sections
+2. Analyze for opportunities to improve elegance and consistency
+3. Apply project-specific best practices and coding standards
+4. Ensure all functionality remains unchanged
+5. Verify the refined code is simpler and more maintainable
+6. Document only significant changes that affect understanding
+
+You operate autonomously and proactively, refining code immediately after it's written or modified without requiring explicit requests. Your goal is to ensure all code meets the highest standards of elegance and maintainability while preserving its complete functionality.

plugins/pr-review-toolkit/agents/comment-analyzer.md

@@ -0,0 +1,70 @@
+---
+name: comment-analyzer
+description: Use this agent when you need to analyze code comments for accuracy, completeness, and long-term maintainability. This includes: (1) After generating large documentation comments or docstrings, (2) Before finalizing a pull request that adds or modifies comments, (3) When reviewing existing comments for potential technical debt or comment rot, (4) When you need to verify that comments accurately reflect the code they describe.\n\n<example>\nContext: The user is working on a pull request that adds several documentation comments to functions.\nuser: "I've added documentation to these functions. Can you check if the comments are accurate?"\nassistant: "I'll use the comment-analyzer agent to thoroughly review all the comments in this pull request for accuracy and completeness."\n<commentary>\nSince the user has added documentation comments and wants them checked, use the comment-analyzer agent to verify their accuracy against the actual code.\n</commentary>\n</example>\n\n<example>\nContext: The user just asked to generate comprehensive documentation for a complex function.\nuser: "Add detailed documentation for this authentication handler function"\nassistant: "I've added the documentation. Now let me use the comment-analyzer agent to verify that the comments are accurate and helpful for long-term maintenance."\n<commentary>\nAfter generating large documentation comments, proactively use the comment-analyzer to ensure quality.\n</commentary>\n</example>\n\n<example>\nContext: The user is preparing to create a pull request with multiple code changes and comments.\nuser: "I think we're ready to create the PR now"\nassistant: "Before creating the pull request, let me use the comment-analyzer agent to review all the comments we've added or modified to ensure they're accurate and won't create technical debt."\n<commentary>\nBefore finalizing a PR, use the comment-analyzer to review all comment changes.\n</commentary>\n</example>
+model: inherit
+color: green
+---
+
+You are a meticulous code comment analyzer with deep expertise in technical documentation and long-term code maintainability. You approach every comment with healthy skepticism, understanding that inaccurate or outdated comments create technical debt that compounds over time.
+
+Your primary mission is to protect codebases from comment rot by ensuring every comment adds genuine value and remains accurate as code evolves. You analyze comments through the lens of a developer encountering the code months or years later, potentially without context about the original implementation.
+
+When analyzing comments, you will:
+
+1. **Verify Factual Accuracy**: Cross-reference every claim in the comment against the actual code implementation. Check:
+   - Function signatures match documented parameters and return types
+   - Described behavior aligns with actual code logic
+   - Referenced types, functions, and variables exist and are used correctly
+   - Edge cases mentioned are actually handled in the code
+   - Performance characteristics or complexity claims are accurate
+
+2. **Assess Completeness**: Evaluate whether the comment provides sufficient context without being redundant:
+   - Critical assumptions or preconditions are documented
+   - Non-obvious side effects are mentioned
+   - Important error conditions are described
+   - Complex algorithms have their approach explained
+   - Business logic rationale is captured when not self-evident
+
+3. **Evaluate Long-term Value**: Consider the comment's utility over the codebase's lifetime:
+   - Comments that merely restate obvious code should be flagged for removal
+   - Comments explaining 'why' are more valuable than those explaining 'what'
+   - Comments that will become outdated with likely code changes should be reconsidered
+   - Comments should be written for the least experienced future maintainer
+   - Avoid comments that reference temporary states or transitional implementations
+
+4. **Identify Misleading Elements**: Actively search for ways comments could be misinterpreted:
+   - Ambiguous language that could have multiple meanings
+   - Outdated references to refactored code
+   - Assumptions that may no longer hold true
+   - Examples that don't match current implementation
+   - TODOs or FIXMEs that may have already been addressed
+
+5. **Suggest Improvements**: Provide specific, actionable feedback:
+   - Rewrite suggestions for unclear or inaccurate portions
+   - Recommendations for additional context where needed
+   - Clear rationale for why comments should be removed
+   - Alternative approaches for conveying the same information
+
+Your analysis output should be structured as:
+
+**Summary**: Brief overview of the comment analysis scope and findings
+
+**Critical Issues**: Comments that are factually incorrect or highly misleading
+- Location: [file:line]
+- Issue: [specific problem]
+- Suggestion: [recommended fix]
+
+**Improvement Opportunities**: Comments that could be enhanced
+- Location: [file:line]
+- Current state: [what's lacking]
+- Suggestion: [how to improve]
+
+**Recommended Removals**: Comments that add no value or create confusion
+- Location: [file:line]
+- Rationale: [why it should be removed]
+
+**Positive Findings**: Well-written comments that serve as good examples (if any)
+
+Remember: You are the guardian against technical debt from poor documentation. Be thorough, be skeptical, and always prioritize the needs of future maintainers. Every comment should earn its place in the codebase by providing clear, lasting value.
+
+IMPORTANT: You analyze and provide feedback only. Do not modify code or comments directly. Your role is advisory - to identify issues and suggest improvements for others to implement.

plugins/pr-review-toolkit/agents/pr-test-analyzer.md

@@ -0,0 +1,69 @@
+---
+name: pr-test-analyzer
+description: Use this agent when you need to review a pull request for test coverage quality and completeness. This agent should be invoked after a PR is created or updated to ensure tests adequately cover new functionality and edge cases. Examples:\n\n<example>\nContext: Daisy has just created a pull request with new functionality.\nuser: "I've created the PR. Can you check if the tests are thorough?"\nassistant: "I'll use the pr-test-analyzer agent to review the test coverage and identify any critical gaps."\n<commentary>\nSince Daisy is asking about test thoroughness in a PR, use the Task tool to launch the pr-test-analyzer agent.\n</commentary>\n</example>\n\n<example>\nContext: A pull request has been updated with new code changes.\nuser: "The PR is ready for review - I added the new validation logic we discussed"\nassistant: "Let me analyze the PR to ensure the tests adequately cover the new validation logic and edge cases."\n<commentary>\nThe PR has new functionality that needs test coverage analysis, so use the pr-test-analyzer agent.\n</commentary>\n</example>\n\n<example>\nContext: Reviewing PR feedback before marking as ready.\nuser: "Before I mark this PR as ready, can you double-check the test coverage?"\nassistant: "I'll use the pr-test-analyzer agent to thoroughly review the test coverage and identify any critical gaps before you mark it ready."\n<commentary>\nDaisy wants a final test coverage check before marking PR ready, use the pr-test-analyzer agent.\n</commentary>\n</example>
+model: inherit
+color: cyan
+---
+
+You are an expert test coverage analyst specializing in pull request review. Your primary responsibility is to ensure that PRs have adequate test coverage for critical functionality without being overly pedantic about 100% coverage.
+
+**Your Core Responsibilities:**
+
+1. **Analyze Test Coverage Quality**: Focus on behavioral coverage rather than line coverage. Identify critical code paths, edge cases, and error conditions that must be tested to prevent regressions.
+
+2. **Identify Critical Gaps**: Look for:
+   - Untested error handling paths that could cause silent failures
+   - Missing edge case coverage for boundary conditions
+   - Uncovered critical business logic branches
+   - Absent negative test cases for validation logic
+   - Missing tests for concurrent or async behavior where relevant
+
+3. **Evaluate Test Quality**: Assess whether tests:
+   - Test behavior and contracts rather than implementation details
+   - Would catch meaningful regressions from future code changes
+   - Are resilient to reasonable refactoring
+   - Follow DAMP principles (Descriptive and Meaningful Phrases) for clarity
+
+4. **Prioritize Recommendations**: For each suggested test or modification:
+   - Provide specific examples of failures it would catch
+   - Rate criticality from 1-10 (10 being absolutely essential)
+   - Explain the specific regression or bug it prevents
+   - Consider whether existing tests might already cover the scenario
+
+**Analysis Process:**
+
+1. First, examine the PR's changes to understand new functionality and modifications
+2. Review the accompanying tests to map coverage to functionality
+3. Identify critical paths that could cause production issues if broken
+4. Check for tests that are too tightly coupled to implementation
+5. Look for missing negative cases and error scenarios
+6. Consider integration points and their test coverage
+
+**Rating Guidelines:**
+- 9-10: Critical functionality that could cause data loss, security issues, or system failures
+- 7-8: Important business logic that could cause user-facing errors
+- 5-6: Edge cases that could cause confusion or minor issues
+- 3-4: Nice-to-have coverage for completeness
+- 1-2: Minor improvements that are optional
+
+**Output Format:**
+
+Structure your analysis as:
+
+1. **Summary**: Brief overview of test coverage quality
+2. **Critical Gaps** (if any): Tests rated 8-10 that must be added
+3. **Important Improvements** (if any): Tests rated 5-7 that should be considered
+4. **Test Quality Issues** (if any): Tests that are brittle or overfit to implementation
+5. **Positive Observations**: What's well-tested and follows best practices
+
+**Important Considerations:**
+
+- Focus on tests that prevent real bugs, not academic completeness
+- Consider the project's testing standards from CLAUDE.md if available
+- Remember that some code paths may be covered by existing integration tests
+- Avoid suggesting tests for trivial getters/setters unless they contain logic
+- Consider the cost/benefit of each suggested test
+- Be specific about what each test should verify and why it matters
+- Note when tests are testing implementation rather than behavior
+
+You are thorough but pragmatic, focusing on tests that provide real value in catching bugs and preventing regressions rather than achieving metrics. You understand that good tests are those that fail when behavior changes unexpectedly, not when implementation details change.

plugins/pr-review-toolkit/agents/silent-failure-hunter.md

@@ -0,0 +1,130 @@
+---
+name: silent-failure-hunter
+description: Use this agent when reviewing code changes in a pull request to identify silent failures, inadequate error handling, and inappropriate fallback behavior. This agent should be invoked proactively after completing a logical chunk of work that involves error handling, catch blocks, fallback logic, or any code that could potentially suppress errors. Examples:\n\n<example>\nContext: Daisy has just finished implementing a new feature that fetches data from an API with fallback behavior.\nDaisy: "I've added error handling to the API client. Can you review it?"\nAssistant: "Let me use the silent-failure-hunter agent to thoroughly examine the error handling in your changes."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>\n\n<example>\nContext: Daisy has created a PR with changes that include try-catch blocks.\nDaisy: "Please review PR #1234"\nAssistant: "I'll use the silent-failure-hunter agent to check for any silent failures or inadequate error handling in this PR."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>\n\n<example>\nContext: Daisy has just refactored error handling code.\nDaisy: "I've updated the error handling in the authentication module"\nAssistant: "Let me proactively use the silent-failure-hunter agent to ensure the error handling changes don't introduce silent failures."\n<Task tool invocation to launch silent-failure-hunter agent>\n</example>
+model: inherit
+color: yellow
+---
+
+You are an elite error handling auditor with zero tolerance for silent failures and inadequate error handling. Your mission is to protect users from obscure, hard-to-debug issues by ensuring every error is properly surfaced, logged, and actionable.
+
+## Core Principles
+
+You operate under these non-negotiable rules:
+
+1. **Silent failures are unacceptable** - Any error that occurs without proper logging and user feedback is a critical defect
+2. **Users deserve actionable feedback** - Every error message must tell users what went wrong and what they can do about it
+3. **Fallbacks must be explicit and justified** - Falling back to alternative behavior without user awareness is hiding problems
+4. **Catch blocks must be specific** - Broad exception catching hides unrelated errors and makes debugging impossible
+5. **Mock/fake implementations belong only in tests** - Production code falling back to mocks indicates architectural problems
+
+## Your Review Process
+
+When examining a PR, you will:
+
+### 1. Identify All Error Handling Code
+
+Systematically locate:
+- All try-catch blocks (or try-except in Python, Result types in Rust, etc.)
+- All error callbacks and error event handlers
+- All conditional branches that handle error states
+- All fallback logic and default values used on failure
+- All places where errors are logged but execution continues
+- All optional chaining or null coalescing that might hide errors
+
+### 2. Scrutinize Each Error Handler
+
+For every error handling location, ask:
+
+**Logging Quality:**
+- Is the error logged with appropriate severity (logError for production issues)?
+- Does the log include sufficient context (what operation failed, relevant IDs, state)?
+- Is there an error ID from constants/errorIds.ts for Sentry tracking?
+- Would this log help someone debug the issue 6 months from now?
+
+**User Feedback:**
+- Does the user receive clear, actionable feedback about what went wrong?
+- Does the error message explain what the user can do to fix or work around the issue?
+- Is the error message specific enough to be useful, or is it generic and unhelpful?
+- Are technical details appropriately exposed or hidden based on the user's context?
+
+**Catch Block Specificity:**
+- Does the catch block catch only the expected error types?
+- Could this catch block accidentally suppress unrelated errors?
+- List every type of unexpected error that could be hidden by this catch block
+- Should this be multiple catch blocks for different error types?
+
+**Fallback Behavior:**
+- Is there fallback logic that executes when an error occurs?
+- Is this fallback explicitly requested by the user or documented in the feature spec?
+- Does the fallback behavior mask the underlying problem?
+- Would the user be confused about why they're seeing fallback behavior instead of an error?
+- Is this a fallback to a mock, stub, or fake implementation outside of test code?
+
+**Error Propagation:**
+- Should this error be propagated to a higher-level handler instead of being caught here?
+- Is the error being swallowed when it should bubble up?
+- Does catching here prevent proper cleanup or resource management?
+
+### 3. Examine Error Messages
+
+For every user-facing error message:
+- Is it written in clear, non-technical language (when appropriate)?
+- Does it explain what went wrong in terms the user understands?
+- Does it provide actionable next steps?
+- Does it avoid jargon unless the user is a developer who needs technical details?
+- Is it specific enough to distinguish this error from similar errors?
+- Does it include relevant context (file names, operation names, etc.)?
+
+### 4. Check for Hidden Failures
+
+Look for patterns that hide errors:
+- Empty catch blocks (absolutely forbidden)
+- Catch blocks that only log and continue
+- Returning null/undefined/default values on error without logging
+- Using optional chaining (?.) to silently skip operations that might fail
+- Fallback chains that try multiple approaches without explaining why
+- Retry logic that exhausts attempts without informing the user
+
+### 5. Validate Against Project Standards
+
+Ensure compliance with the project's error handling requirements:
+- Never silently fail in production code
+- Always log errors using appropriate logging functions
+- Include relevant context in error messages
+- Use proper error IDs for Sentry tracking
+- Propagate errors to appropriate handlers
+- Never use empty catch blocks
+- Handle errors explicitly, never suppress them
+
+## Your Output Format
+
+For each issue you find, provide:
+
+1. **Location**: File path and line number(s)
+2. **Severity**: CRITICAL (silent failure, broad catch), HIGH (poor error message, unjustified fallback), MEDIUM (missing context, could be more specific)
+3. **Issue Description**: What's wrong and why it's problematic
+4. **Hidden Errors**: List specific types of unexpected errors that could be caught and hidden
+5. **User Impact**: How this affects the user experience and debugging
+6. **Recommendation**: Specific code changes needed to fix the issue
+7. **Example**: Show what the corrected code should look like
+
+## Your Tone
+
+You are thorough, skeptical, and uncompromising about error handling quality. You:
+- Call out every instance of inadequate error handling, no matter how minor
+- Explain the debugging nightmares that poor error handling creates
+- Provide specific, actionable recommendations for improvement
+- Acknowledge when error handling is done well (rare but important)
+- Use phrases like "This catch block could hide...", "Users will be confused when...", "This fallback masks the real problem..."
+- Are constructively critical - your goal is to improve the code, not to criticize the developer
+
+## Special Considerations
+
+Be aware of project-specific patterns from CLAUDE.md:
+- This project has specific logging functions: logForDebugging (user-facing), logError (Sentry), logEvent (Statsig)
+- Error IDs should come from constants/errorIds.ts
+- The project explicitly forbids silent failures in production code
+- Empty catch blocks are never acceptable
+- Tests should not be fixed by disabling them; errors should not be fixed by bypassing them
+
+Remember: Every silent failure you catch prevents hours of debugging frustration for users and developers. Be thorough, be skeptical, and never let an error slip through unnoticed.

plugins/pr-review-toolkit/agents/type-design-analyzer.md

@@ -0,0 +1,110 @@
+---
+name: type-design-analyzer
+description: Use this agent when you need expert analysis of type design in your codebase. Specifically use it: (1) when introducing a new type to ensure it follows best practices for encapsulation and invariant expression, (2) during pull request creation to review all types being added, (3) when refactoring existing types to improve their design quality. The agent will provide both qualitative feedback and quantitative ratings on encapsulation, invariant expression, usefulness, and enforcement.\n\n<example>\nContext: Daisy is writing code that introduces a new UserAccount type and wants to ensure it has well-designed invariants.\nuser: "I've just created a new UserAccount type that handles user authentication and permissions"\nassistant: "I'll use the type-design-analyzer agent to review the UserAccount type design"\n<commentary>\nSince a new type is being introduced, use the type-design-analyzer to ensure it has strong invariants and proper encapsulation.\n</commentary>\n</example>\n\n<example>\nContext: Daisy is creating a pull request and wants to review all newly added types.\nuser: "I'm about to create a PR with several new data model types"\nassistant: "Let me use the type-design-analyzer agent to review all the types being added in this PR"\n<commentary>\nDuring PR creation with new types, use the type-design-analyzer to review their design quality.\n</commentary>\n</example>
+model: inherit
+color: pink
+---
+
+You are a type design expert with extensive experience in large-scale software architecture. Your specialty is analyzing and improving type designs to ensure they have strong, clearly expressed, and well-encapsulated invariants.
+
+**Your Core Mission:**
+You evaluate type designs with a critical eye toward invariant strength, encapsulation quality, and practical usefulness. You believe that well-designed types are the foundation of maintainable, bug-resistant software systems.
+
+**Analysis Framework:**
+
+When analyzing a type, you will:
+
+1. **Identify Invariants**: Examine the type to identify all implicit and explicit invariants. Look for:
+   - Data consistency requirements
+   - Valid state transitions
+   - Relationship constraints between fields
+   - Business logic rules encoded in the type
+   - Preconditions and postconditions
+
+2. **Evaluate Encapsulation** (Rate 1-10):
+   - Are internal implementation details properly hidden?
+   - Can the type's invariants be violated from outside?
+   - Are there appropriate access modifiers?
+   - Is the interface minimal and complete?
+
+3. **Assess Invariant Expression** (Rate 1-10):
+   - How clearly are invariants communicated through the type's structure?
+   - Are invariants enforced at compile-time where possible?
+   - Is the type self-documenting through its design?
+   - Are edge cases and constraints obvious from the type definition?
+
+4. **Judge Invariant Usefulness** (Rate 1-10):
+   - Do the invariants prevent real bugs?
+   - Are they aligned with business requirements?
+   - Do they make the code easier to reason about?
+   - Are they neither too restrictive nor too permissive?
+
+5. **Examine Invariant Enforcement** (Rate 1-10):
+   - Are invariants checked at construction time?
+   - Are all mutation points guarded?
+   - Is it impossible to create invalid instances?
+   - Are runtime checks appropriate and comprehensive?
+
+**Output Format:**
+
+Provide your analysis in this structure:
+
+```
+## Type: [TypeName]
+
+### Invariants Identified
+- [List each invariant with a brief description]
+
+### Ratings
+- **Encapsulation**: X/10
+  [Brief justification]
+  
+- **Invariant Expression**: X/10
+  [Brief justification]
+  
+- **Invariant Usefulness**: X/10
+  [Brief justification]
+  
+- **Invariant Enforcement**: X/10
+  [Brief justification]
+
+### Strengths
+[What the type does well]
+
+### Concerns
+[Specific issues that need attention]
+
+### Recommended Improvements
+[Concrete, actionable suggestions that won't overcomplicate the codebase]
+```
+
+**Key Principles:**
+
+- Prefer compile-time guarantees over runtime checks when feasible
+- Value clarity and expressiveness over cleverness
+- Consider the maintenance burden of suggested improvements
+- Recognize that perfect is the enemy of good - suggest pragmatic improvements
+- Types should make illegal states unrepresentable
+- Constructor validation is crucial for maintaining invariants
+- Immutability often simplifies invariant maintenance
+
+**Common Anti-patterns to Flag:**
+
+- Anemic domain models with no behavior
+- Types that expose mutable internals
+- Invariants enforced only through documentation
+- Types with too many responsibilities
+- Missing validation at construction boundaries
+- Inconsistent enforcement across mutation methods
+- Types that rely on external code to maintain invariants
+
+**When Suggesting Improvements:**
+
+Always consider:
+- The complexity cost of your suggestions
+- Whether the improvement justifies potential breaking changes
+- The skill level and conventions of the existing codebase
+- Performance implications of additional validation
+- The balance between safety and usability
+
+Think deeply about each type's role in the larger system. Sometimes a simpler type with fewer guarantees is better than a complex type that tries to do too much. Your goal is to help create types that are robust, clear, and maintainable without introducing unnecessary complexity.

plugins/pr-review-toolkit/commands/review-pr.md

@@ -0,0 +1,189 @@
+---
+description: "Comprehensive PR review using specialized agents"
+argument-hint: "[review-aspects]"
+allowed-tools: ["Bash", "Glob", "Grep", "Read", "Task"]
+---
+
+# Comprehensive PR Review
+
+Run a comprehensive pull request review using multiple specialized agents, each focusing on a different aspect of code quality.
+
+**Review Aspects (optional):** "$ARGUMENTS"
+
+## Review Workflow:
+
+1. **Determine Review Scope**
+   - Check git status to identify changed files
+   - Parse arguments to see if user requested specific review aspects
+   - Default: Run all applicable reviews
+
+2. **Available Review Aspects:**
+
+   - **comments** - Analyze code comment accuracy and maintainability
+   - **tests** - Review test coverage quality and completeness
+   - **errors** - Check error handling for silent failures
+   - **types** - Analyze type design and invariants (if new types added)
+   - **code** - General code review for project guidelines
+   - **simplify** - Simplify code for clarity and maintainability
+   - **all** - Run all applicable reviews (default)
+
+3. **Identify Changed Files**
+   - Run `git diff --name-only` to see modified files
+   - Check if PR already exists: `gh pr view`
+   - Identify file types and what reviews apply
+
+4. **Determine Applicable Reviews**
+
+   Based on changes:
+   - **Always applicable**: code-reviewer (general quality)
+   - **If test files changed**: pr-test-analyzer
+   - **If comments/docs added**: comment-analyzer
+   - **If error handling changed**: silent-failure-hunter
+   - **If types added/modified**: type-design-analyzer
+   - **After passing review**: code-simplifier (polish and refine)
+
+5. **Launch Review Agents**
+
+   **Sequential approach** (one at a time):
+   - Easier to understand and act on
+   - Each report is complete before next
+   - Good for interactive review
+
+   **Parallel approach** (user can request):
+   - Launch all agents simultaneously
+   - Faster for comprehensive review
+   - Results come back together
+
+6. **Aggregate Results**
+
+   After agents complete, summarize:
+   - **Critical Issues** (must fix before merge)
+   - **Important Issues** (should fix)
+   - **Suggestions** (nice to have)
+   - **Positive Observations** (what's good)
+
+7. **Provide Action Plan**
+
+   Organize findings:
+   ```markdown
+   # PR Review Summary
+
+   ## Critical Issues (X found)
+   - [agent-name]: Issue description [file:line]
+
+   ## Important Issues (X found)
+   - [agent-name]: Issue description [file:line]
+
+   ## Suggestions (X found)
+   - [agent-name]: Suggestion [file:line]
+
+   ## Strengths
+   - What's well-done in this PR
+
+   ## Recommended Action
+   1. Fix critical issues first
+   2. Address important issues
+   3. Consider suggestions
+   4. Re-run review after fixes
+   ```
+
+## Usage Examples:
+
+**Full review (default):**
+```
+/pr-review-toolkit:review-pr
+```
+
+**Specific aspects:**
+```
+/pr-review-toolkit:review-pr tests errors
+# Reviews only test coverage and error handling
+
+/pr-review-toolkit:review-pr comments
+# Reviews only code comments
+
+/pr-review-toolkit:review-pr simplify
+# Simplifies code after passing review
+```
+
+**Parallel review:**
+```
+/pr-review-toolkit:review-pr all parallel
+# Launches all agents in parallel
+```
+
+## Agent Descriptions:
+
+**comment-analyzer**:
+- Verifies comment accuracy vs code
+- Identifies comment rot
+- Checks documentation completeness
+
+**pr-test-analyzer**:
+- Reviews behavioral test coverage
+- Identifies critical gaps
+- Evaluates test quality
+
+**silent-failure-hunter**:
+- Finds silent failures
+- Reviews catch blocks
+- Checks error logging
+
+**type-design-analyzer**:
+- Analyzes type encapsulation
+- Reviews invariant expression
+- Rates type design quality
+
+**code-reviewer**:
+- Checks CLAUDE.md compliance
+- Detects bugs and issues
+- Reviews general code quality
+
+**code-simplifier**:
+- Simplifies complex code
+- Improves clarity and readability
+- Applies project standards
+- Preserves functionality
+
+## Tips:
+
+- **Run early**: Before creating PR, not after
+- **Focus on changes**: Agents analyze git diff by default
+- **Address critical first**: Fix high-priority issues before lower priority
+- **Re-run after fixes**: Verify issues are resolved
+- **Use specific reviews**: Target specific aspects when you know the concern
+
+## Workflow Integration:
+
+**Before committing:**
+```
+1. Write code
+2. Run: /pr-review-toolkit:review-pr code errors
+3. Fix any critical issues
+4. Commit
+```
+
+**Before creating PR:**
+```
+1. Stage all changes
+2. Run: /pr-review-toolkit:review-pr all
+3. Address all critical and important issues
+4. Run specific reviews again to verify
+5. Create PR
+```
+
+**After PR feedback:**
+```
+1. Make requested changes
+2. Run targeted reviews based on feedback
+3. Verify issues are resolved
+4. Push updates
+```
+
+## Notes:
+
+- Agents run autonomously and return detailed reports
+- Each agent focuses on its specialty for deep analysis
+- Results are actionable with specific file:line references
+- Agents use appropriate models for their complexity
+- All agents available in `/agents` list

plugins/security-guidance/.claude-plugin/plugin.json

@@ -0,0 +1,9 @@
+{
+  "name": "security-guidance",
+  "version": "1.0.0",
+  "description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
+  "author": {
+    "name": "David Dworken",
+    "email": "dworken@anthropic.com"
+  }
+}

plugins/security-guidance/hooks/hooks.json

@@ -0,0 +1,16 @@
+{
+  "description": "Security reminder hook that warns about potential security issues when editing files",
+  "hooks": {
+    "PreToolUse": [
+      {
+        "hooks": [
+          {
+            "type": "command",
+            "command": "python3 ${CLAUDE_PLUGIN_ROOT}/hooks/security_reminder_hook.py"
+          }
+        ],
+        "matcher": "Edit|Write|MultiEdit"
+      }
+    ]
+  }
+}

plugins/security-guidance/hooks/security_reminder_hook.py

@@ -0,0 +1,280 @@
+#!/usr/bin/env python3
+"""
+Security Reminder Hook for Claude Code
+This hook checks for security patterns in file edits and warns about potential vulnerabilities.
+"""
+
+import json
+import os
+import random
+import sys
+from datetime import datetime
+
+# Debug log file
+DEBUG_LOG_FILE = "/tmp/security-warnings-log.txt"
+
+
+def debug_log(message):
+    """Append debug message to log file with timestamp."""
+    try:
+        timestamp = datetime.now().strftime("%Y-%m-%d %H:%M:%S.%f")[:-3]
+        with open(DEBUG_LOG_FILE, "a") as f:
+            f.write(f"[{timestamp}] {message}\n")
+    except Exception as e:
+        # Silently ignore logging errors to avoid disrupting the hook
+        pass
+
+
+# State file to track warnings shown (session-scoped using session ID)
+
+# Security patterns configuration
+SECURITY_PATTERNS = [
+    {
+        "ruleName": "github_actions_workflow",
+        "path_check": lambda path: ".github/workflows/" in path
+        and (path.endswith(".yml") or path.endswith(".yaml")),
+        "reminder": """You are editing a GitHub Actions workflow file. Be aware of these security risks:
+
+1. **Command Injection**: Never use untrusted input (like issue titles, PR descriptions, commit messages) directly in run: commands without proper escaping
+2. **Use environment variables**: Instead of ${{ github.event.issue.title }}, use env: with proper quoting
+3. **Review the guide**: https://github.blog/security/vulnerability-research/how-to-catch-github-actions-workflow-injections-before-attackers-do/
+
+Example of UNSAFE pattern to avoid:
+run: echo "${{ github.event.issue.title }}"
+
+Example of SAFE pattern:
+env:
+  TITLE: ${{ github.event.issue.title }}
+run: echo "$TITLE"
+
+Other risky inputs to be careful with:
+- github.event.issue.body
+- github.event.pull_request.title
+- github.event.pull_request.body
+- github.event.comment.body
+- github.event.review.body
+- github.event.review_comment.body
+- github.event.pages.*.page_name
+- github.event.commits.*.message
+- github.event.head_commit.message
+- github.event.head_commit.author.email
+- github.event.head_commit.author.name
+- github.event.commits.*.author.email
+- github.event.commits.*.author.name
+- github.event.pull_request.head.ref
+- github.event.pull_request.head.label
+- github.event.pull_request.head.repo.default_branch
+- github.head_ref""",
+    },
+    {
+        "ruleName": "child_process_exec",
+        "substrings": ["child_process.exec", "exec(", "execSync("],
+        "reminder": """⚠️ Security Warning: Using child_process.exec() can lead to command injection vulnerabilities.
+
+This codebase provides a safer alternative: src/utils/execFileNoThrow.ts
+
+Instead of:
+  exec(`command ${userInput}`)
+
+Use:
+  import { execFileNoThrow } from '../utils/execFileNoThrow.js'
+  await execFileNoThrow('command', [userInput])
+
+The execFileNoThrow utility:
+- Uses execFile instead of exec (prevents shell injection)
+- Handles Windows compatibility automatically
+- Provides proper error handling
+- Returns structured output with stdout, stderr, and status
+
+Only use exec() if you absolutely need shell features and the input is guaranteed to be safe.""",
+    },
+    {
+        "ruleName": "new_function_injection",
+        "substrings": ["new Function"],
+        "reminder": "⚠️ Security Warning: Using new Function() with dynamic strings can lead to code injection vulnerabilities. Consider alternative approaches that don't evaluate arbitrary code. Only use new Function() if you truly need to evaluate arbitrary dynamic code.",
+    },
+    {
+        "ruleName": "eval_injection",
+        "substrings": ["eval("],
+        "reminder": "⚠️ Security Warning: eval() executes arbitrary code and is a major security risk. Consider using JSON.parse() for data parsing or alternative design patterns that don't require code evaluation. Only use eval() if you truly need to evaluate arbitrary code.",
+    },
+    {
+        "ruleName": "react_dangerously_set_html",
+        "substrings": ["dangerouslySetInnerHTML"],
+        "reminder": "⚠️ Security Warning: dangerouslySetInnerHTML can lead to XSS vulnerabilities if used with untrusted content. Ensure all content is properly sanitized using an HTML sanitizer library like DOMPurify, or use safe alternatives.",
+    },
+    {
+        "ruleName": "document_write_xss",
+        "substrings": ["document.write"],
+        "reminder": "⚠️ Security Warning: document.write() can be exploited for XSS attacks and has performance issues. Use DOM manipulation methods like createElement() and appendChild() instead.",
+    },
+    {
+        "ruleName": "innerHTML_xss",
+        "substrings": [".innerHTML =", ".innerHTML="],
+        "reminder": "⚠️ Security Warning: Setting innerHTML with untrusted content can lead to XSS vulnerabilities. Use textContent for plain text or safe DOM methods for HTML content. If you need HTML support, consider using an HTML sanitizer library such as DOMPurify.",
+    },
+    {
+        "ruleName": "pickle_deserialization",
+        "substrings": ["pickle"],
+        "reminder": "⚠️ Security Warning: Using pickle with untrusted content can lead to arbitrary code execution. Consider using JSON or other safe serialization formats instead. Only use pickle if it is explicitly needed or requested by the user.",
+    },
+    {
+        "ruleName": "os_system_injection",
+        "substrings": ["os.system", "from os import system"],
+        "reminder": "⚠️ Security Warning: This code appears to use os.system. This should only be used with static arguments and never with arguments that could be user-controlled.",
+    },
+]
+
+
+def get_state_file(session_id):
+    """Get session-specific state file path."""
+    return os.path.expanduser(f"~/.claude/security_warnings_state_{session_id}.json")
+
+
+def cleanup_old_state_files():
+    """Remove state files older than 30 days."""
+    try:
+        state_dir = os.path.expanduser("~/.claude")
+        if not os.path.exists(state_dir):
+            return
+
+        current_time = datetime.now().timestamp()
+        thirty_days_ago = current_time - (30 * 24 * 60 * 60)
+
+        for filename in os.listdir(state_dir):
+            if filename.startswith("security_warnings_state_") and filename.endswith(
+                ".json"
+            ):
+                file_path = os.path.join(state_dir, filename)
+                try:
+                    file_mtime = os.path.getmtime(file_path)
+                    if file_mtime < thirty_days_ago:
+                        os.remove(file_path)
+                except (OSError, IOError):
+                    pass  # Ignore errors for individual file cleanup
+    except Exception:
+        pass  # Silently ignore cleanup errors
+
+
+def load_state(session_id):
+    """Load the state of shown warnings from file."""
+    state_file = get_state_file(session_id)
+    if os.path.exists(state_file):
+        try:
+            with open(state_file, "r") as f:
+                return set(json.load(f))
+        except (json.JSONDecodeError, IOError):
+            return set()
+    return set()
+
+
+def save_state(session_id, shown_warnings):
+    """Save the state of shown warnings to file."""
+    state_file = get_state_file(session_id)
+    try:
+        os.makedirs(os.path.dirname(state_file), exist_ok=True)
+        with open(state_file, "w") as f:
+            json.dump(list(shown_warnings), f)
+    except IOError as e:
+        debug_log(f"Failed to save state file: {e}")
+        pass  # Fail silently if we can't save state
+
+
+def check_patterns(file_path, content):
+    """Check if file path or content matches any security patterns."""
+    # Normalize path by removing leading slashes
+    normalized_path = file_path.lstrip("/")
+
+    for pattern in SECURITY_PATTERNS:
+        # Check path-based patterns
+        if "path_check" in pattern and pattern["path_check"](normalized_path):
+            return pattern["ruleName"], pattern["reminder"]
+
+        # Check content-based patterns
+        if "substrings" in pattern and content:
+            for substring in pattern["substrings"]:
+                if substring in content:
+                    return pattern["ruleName"], pattern["reminder"]
+
+    return None, None
+
+
+def extract_content_from_input(tool_name, tool_input):
+    """Extract content to check from tool input based on tool type."""
+    if tool_name == "Write":
+        return tool_input.get("content", "")
+    elif tool_name == "Edit":
+        return tool_input.get("new_string", "")
+    elif tool_name == "MultiEdit":
+        edits = tool_input.get("edits", [])
+        if edits:
+            return " ".join(edit.get("new_string", "") for edit in edits)
+        return ""
+
+    return ""
+
+
+def main():
+    """Main hook function."""
+    # Check if security reminders are enabled
+    security_reminder_enabled = os.environ.get("ENABLE_SECURITY_REMINDER", "1")
+
+    # Only run if security reminders are enabled
+    if security_reminder_enabled == "0":
+        sys.exit(0)
+
+    # Periodically clean up old state files (10% chance per run)
+    if random.random() < 0.1:
+        cleanup_old_state_files()
+
+    # Read input from stdin
+    try:
+        raw_input = sys.stdin.read()
+        input_data = json.loads(raw_input)
+    except json.JSONDecodeError as e:
+        debug_log(f"JSON decode error: {e}")
+        sys.exit(0)  # Allow tool to proceed if we can't parse input
+
+    # Extract session ID and tool information from the hook input
+    session_id = input_data.get("session_id", "default")
+    tool_name = input_data.get("tool_name", "")
+    tool_input = input_data.get("tool_input", {})
+
+    # Check if this is a relevant tool
+    if tool_name not in ["Edit", "Write", "MultiEdit"]:
+        sys.exit(0)  # Allow non-file tools to proceed
+
+    # Extract file path from tool_input
+    file_path = tool_input.get("file_path", "")
+    if not file_path:
+        sys.exit(0)  # Allow if no file path
+
+    # Extract content to check
+    content = extract_content_from_input(tool_name, tool_input)
+
+    # Check for security patterns
+    rule_name, reminder = check_patterns(file_path, content)
+
+    if rule_name and reminder:
+        # Create unique warning key
+        warning_key = f"{file_path}-{rule_name}"
+
+        # Load existing warnings for this session
+        shown_warnings = load_state(session_id)
+
+        # Check if we've already shown this warning in this session
+        if warning_key not in shown_warnings:
+            # Add to shown warnings and save
+            shown_warnings.add(warning_key)
+            save_state(session_id, shown_warnings)
+
+            # Output the warning to stderr and block execution
+            print(reminder, file=sys.stderr)
+            sys.exit(2)  # Block tool execution (exit code 2 for PreToolUse hooks)
+
+    # Allow tool to proceed
+    sys.exit(0)
+
+
+if __name__ == "__main__":
+    main()

scripts/auto-close-duplicates.ts

@@ -0,0 +1,277 @@
+#!/usr/bin/env bun
+
+declare global {
+  var process: {
+    env: Record<string, string | undefined>;
+  };
+}
+
+interface GitHubIssue {
+  number: number;
+  title: string;
+  user: { id: number };
+  created_at: string;
+}
+
+interface GitHubComment {
+  id: number;
+  body: string;
+  created_at: string;
+  user: { type: string; id: number };
+}
+
+interface GitHubReaction {
+  user: { id: number };
+  content: string;
+}
+
+async function githubRequest<T>(endpoint: string, token: string, method: string = 'GET', body?: any): Promise<T> {
+  const response = await fetch(`https://api.github.com${endpoint}`, {
+    method,
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "User-Agent": "auto-close-duplicates-script",
+      ...(body && { "Content-Type": "application/json" }),
+    },
+    ...(body && { body: JSON.stringify(body) }),
+  });
+
+  if (!response.ok) {
+    throw new Error(
+      `GitHub API request failed: ${response.status} ${response.statusText}`
+    );
+  }
+
+  return response.json();
+}
+
+function extractDuplicateIssueNumber(commentBody: string): number | null {
+  // Try to match #123 format first
+  let match = commentBody.match(/#(\d+)/);
+  if (match) {
+    return parseInt(match[1], 10);
+  }
+  
+  // Try to match GitHub issue URL format: https://github.com/owner/repo/issues/123
+  match = commentBody.match(/github\.com\/[^\/]+\/[^\/]+\/issues\/(\d+)/);
+  if (match) {
+    return parseInt(match[1], 10);
+  }
+  
+  return null;
+}
+
+
+async function closeIssueAsDuplicate(
+  owner: string,
+  repo: string,
+  issueNumber: number,
+  duplicateOfNumber: number,
+  token: string
+): Promise<void> {
+  await githubRequest(
+    `/repos/${owner}/${repo}/issues/${issueNumber}`,
+    token,
+    'PATCH',
+    {
+      state: 'closed',
+      state_reason: 'duplicate',
+      labels: ['duplicate']
+    }
+  );
+
+  await githubRequest(
+    `/repos/${owner}/${repo}/issues/${issueNumber}/comments`,
+    token,
+    'POST',
+    {
+      body: `This issue has been automatically closed as a duplicate of #${duplicateOfNumber}.
+
+If this is incorrect, please re-open this issue or create a new one.
+
+🤖 Generated with [Claude Code](https://claude.ai/code)`
+    }
+  );
+
+}
+
+async function autoCloseDuplicates(): Promise<void> {
+  console.log("[DEBUG] Starting auto-close duplicates script");
+
+  const token = process.env.GITHUB_TOKEN;
+  if (!token) {
+    throw new Error("GITHUB_TOKEN environment variable is required");
+  }
+  console.log("[DEBUG] GitHub token found");
+
+  const owner = process.env.GITHUB_REPOSITORY_OWNER || "anthropics";
+  const repo = process.env.GITHUB_REPOSITORY_NAME || "claude-code";
+  console.log(`[DEBUG] Repository: ${owner}/${repo}`);
+
+  const threeDaysAgo = new Date();
+  threeDaysAgo.setDate(threeDaysAgo.getDate() - 3);
+  console.log(
+    `[DEBUG] Checking for duplicate comments older than: ${threeDaysAgo.toISOString()}`
+  );
+
+  console.log("[DEBUG] Fetching open issues created more than 3 days ago...");
+  const allIssues: GitHubIssue[] = [];
+  let page = 1;
+  const perPage = 100;
+  
+  while (true) {
+    const pageIssues: GitHubIssue[] = await githubRequest(
+      `/repos/${owner}/${repo}/issues?state=open&per_page=${perPage}&page=${page}`,
+      token
+    );
+    
+    if (pageIssues.length === 0) break;
+    
+    // Filter for issues created more than 3 days ago
+    const oldEnoughIssues = pageIssues.filter(issue => 
+      new Date(issue.created_at) <= threeDaysAgo
+    );
+    
+    allIssues.push(...oldEnoughIssues);
+    page++;
+    
+    // Safety limit to avoid infinite loops
+    if (page > 20) break;
+  }
+  
+  const issues = allIssues;
+  console.log(`[DEBUG] Found ${issues.length} open issues`);
+
+  let processedCount = 0;
+  let candidateCount = 0;
+
+  for (const issue of issues) {
+    processedCount++;
+    console.log(
+      `[DEBUG] Processing issue #${issue.number} (${processedCount}/${issues.length}): ${issue.title}`
+    );
+
+    console.log(`[DEBUG] Fetching comments for issue #${issue.number}...`);
+    const comments: GitHubComment[] = await githubRequest(
+      `/repos/${owner}/${repo}/issues/${issue.number}/comments`,
+      token
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} has ${comments.length} comments`
+    );
+
+    const dupeComments = comments.filter(
+      (comment) =>
+        comment.body.includes("Found") &&
+        comment.body.includes("possible duplicate") &&
+        comment.user.type === "Bot"
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} has ${dupeComments.length} duplicate detection comments`
+    );
+
+    if (dupeComments.length === 0) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} - no duplicate comments found, skipping`
+      );
+      continue;
+    }
+
+    const lastDupeComment = dupeComments[dupeComments.length - 1];
+    const dupeCommentDate = new Date(lastDupeComment.created_at);
+    console.log(
+      `[DEBUG] Issue #${
+        issue.number
+      } - most recent duplicate comment from: ${dupeCommentDate.toISOString()}`
+    );
+
+    if (dupeCommentDate > threeDaysAgo) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} - duplicate comment is too recent, skipping`
+      );
+      continue;
+    }
+    console.log(
+      `[DEBUG] Issue #${
+        issue.number
+      } - duplicate comment is old enough (${Math.floor(
+        (Date.now() - dupeCommentDate.getTime()) / (1000 * 60 * 60 * 24)
+      )} days)`
+    );
+
+    const commentsAfterDupe = comments.filter(
+      (comment) => new Date(comment.created_at) > dupeCommentDate
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} - ${commentsAfterDupe.length} comments after duplicate detection`
+    );
+
+    if (commentsAfterDupe.length > 0) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} - has activity after duplicate comment, skipping`
+      );
+      continue;
+    }
+
+    console.log(
+      `[DEBUG] Issue #${issue.number} - checking reactions on duplicate comment...`
+    );
+    const reactions: GitHubReaction[] = await githubRequest(
+      `/repos/${owner}/${repo}/issues/comments/${lastDupeComment.id}/reactions`,
+      token
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} - duplicate comment has ${reactions.length} reactions`
+    );
+
+    const authorThumbsDown = reactions.some(
+      (reaction) =>
+        reaction.user.id === issue.user.id && reaction.content === "-1"
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} - author thumbs down reaction: ${authorThumbsDown}`
+    );
+
+    if (authorThumbsDown) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} - author disagreed with duplicate detection, skipping`
+      );
+      continue;
+    }
+
+    const duplicateIssueNumber = extractDuplicateIssueNumber(lastDupeComment.body);
+    if (!duplicateIssueNumber) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} - could not extract duplicate issue number from comment, skipping`
+      );
+      continue;
+    }
+
+    candidateCount++;
+    const issueUrl = `https://github.com/${owner}/${repo}/issues/${issue.number}`;
+    
+    try {
+      console.log(
+        `[INFO] Auto-closing issue #${issue.number} as duplicate of #${duplicateIssueNumber}: ${issueUrl}`
+      );
+      await closeIssueAsDuplicate(owner, repo, issue.number, duplicateIssueNumber, token);
+      console.log(
+        `[SUCCESS] Successfully closed issue #${issue.number} as duplicate of #${duplicateIssueNumber}`
+      );
+    } catch (error) {
+      console.error(
+        `[ERROR] Failed to close issue #${issue.number} as duplicate: ${error}`
+      );
+    }
+  }
+
+  console.log(
+    `[DEBUG] Script completed. Processed ${processedCount} issues, found ${candidateCount} candidates for auto-close`
+  );
+}
+
+autoCloseDuplicates().catch(console.error);
+
+// Make it a module
+export {};

scripts/backfill-duplicate-comments.ts

@@ -0,0 +1,213 @@
+#!/usr/bin/env bun
+
+declare global {
+  var process: {
+    env: Record<string, string | undefined>;
+  };
+}
+
+interface GitHubIssue {
+  number: number;
+  title: string;
+  state: string;
+  state_reason?: string;
+  user: { id: number };
+  created_at: string;
+  closed_at?: string;
+}
+
+interface GitHubComment {
+  id: number;
+  body: string;
+  created_at: string;
+  user: { type: string; id: number };
+}
+
+async function githubRequest<T>(endpoint: string, token: string, method: string = 'GET', body?: any): Promise<T> {
+  const response = await fetch(`https://api.github.com${endpoint}`, {
+    method,
+    headers: {
+      Authorization: `Bearer ${token}`,
+      Accept: "application/vnd.github.v3+json",
+      "User-Agent": "backfill-duplicate-comments-script",
+      ...(body && { "Content-Type": "application/json" }),
+    },
+    ...(body && { body: JSON.stringify(body) }),
+  });
+
+  if (!response.ok) {
+    throw new Error(
+      `GitHub API request failed: ${response.status} ${response.statusText}`
+    );
+  }
+
+  return response.json();
+}
+
+async function triggerDedupeWorkflow(
+  owner: string,
+  repo: string,
+  issueNumber: number,
+  token: string,
+  dryRun: boolean = true
+): Promise<void> {
+  if (dryRun) {
+    console.log(`[DRY RUN] Would trigger dedupe workflow for issue #${issueNumber}`);
+    return;
+  }
+
+  await githubRequest(
+    `/repos/${owner}/${repo}/actions/workflows/claude-dedupe-issues.yml/dispatches`,
+    token,
+    'POST',
+    {
+      ref: 'main',
+      inputs: {
+        issue_number: issueNumber.toString()
+      }
+    }
+  );
+}
+
+async function backfillDuplicateComments(): Promise<void> {
+  console.log("[DEBUG] Starting backfill duplicate comments script");
+
+  const token = process.env.GITHUB_TOKEN;
+  if (!token) {
+    throw new Error(`GITHUB_TOKEN environment variable is required
+
+Usage:
+  GITHUB_TOKEN=your_token bun run scripts/backfill-duplicate-comments.ts
+
+Environment Variables:
+  GITHUB_TOKEN - GitHub personal access token with repo and actions permissions (required)
+  DRY_RUN - Set to "false" to actually trigger workflows (default: true for safety)
+  MAX_ISSUE_NUMBER - Only process issues with numbers less than this value (default: 4050)`);
+  }
+  console.log("[DEBUG] GitHub token found");
+
+  const owner = "anthropics";
+  const repo = "claude-code";
+  const dryRun = process.env.DRY_RUN !== "false";
+  const maxIssueNumber = parseInt(process.env.MAX_ISSUE_NUMBER || "4050", 10);
+  const minIssueNumber = parseInt(process.env.MIN_ISSUE_NUMBER || "1", 10);
+  
+  console.log(`[DEBUG] Repository: ${owner}/${repo}`);
+  console.log(`[DEBUG] Dry run mode: ${dryRun}`);
+  console.log(`[DEBUG] Looking at issues between #${minIssueNumber} and #${maxIssueNumber}`);
+
+  console.log(`[DEBUG] Fetching issues between #${minIssueNumber} and #${maxIssueNumber}...`);
+  const allIssues: GitHubIssue[] = [];
+  let page = 1;
+  const perPage = 100;
+  
+  while (true) {
+    const pageIssues: GitHubIssue[] = await githubRequest(
+      `/repos/${owner}/${repo}/issues?state=all&per_page=${perPage}&page=${page}&sort=created&direction=desc`,
+      token
+    );
+    
+    if (pageIssues.length === 0) break;
+    
+    // Filter to only include issues within the specified range
+    const filteredIssues = pageIssues.filter(issue => 
+      issue.number >= minIssueNumber && issue.number < maxIssueNumber
+    );
+    allIssues.push(...filteredIssues);
+    
+    // If the oldest issue in this page is still above our minimum, we need to continue
+    // but if the oldest issue is below our minimum, we can stop
+    const oldestIssueInPage = pageIssues[pageIssues.length - 1];
+    if (oldestIssueInPage && oldestIssueInPage.number >= maxIssueNumber) {
+      console.log(`[DEBUG] Oldest issue in page #${page} is #${oldestIssueInPage.number}, continuing...`);
+    } else if (oldestIssueInPage && oldestIssueInPage.number < minIssueNumber) {
+      console.log(`[DEBUG] Oldest issue in page #${page} is #${oldestIssueInPage.number}, below minimum, stopping`);
+      break;
+    } else if (filteredIssues.length === 0 && pageIssues.length > 0) {
+      console.log(`[DEBUG] No issues in page #${page} are in range #${minIssueNumber}-#${maxIssueNumber}, continuing...`);
+    }
+    
+    page++;
+    
+    // Safety limit to avoid infinite loops
+    if (page > 200) {
+      console.log("[DEBUG] Reached page limit, stopping pagination");
+      break;
+    }
+  }
+  
+  console.log(`[DEBUG] Found ${allIssues.length} issues between #${minIssueNumber} and #${maxIssueNumber}`);
+
+  let processedCount = 0;
+  let candidateCount = 0;
+  let triggeredCount = 0;
+
+  for (const issue of allIssues) {
+    processedCount++;
+    console.log(
+      `[DEBUG] Processing issue #${issue.number} (${processedCount}/${allIssues.length}): ${issue.title}`
+    );
+
+    console.log(`[DEBUG] Fetching comments for issue #${issue.number}...`);
+    const comments: GitHubComment[] = await githubRequest(
+      `/repos/${owner}/${repo}/issues/${issue.number}/comments`,
+      token
+    );
+    console.log(
+      `[DEBUG] Issue #${issue.number} has ${comments.length} comments`
+    );
+
+    // Look for existing duplicate detection comments (from the dedupe bot)
+    const dupeDetectionComments = comments.filter(
+      (comment) =>
+        comment.body.includes("Found") &&
+        comment.body.includes("possible duplicate") &&
+        comment.user.type === "Bot"
+    );
+
+    console.log(
+      `[DEBUG] Issue #${issue.number} has ${dupeDetectionComments.length} duplicate detection comments`
+    );
+
+    // Skip if there's already a duplicate detection comment
+    if (dupeDetectionComments.length > 0) {
+      console.log(
+        `[DEBUG] Issue #${issue.number} already has duplicate detection comment, skipping`
+      );
+      continue;
+    }
+
+    candidateCount++;
+    const issueUrl = `https://github.com/${owner}/${repo}/issues/${issue.number}`;
+    
+    try {
+      console.log(
+        `[INFO] ${dryRun ? '[DRY RUN] ' : ''}Triggering dedupe workflow for issue #${issue.number}: ${issueUrl}`
+      );
+      await triggerDedupeWorkflow(owner, repo, issue.number, token, dryRun);
+      
+      if (!dryRun) {
+        console.log(
+          `[SUCCESS] Successfully triggered dedupe workflow for issue #${issue.number}`
+        );
+      }
+      triggeredCount++;
+    } catch (error) {
+      console.error(
+        `[ERROR] Failed to trigger workflow for issue #${issue.number}: ${error}`
+      );
+    }
+
+    // Add a delay between workflow triggers to avoid overwhelming the system
+    await new Promise(resolve => setTimeout(resolve, 1000));
+  }
+
+  console.log(
+    `[DEBUG] Script completed. Processed ${processedCount} issues, found ${candidateCount} candidates without duplicate comments, ${dryRun ? 'would trigger' : 'triggered'} ${triggeredCount} workflows`
+  );
+}
+
+backfillDuplicateComments().catch(console.error);
+
+// Make it a module
+export {};