mirror of
https://github.com/anthropics/claude-code.git
synced 2026-02-01 22:48:05 +00:00
Compare commits
8 Commits
ashwin/plu
...
sidb/fix-f
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
00f53cb2cb | ||
|
|
af073adcd1 | ||
|
|
b03aea4649 | ||
|
|
5cff78741f | ||
|
|
8d1be7bc48 | ||
|
|
f876b85116 | ||
|
|
a0317fcc53 | ||
|
|
87e1022e09 |
@@ -35,6 +35,17 @@
|
||||
},
|
||||
"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"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
42
.github/workflows/remove-autoclose-label.yml
vendored
Normal file
42
.github/workflows/remove-autoclose-label.yml
vendored
Normal file
@@ -0,0 +1,42 @@
|
||||
name: "Remove Autoclose Label on Activity"
|
||||
|
||||
on:
|
||||
issue_comment:
|
||||
types: [created]
|
||||
|
||||
permissions:
|
||||
issues: write
|
||||
|
||||
jobs:
|
||||
remove-autoclose:
|
||||
# Only run if the issue has the autoclose label
|
||||
if: |
|
||||
github.event.issue.state == 'open' &&
|
||||
contains(github.event.issue.labels.*.name, 'autoclose') &&
|
||||
github.event.comment.user.login != 'github-actions[bot]'
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Remove autoclose label
|
||||
uses: actions/github-script@v7
|
||||
with:
|
||||
script: |
|
||||
console.log(`Removing autoclose label from issue #${context.issue.number} due to new comment from ${context.payload.comment.user.login}`);
|
||||
|
||||
try {
|
||||
// Remove the autoclose label
|
||||
await github.rest.issues.removeLabel({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: context.issue.number,
|
||||
name: 'autoclose'
|
||||
});
|
||||
|
||||
console.log(`Successfully removed autoclose label from issue #${context.issue.number}`);
|
||||
} catch (error) {
|
||||
// If the label was already removed or doesn't exist, that's fine
|
||||
if (error.status === 404) {
|
||||
console.log(`Autoclose label was already removed from issue #${context.issue.number}`);
|
||||
} else {
|
||||
throw error;
|
||||
}
|
||||
}
|
||||
157
.github/workflows/stale-issue-manager.yml
vendored
Normal file
157
.github/workflows/stale-issue-manager.yml
vendored
Normal file
@@ -0,0 +1,157 @@
|
||||
name: "Manage Stale Issues"
|
||||
|
||||
on:
|
||||
schedule:
|
||||
# 2am Pacific = 9am UTC (10am UTC during DST)
|
||||
- cron: "0 10 * * *"
|
||||
workflow_dispatch:
|
||||
|
||||
permissions:
|
||||
issues: write
|
||||
|
||||
concurrency:
|
||||
group: stale-issue-manager
|
||||
|
||||
jobs:
|
||||
manage-stale-issues:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Manage stale issues
|
||||
uses: actions/github-script@v7
|
||||
with:
|
||||
script: |
|
||||
const oneMonthAgo = new Date();
|
||||
oneMonthAgo.setDate(oneMonthAgo.getDate() - 30);
|
||||
|
||||
const twoMonthsAgo = new Date();
|
||||
twoMonthsAgo.setDate(twoMonthsAgo.getDate() - 60);
|
||||
|
||||
const warningComment = `This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.`;
|
||||
|
||||
const closingComment = `This issue has been automatically closed due to 60 days of inactivity. If you're still experiencing this issue, please open a new issue with updated information.`;
|
||||
|
||||
let page = 1;
|
||||
let hasMore = true;
|
||||
let totalWarned = 0;
|
||||
let totalClosed = 0;
|
||||
let totalLabeled = 0;
|
||||
|
||||
while (hasMore) {
|
||||
// Get open issues sorted by last updated (oldest first)
|
||||
const { data: issues } = await github.rest.issues.listForRepo({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
state: 'open',
|
||||
sort: 'updated',
|
||||
direction: 'asc',
|
||||
per_page: 100,
|
||||
page: page
|
||||
});
|
||||
|
||||
if (issues.length === 0) {
|
||||
hasMore = false;
|
||||
break;
|
||||
}
|
||||
|
||||
for (const issue of issues) {
|
||||
// Skip if already locked
|
||||
if (issue.locked) continue;
|
||||
|
||||
// Skip pull requests
|
||||
if (issue.pull_request) continue;
|
||||
|
||||
// Check if updated more recently than 30 days ago
|
||||
const updatedAt = new Date(issue.updated_at);
|
||||
if (updatedAt > oneMonthAgo) {
|
||||
// Since issues are sorted by updated_at ascending,
|
||||
// once we hit a recent issue, all remaining will be recent too
|
||||
hasMore = false;
|
||||
break;
|
||||
}
|
||||
|
||||
// Check if issue has autoclose label
|
||||
const hasAutocloseLabel = issue.labels.some(label =>
|
||||
typeof label === 'object' && label.name === 'autoclose'
|
||||
);
|
||||
|
||||
try {
|
||||
// Get comments to check for existing warning
|
||||
const { data: comments } = await github.rest.issues.listComments({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: issue.number,
|
||||
per_page: 100
|
||||
});
|
||||
|
||||
// Find the last comment from github-actions bot
|
||||
const botComments = comments.filter(comment =>
|
||||
comment.user && comment.user.login === 'github-actions[bot]' &&
|
||||
comment.body && comment.body.includes('inactive for 30 days')
|
||||
);
|
||||
|
||||
const lastBotComment = botComments[botComments.length - 1];
|
||||
|
||||
if (lastBotComment) {
|
||||
// Check if the bot comment is older than 30 days (total 60 days of inactivity)
|
||||
const botCommentDate = new Date(lastBotComment.created_at);
|
||||
if (botCommentDate < oneMonthAgo) {
|
||||
// Close the issue - it's been stale for 60+ days
|
||||
console.log(`Closing issue #${issue.number} (stale for 60+ days): ${issue.title}`);
|
||||
|
||||
// Post closing comment
|
||||
await github.rest.issues.createComment({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: issue.number,
|
||||
body: closingComment
|
||||
});
|
||||
|
||||
// Close the issue
|
||||
await github.rest.issues.update({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: issue.number,
|
||||
state: 'closed',
|
||||
state_reason: 'not_planned'
|
||||
});
|
||||
|
||||
totalClosed++;
|
||||
}
|
||||
// If bot comment exists but is recent, issue already has warning
|
||||
} else if (updatedAt < oneMonthAgo) {
|
||||
// No bot warning yet, issue is 30+ days old
|
||||
console.log(`Warning issue #${issue.number} (stale for 30+ days): ${issue.title}`);
|
||||
|
||||
// Post warning comment
|
||||
await github.rest.issues.createComment({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: issue.number,
|
||||
body: warningComment
|
||||
});
|
||||
|
||||
totalWarned++;
|
||||
|
||||
// Add autoclose label if not present
|
||||
if (!hasAutocloseLabel) {
|
||||
await github.rest.issues.addLabels({
|
||||
owner: context.repo.owner,
|
||||
repo: context.repo.repo,
|
||||
issue_number: issue.number,
|
||||
labels: ['autoclose']
|
||||
});
|
||||
totalLabeled++;
|
||||
}
|
||||
}
|
||||
} catch (error) {
|
||||
console.error(`Failed to process issue #${issue.number}: ${error.message}`);
|
||||
}
|
||||
}
|
||||
|
||||
page++;
|
||||
}
|
||||
|
||||
console.log(`Summary:`);
|
||||
console.log(`- Issues warned (30 days stale): ${totalWarned}`);
|
||||
console.log(`- Issues labeled with autoclose: ${totalLabeled}`);
|
||||
console.log(`- Issues closed (60 days stale): ${totalClosed}`);
|
||||
14
CHANGELOG.md
14
CHANGELOG.md
@@ -1,5 +1,19 @@
|
||||
# Changelog
|
||||
|
||||
## 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
|
||||
|
||||
9
plugins/feature-dev/.claude-plugin/plugin.json
Normal file
9
plugins/feature-dev/.claude-plugin/plugin.json
Normal 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"
|
||||
}
|
||||
}
|
||||
34
plugins/feature-dev/agents/code-architect.md
Normal file
34
plugins/feature-dev/agents/code-architect.md
Normal 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.
|
||||
51
plugins/feature-dev/agents/code-explorer.md
Normal file
51
plugins/feature-dev/agents/code-explorer.md
Normal 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.
|
||||
46
plugins/feature-dev/agents/code-reviewer.md
Normal file
46
plugins/feature-dev/agents/code-reviewer.md
Normal 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.
|
||||
125
plugins/feature-dev/commands/feature-dev.md
Normal file
125
plugins/feature-dev/commands/feature-dev.md
Normal 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
|
||||
|
||||
---
|
||||
9
plugins/security-guidance/.claude-plugin/plugin.json
Normal file
9
plugins/security-guidance/.claude-plugin/plugin.json
Normal 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"
|
||||
}
|
||||
}
|
||||
16
plugins/security-guidance/hooks/hooks.json
Normal file
16
plugins/security-guidance/hooks/hooks.json
Normal 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"
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
280
plugins/security-guidance/hooks/security_reminder_hook.py
Executable file
280
plugins/security-guidance/hooks/security_reminder_hook.py
Executable 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()
|
||||
Reference in New Issue
Block a user