Compare commits

...

62 Commits

Author SHA1 Message Date
Boris Cherny
2d0fcacc05 Update code-review.md to avoid flagging test failures 2025-11-09 13:04:12 -08:00
GitHub Actions
1fe9e369a7 chore: Update CHANGELOG.md 2025-11-07 22:00:42 +00:00
GitHub Actions
b95fa46499 chore: Update CHANGELOG.md 2025-11-06 21:04:19 +00:00
GitHub Actions
7a05427a4b chore: Update CHANGELOG.md 2025-11-05 21:07:53 +00:00
GitHub Actions
84b97165dd chore: Update CHANGELOG.md 2025-11-04 22:34:37 +00:00
GitHub Actions
07dcea57ee chore: Update CHANGELOG.md 2025-11-04 00:57:10 +00:00
Boris Cherny
b42fd9928c Merge pull request #10830 from anthropics/boris/pumg
Add explanatory-output-style and learning-output-style plugins to marketplace
2025-11-01 16:26:53 -07:00
Boris Cherny
128de2a75d 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>
2025-11-01 16:15:21 -07:00
Boris Cherny
b8a98a8df7 Merge pull request #10826 from anthropics/boris/rmbx
feat: Add learning-output-style plugin
2025-11-01 15:55:57 -07:00
claude[bot]
ba49573fe1 feat: Incorporate explanatory functionality into learning-output-style plugin
- Update session-start.sh to include explanatory insights alongside learning mode
- Add educational insight formatting with ★ Insight sections
- Update README.md to clarify differences from unshipped Learning output style
- Document that this plugin now combines both learning and explanatory functionality
- Address review feedback about incorporating explanatory-output-style features

Co-authored-by: Boris Cherny <bcherny@users.noreply.github.com>
2025-11-01 22:37:17 +00:00
Boris Cherny
015808d89c feat: Add learning-output-style plugin
Add interactive learning mode plugin that requests meaningful code contributions at decision points. Based on the unshipped Learning output style, this plugin engages users in active learning by having them write 5-10 lines of code for business logic, error handling, and design decisions.

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-11-01 15:26:34 -07:00
GitHub Actions
ae411f8461 chore: Update CHANGELOG.md 2025-11-01 00:47:17 +00:00
GitHub Actions
4310085cb5 chore: Update CHANGELOG.md 2025-10-31 23:27:06 +00:00
GitHub Actions
c509821adc chore: Update CHANGELOG.md 2025-10-31 21:57:10 +00:00
GitHub Actions
d9aa4cf649 chore: Update CHANGELOG.md 2025-10-31 16:02:25 +00:00
GitHub Actions
b935da77db chore: Update CHANGELOG.md 2025-10-30 23:32:01 +00:00
Dickson Tsai
0c7d02b56f Merge pull request #10495 from anthropics/dickson/explanatory-output-style
Implement Explanatory output style as a plugin
2025-10-29 11:04:44 -07:00
Dickson Tsai
8b47e224a0 Editorial changes 2025-10-29 08:37:48 -07:00
Dickson Tsai
21bbc9f250 Merge pull request #10445 from stbenjam/lints
Add missing plugin.json files to fix claudelint errors
2025-10-29 08:19:27 -07:00
Catherine Wu
7add6863a0 Merge pull request #10076 from anthropics/add-oncall-triage-workflow
Add oncall triage slash command for issue management
2025-10-28 20:12:35 -07:00
Cat Wu
5484a86d28 Increase oncall triage engagement threshold to 50
Updates the oncall triage automation to require 50+ engagements
(comments + reactions) before applying the oncall label, making the
criteria more conservative to focus on the most critical issues.

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-28 20:04:53 -07:00
Dickson Tsai
10e1d3fe77 Implement a plugin as alternative for deprecated Explanatory output style 2025-10-28 02:39:56 -07:00
GitHub Actions
4dc23d0275 chore: Update CHANGELOG.md 2025-10-28 00:45:49 +00:00
GitHub Actions
8077cdc68c chore: Update CHANGELOG.md 2025-10-27 21:29:34 +00:00
Stephen Benjamin
207b22de65 Add missing plugin.json files to fix claudelint errors
Added plugin metadata files for code-review and commit-commands plugins
to comply with Claude plugin structure requirements. These files were
identified as missing by the [claudelint](https://github.com/stbenjam/claudelint)
tool, which validates plugin structure and format according to the Claude
Code plugin conventions.
2025-10-27 12:49:45 -04:00
Ashwin Bhat
52fea66ba5 Update code-review.md (#10358) 2025-10-25 21:58:21 -07:00
Wanghong Yuan
4e417747c5 Merge pull request #10227 from anthropics/add-code-review-plugin
Add code-review plugin for automated PR reviews
2025-10-24 15:38:33 -07:00
GitHub Actions
1b41969c71 chore: Update CHANGELOG.md 2025-10-24 22:04:57 +00:00
Wanghong Yuan MacBook
e9af4d7c1d rm gh api 2025-10-24 13:08:13 -07:00
Wanghong Yuan MacBook
48a8bfc2b1 Add code-review plugin to marketplace.json
Added marketplace entry for the code-review plugin, which provides automated PR review using multiple specialized agents with confidence-based scoring.

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-23 23:35:40 -07:00
Wanghong Yuan MacBook
546f0b46ac Add code-review plugin with automated PR review workflow
Add new code-review plugin that provides automated pull request reviews using multiple specialized agents with confidence-based scoring to filter false positives.

Key features:
- Multiple parallel agents for independent auditing (CLAUDE.md compliance, bug detection, historical context)
- Confidence-based scoring (0-100) with 80+ threshold to filter false positives
- Automatic skipping of closed, draft, or already-reviewed PRs
- Links directly to code with full SHA and line ranges

Updates:
- Add code-review plugin directory with command and README
- Update plugins/README.md to document the new plugin

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-23 23:11:44 -07:00
GitHub Actions
3be7215354 chore: Update CHANGELOG.md 2025-10-21 21:34:34 +00:00
Cat Wu
5d0e5cf15f Add oncall triage slash command for issue management
Creates a new /oncall-triage command that automates the process of triaging GitHub issues and labeling critical ones for oncall attention.

The command:
- Fetches open bugs updated in last 3 days with 5+ engagements
- Systematically evaluates each issue for blocking severity
- Adds "oncall" label to truly blocking issues
- Provides summary of all issues that received the label

Includes guidance to use individual gh commands instead of bash loops to avoid approval prompts.

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-21 13:44:18 -07:00
Catherine Wu
71bb75e3b5 Merge pull request #10023 from anthropics/add-oncall-triage-workflow
Add automated oncall triage workflow
2025-10-21 09:49:49 -07:00
Catherine Wu
1b827ad951 Merge pull request #10024 from anthropics/claude/investigate-workflow-config-011CUKnhpbage9BLno96Adg1
feat: upgrade GitHub workflows to use Claude Sonnet 4.5
2025-10-21 09:49:40 -07:00
Cat Wu
113ea425ac Add automated oncall triage workflow
Implements a GitHub Actions workflow that automatically identifies and labels critical blocking issues requiring oncall attention.

Features:
- Runs every 6 hours via cron schedule
- Fetches open issues updated in the last 3 days (5 per page to avoid context overflow)
- Orders by UPDATED_AT DESC and stops when hitting issues older than 3 days
- Evaluates each issue for bug status, engagement level (5+), and blocking severity
- Uses LLM comprehension to determine true blocking impact, not keyword matching
- Applies "oncall" label to qualifying issues via GitHub MCP tools
- Provides detailed summary including processed count, labeled issues, and close calls

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-20 23:13:36 -07:00
Claude
70cb0d1016 feat: upgrade GitHub workflows to use Claude Sonnet 4.5
Update all Claude Code GitHub Action workflows to use the latest Sonnet 4.5 model (claude-sonnet-4-5-20250929) instead of the default Sonnet 4.0 model. This provides improved performance and capabilities for:
- Issue commenting and PR reviews (claude.yml)
- Automated issue triage (claude-issue-triage.yml)
- Duplicate issue detection (claude-dedupe-issues.yml)

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-10-21 05:30:35 +00:00
GitHub Actions
ff0aafa946 chore: Update CHANGELOG.md 2025-10-20 22:56:31 +00:00
GitHub Actions
fb9d9169a0 chore: Update CHANGELOG.md 2025-10-18 00:27:28 +00:00
Ashwin Bhat
cabd74fa9e docs: Add comprehensive plugin documentation (#9797)
- Add plugins section to main README with link to detailed docs
- Create plugins/README.md with overview of all available plugins
- Add detailed READMEs for agent-sdk-dev, commit-commands, and feature-dev plugins
- Document all commands, agents, usage patterns, and workflows

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

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-17 16:44:48 -07:00
GitHub Actions
0ea180e55e chore: Update CHANGELOG.md 2025-10-17 22:26:06 +00:00
GitHub Actions
b4b858a115 chore: Update CHANGELOG.md 2025-10-16 16:48:05 +00:00
GitHub Actions
25f5057c37 chore: Update CHANGELOG.md 2025-10-15 22:26:23 +00:00
GitHub Actions
6dd90b2b89 chore: Update CHANGELOG.md 2025-10-15 20:16:40 +00:00
GitHub Actions
32d0be96e3 chore: Update CHANGELOG.md 2025-10-15 16:54:54 +00:00
GitHub Actions
5096c85c4a chore: Update CHANGELOG.md 2025-10-14 17:47:02 +00:00
GitHub Actions
24aa2626cc chore: Update CHANGELOG.md 2025-10-10 21:16:29 +00:00
Ashwin Bhat
a6e0921729 Revert "Add stale issue management workflows" (#9304) 2025-10-10 09:02:03 -07:00
GitHub Actions
8462b0700b chore: Update CHANGELOG.md 2025-10-09 17:50:27 +00:00
Ashwin Bhat
88d3666b7f Remove model specification from new-sdk-app command (#9232)
The model field is no longer needed in the command frontmatter as model selection is now handled at a different level.

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

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-09 10:11:08 -07:00
Ashwin Bhat
87a3b338c6 refactor: Update agent-sdk-dev plugin structure and configuration (#9230)
- Move plugin.json to .claude-plugin directory to match pr-review-toolkit pattern
- Add author information: Ashwin Bhat (ashwin@anthropic.com)
- Update model field from sonnet-4.5 to sonnet in all agent/command definitions

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

Co-authored-by: Claude <noreply@anthropic.com>
2025-10-09 09:56:12 -07:00
David Dworken
c6a1c392d7 Merge pull request #9231 from ddworken/dworken/marketplace
feat: add security-guidance plugin to marketplace.json
2025-10-09 09:52:58 -07:00
David Dworken
559db46b72 feat: add security-guidance plugin to marketplace.json 2025-10-09 09:50:34 -07:00
Sid Bidasaria
3139f287fb Merge pull request #9229 from anthropics/sidb/fix-feature-dev-agents
fix: agent model idenitifer names
2025-10-09 09:45:32 -07:00
Sid Bidasaria
00f53cb2cb fix: agent model idenitifer names 2025-10-09 09:44:24 -07:00
GitHub Actions
af073adcd1 chore: Update CHANGELOG.md 2025-10-09 16:32:49 +00:00
Sid Bidasaria
b03aea4649 Merge pull request #9226 from anthropics/sidb/feature-dev
feat: add feature-dev plugin
2025-10-09 09:31:28 -07:00
Sid Bidasaria
5cff78741f feat: add feature-dev to public marketplace 2025-10-09 09:29:11 -07:00
Daisy S. Hollman
8d1be7bc48 Merge pull request #6369 from anthropics/ashwin/taskreaper
Add stale issue management workflows
2025-10-09 09:19:00 -07:00
David Dworken
f876b85116 feat: Add security-guidance plugin in claude-code repo (#9223) 2025-10-09 09:10:43 -07:00
Daisy S. Hollman
a0317fcc53 Merge pull request #9220 from anthropics/ashwin/pluginimport
Bundle core plugins into claude-code repo
2025-10-09 08:36:21 -07:00
Ashwin Bhat
87e1022e09 Add stale issue management workflows
- Add stale-issue-manager.yml to check and manage inactive issues daily
- Add remove-autoclose-label.yml to remove autoclose label when users comment
- Issues get warning after 30 days of inactivity
- Issues auto-close after 60 days (30 days after warning)
- User comments reset the stale timer by removing autoclose label

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

Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-22 15:23:07 -07:00
38 changed files with 2505 additions and 8 deletions

View File

@@ -35,6 +35,61 @@
},
"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"
}
]
}

View File

@@ -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

View File

@@ -27,6 +27,7 @@ jobs:
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 }}

View File

@@ -102,5 +102,6 @@ jobs:
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 }}

View File

@@ -34,4 +34,5 @@ jobs:
uses: anthropics/claude-code-action@beta
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
claude_args: "--model claude-sonnet-4-5-20250929"

120
.github/workflows/oncall-triage.yml vendored Normal file
View File

@@ -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 }}

2
.gitignore vendored Normal file
View File

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

View File

@@ -1,5 +1,164 @@
# Changelog
## 2.0.36
- Fixed: DISABLE_AUTOUPDATER environment variable now properly disables package manager update notifications
- Fixed queued messages being incorrectly executed as bash commands
- Fixed input being lost when typing while a queued message is processed
## 2.0.35
- Improve fuzzy search results when searching commands
- Improved VS Code extension to respect `chat.fontSize` and `chat.fontFamily` settings throughout the entire UI, and apply font changes immediately without requiring reload
- Added `CLAUDE_CODE_EXIT_AFTER_STOP_DELAY` environment variable to automatically exit SDK mode after a specified idle duration, useful for automated workflows and scripts
- Migrated `ignorePatterns` from project config to deny permissions in the localSettings.
- Fixed messages returning null `stop_reason` and `stop_sequence` values
- Fixed menu navigation getting stuck on items with empty string or other falsy values (e.g., in the `/hooks` menu)
## 2.0.34
- VSCode Extension: Added setting to configure the initial permission mode for new conversations
- Improved file path suggestion performance with native Rust-based fuzzy finder
- Fixed infinite token refresh loop that caused MCP servers with OAuth (e.g., Slack) to hang during connection
- Fixed memory crash when reading or writing large files (especially base64-encoded images)
## 2.0.33
- Native binary installs now launch quicker.
- Fixed `claude doctor` incorrectly detecting Homebrew vs npm-global installations by properly resolving symlinks
- Fixed `claude mcp serve` exposing tools with incompatible outputSchemas
## 2.0.32
- Un-deprecate output styles based on community feedback
- Added `companyAnnouncements` setting for displaying announcements on startup
- Fixed hook progress messages not updating correctly during PostToolUse hook execution
## 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

View File

@@ -20,6 +20,10 @@ npm install -g @anthropic-ai/claude-code
2. Navigate to your project directory and run `claude`.
## Plugins
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.
## Reporting Bugs
We welcome your feedback. Use the `/bug` command to report issues directly within Claude Code, or file a [GitHub issue](https://github.com/anthropics/claude-code/issues).

103
plugins/README.md Normal file
View File

@@ -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)

View File

@@ -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"
}
}

View File

@@ -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

View File

@@ -1,7 +1,7 @@
---
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-4.5
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.

View File

@@ -1,7 +1,7 @@
---
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-4.5
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.

View File

@@ -1,7 +1,6 @@
---
description: Create and setup a new Claude Agent SDK application
argument-hint: [project-name]
model: sonnet-4.5
---
You are tasked with helping the user create a new Claude Agent SDK application. Follow these steps carefully:

View File

@@ -1,5 +0,0 @@
{
"name": "agent-sdk-dev",
"description": "Claude Agent SDK Development Plugin",
"version": "1.0.0"
}

View File

@@ -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"
}
}

View File

@@ -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

View File

@@ -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, typechecker, or test runner will catch (eg. failing tests, lint errors, type errors). Do not run these to verify; assume that they will be run as part of CI.
- 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`)

View File

@@ -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"
}
}

View File

@@ -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

View File

@@ -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"
}
}

View File

@@ -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!

View File

@@ -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

View File

@@ -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"
}
]
}
]
}
}

View File

@@ -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"
}
}

View File

@@ -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

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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
---

View File

@@ -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"
}
}

View File

@@ -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.

View File

@@ -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

View File

@@ -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"
}
]
}
]
}
}

View File

@@ -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"
}
}

View File

@@ -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"
}
]
}
}

View File

@@ -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()