mirror of
https://github.com/anthropics/claude-code.git
synced 2026-02-19 04:27:33 -08:00
Compare commits
34 Commits
claude/cre
...
add-fronte
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
c91a6b660d | ||
|
|
62c3cbc471 | ||
|
|
b42fd9928c | ||
|
|
128de2a75d | ||
|
|
b8a98a8df7 | ||
|
|
ba49573fe1 | ||
|
|
015808d89c | ||
|
|
ae411f8461 | ||
|
|
4310085cb5 | ||
|
|
c509821adc | ||
|
|
d9aa4cf649 | ||
|
|
b935da77db | ||
|
|
0c7d02b56f | ||
|
|
8b47e224a0 | ||
|
|
21bbc9f250 | ||
|
|
7add6863a0 | ||
|
|
5484a86d28 | ||
|
|
10e1d3fe77 | ||
|
|
4dc23d0275 | ||
|
|
8077cdc68c | ||
|
|
207b22de65 | ||
|
|
52fea66ba5 | ||
|
|
4e417747c5 | ||
|
|
1b41969c71 | ||
|
|
e9af4d7c1d | ||
|
|
48a8bfc2b1 | ||
|
|
546f0b46ac | ||
|
|
3be7215354 | ||
|
|
5d0e5cf15f | ||
|
|
71bb75e3b5 | ||
|
|
1b827ad951 | ||
|
|
113ea425ac | ||
|
|
70cb0d1016 | ||
|
|
ff0aafa946 |
@@ -57,6 +57,50 @@
|
||||
},
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"name": "frontend-design",
|
||||
"description": "Create distinctive, production-grade frontend interfaces with high design quality. Generates creative, polished code that avoids generic AI aesthetics.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Prithvi Rajasekaran & Alexander Bricken",
|
||||
"email": "prithvi@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/frontend-design",
|
||||
"category": "development"
|
||||
}
|
||||
]
|
||||
}
|
||||
|
||||
40
.claude/commands/oncall-triage.md
Normal file
40
.claude/commands/oncall-triage.md
Normal 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
|
||||
1
.github/workflows/claude-dedupe-issues.yml
vendored
1
.github/workflows/claude-dedupe-issues.yml
vendored
@@ -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 }}
|
||||
|
||||
|
||||
1
.github/workflows/claude-issue-triage.yml
vendored
1
.github/workflows/claude-issue-triage.yml
vendored
@@ -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 }}
|
||||
|
||||
120
.github/workflows/claude-oncall-triage.yml
vendored
120
.github/workflows/claude-oncall-triage.yml
vendored
@@ -1,120 +0,0 @@
|
||||
name: Claude Oncall Issue Triage
|
||||
description: Identify critical issues that require oncall attention
|
||||
on:
|
||||
issues:
|
||||
types: [opened, edited, reopened]
|
||||
issue_comment:
|
||||
types: [created]
|
||||
schedule:
|
||||
# Run every 6 hours to catch issues that recently crossed the threshold
|
||||
- cron: '0 */6 * * *'
|
||||
workflow_dispatch: # Allow manual trigger
|
||||
|
||||
jobs:
|
||||
oncall-triage:
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 10
|
||||
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 }}
|
||||
Triggered by: ${{ github.event_name }}
|
||||
Issue number (if triggered by issue event or comment): ${{ github.event.issue.number }}
|
||||
|
||||
TASK OVERVIEW:
|
||||
|
||||
1. Determine which issues to process:
|
||||
- If this workflow was triggered by an issue event or comment (issue number provided above), process ONLY that issue
|
||||
- This includes NEW comments on OLDER issues - they may now qualify for oncall if they meet the criteria
|
||||
- If triggered by schedule or manual trigger, use mcp__github__search_issues to find issues created in the last 7 days (use query: "is:issue is:open created:>=$(date -d '7 days ago' +%Y-%m-%d)")
|
||||
- This keeps the dataset small and focused on recent activity
|
||||
|
||||
2. For each issue to process, gather information using GitHub MCP tools:
|
||||
- Issue details (title, body, labels) using mcp__github__get_issue
|
||||
- All comments using mcp__github__get_issue_comments
|
||||
- Reaction counts from the reactionGroups field
|
||||
|
||||
3. Evaluate each issue against the oncall criteria. An issue is oncall-worthy if ALL of the following are true:
|
||||
|
||||
a) Must be a bug:
|
||||
- The issue has a "bug" label OR
|
||||
- The issue content clearly describes a bug (error, crash, unexpected behavior)
|
||||
|
||||
b) Must be blocking users from using Claude Code:
|
||||
- Look for keywords indicating severity: "crash", "stuck", "frozen", "hang", "unresponsive", "cannot use", "blocked", "broken"
|
||||
- The issue prevents core functionality from working
|
||||
- Users cannot work around the issue
|
||||
|
||||
c) Last activity is within the last 3 days:
|
||||
- Check the issue's updated_at timestamp
|
||||
- Calculate if it was updated within the last 72 hours from now
|
||||
- Activity includes: new comments, reactions, or label changes
|
||||
|
||||
d) At least 5 engagements:
|
||||
- Count total reactions from the reactionGroups field (sum all reaction counts)
|
||||
- Count total number of comments
|
||||
- Sum must be >= 5
|
||||
|
||||
4. For issues that meet ALL criteria above AND don't 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
|
||||
|
||||
5. Do NOT remove the "oncall" label from any issues
|
||||
|
||||
IMPORTANT GUIDELINES:
|
||||
- Be conservative in your assessment - only flag truly critical blocking issues
|
||||
- ALL four criteria must be met for an issue to receive the "oncall" label
|
||||
- DO NOT post any comments to issues
|
||||
- Your ONLY action should be to apply the "oncall" label using mcp__github__update_issue
|
||||
- Only add the label, never remove it
|
||||
- Process efficiently - only check recent issues (last 7 days) when running on schedule
|
||||
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__search_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 }}
|
||||
1
.github/workflows/claude.yml
vendored
1
.github/workflows/claude.yml
vendored
@@ -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
120
.github/workflows/oncall-triage.yml
vendored
Normal 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
2
.gitignore
vendored
Normal file
@@ -0,0 +1,2 @@
|
||||
.DS_Store
|
||||
|
||||
59
CHANGELOG.md
59
CHANGELOG.md
@@ -1,5 +1,64 @@
|
||||
# Changelog
|
||||
|
||||
## 2.0.31
|
||||
|
||||
- Windows: native installation uses shift+tab as shortcut for mode switching, instead of alt+m
|
||||
- Vertex: add support for Web Search on supported models
|
||||
- VSCode: Adding the respectGitIgnore configuration to include .gitignored files in file searches (defaults to true)
|
||||
- Fixed a bug with subagents and MCP servers related to "Tool names must be unique" error
|
||||
- Fixed issue causing `/compact` to fail with `prompt_too_long` by making it respect existing compact boundaries
|
||||
- Fixed plugin uninstall not removing plugins
|
||||
|
||||
## 2.0.30
|
||||
|
||||
- Added helpful hint to run `security unlock-keychain` when encountering API key errors on macOS with locked keychain
|
||||
- Added `allowUnsandboxedCommands` sandbox setting to disable the dangerouslyDisableSandbox escape hatch at policy level
|
||||
- Added `disallowedTools` field to custom agent definitions for explicit tool blocking
|
||||
- Added prompt-based stop hooks
|
||||
- VSCode: Added respectGitIgnore configuration to include .gitignored files in file searches (defaults to true)
|
||||
- Enabled SSE MCP servers on native build
|
||||
- Deprecated output styles. Review options in `/output-style` and use --system-prompt-file, --system-prompt, --append-system-prompt, CLAUDE.md, or plugins instead
|
||||
- Removed support for custom ripgrep configuration, resolving an issue where Search returns no results and config discovery fails
|
||||
- Fixed Explore agent creating unwanted .md investigation files during codebase exploration
|
||||
- Fixed a bug where `/context` would sometimes fail with "max_tokens must be greater than thinking.budget_tokens" error message
|
||||
- Fixed `--mcp-config` flag to correctly override file-based MCP configurations
|
||||
- Fixed bug that saved session permissions to local settings
|
||||
- Fixed MCP tools not being available to sub-agents
|
||||
- Fixed hooks and plugins not executing when using --dangerously-skip-permissions flag
|
||||
- Fixed delay when navigating through typeahead suggestions with arrow keys
|
||||
- VSCode: Restored selection indicator in input footer showing current file or code selection status
|
||||
|
||||
## 2.0.28
|
||||
|
||||
- Plan mode: introduced new Plan subagent
|
||||
- Subagents: claude can now choose to resume subagents
|
||||
- Subagents: claude can dynamically choose the model used by its subagents
|
||||
- SDK: added --max-budget-usd flag
|
||||
- Discovery of custom slash commands, subagents, and output styles no longer respects .gitignore
|
||||
- Stop `/terminal-setup` from adding backslash to `Shift + Enter` in VS Code
|
||||
- Add branch and tag support for git-based plugins and marketplaces using fragment syntax (e.g., `owner/repo#branch`)
|
||||
- Fixed a bug where macOS permission prompts would show up upon initial launch when launching from home directory
|
||||
- Various other bug fixes
|
||||
|
||||
## 2.0.27
|
||||
|
||||
- New UI for permission prompts
|
||||
- Added current branch filtering and search to session resume screen for easier navigation
|
||||
- Fixed directory @-mention causing "No assistant message found" error
|
||||
- VSCode Extension: Add config setting to include .gitignored files in file searches
|
||||
- VSCode Extension: Bug fixes for unrelated 'Warmup' conversations, and configuration/settings occasionally being reset to defaults
|
||||
|
||||
## 2.0.25
|
||||
|
||||
- Removed legacy SDK entrypoint. Please migrate to @anthropic-ai/claude-agent-sdk for future SDK updates: https://docs.claude.com/en/docs/claude-code/sdk/migration-guide
|
||||
|
||||
## 2.0.24
|
||||
|
||||
- Fixed a bug where project-level skills were not loading when --setting-sources 'project' was specified
|
||||
- Claude Code Web: Support for Web -> CLI teleport
|
||||
- Sandbox: Releasing a sandbox mode for the BashTool on Linux & Mac
|
||||
- Bedrock: Display awsAuthRefresh output when auth is required
|
||||
|
||||
## 2.0.22
|
||||
|
||||
- Fixed content layout shift when scrolling through slash commands
|
||||
|
||||
@@ -32,6 +32,16 @@ Simplifies common git operations with streamlined commands for committing, pushi
|
||||
- `/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**
|
||||
|
||||
10
plugins/code-review/.claude-plugin/plugin.json
Normal file
10
plugins/code-review/.claude-plugin/plugin.json
Normal 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"
|
||||
}
|
||||
}
|
||||
|
||||
246
plugins/code-review/README.md
Normal file
246
plugins/code-review/README.md
Normal 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
|
||||
84
plugins/code-review/commands/code-review.md
Normal file
84
plugins/code-review/commands/code-review.md
Normal 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 will catch (no need to run the linter to verify)
|
||||
- General code quality issues (eg. lack of test coverage, general security issues), unless explicitly required in CLAUDE.md
|
||||
- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
|
||||
|
||||
Notes:
|
||||
|
||||
- Use `gh` to interact with Github (eg. to fetch a pull request, or to create inline comments), rather than web fetch
|
||||
- Make a todo list first
|
||||
- You must cite and link each bug (eg. if referring to a CLAUDE.md, you must link it)
|
||||
- For your comment, follow the following format precisely (assuming for this example that you found 3 issues):
|
||||
|
||||
---
|
||||
|
||||
## Code review
|
||||
|
||||
Found 3 issues:
|
||||
|
||||
1. <brief description of bug> (CLAUDE.md says "<...>")
|
||||
|
||||
<link to file and line with full sha1 + line range for context, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
|
||||
|
||||
2. <brief description of bug> (some/other/CLAUDE.md says "<...>")
|
||||
|
||||
<link to file and line with full sha1 + line range for context>
|
||||
|
||||
3. <brief description of bug> (bug due to <file and code snippet>)
|
||||
|
||||
<link to file and line with full sha1 + line range for context>
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
|
||||
<sub>- If this code review was useful, please react with 👍. Otherwise, react with 👎.</sub>
|
||||
|
||||
---
|
||||
|
||||
- Or, if you found no issues:
|
||||
|
||||
---
|
||||
|
||||
## Auto code review
|
||||
|
||||
No issues found. Checked for bugs and CLAUDE.md compliance.
|
||||
|
||||
## 🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
|
||||
- When linking to code, follow the following format precisely, otherwise the Markdown preview won't render correctly: https://github.com/anthropics/claude-cli-internal/blob/c21d3c10bc8e898b7ac1a2d745bdc9bc4e423afe/package.json#L10-L15
|
||||
- Requires full git sha
|
||||
- Repo name must match the repo you're code reviewing
|
||||
- # sign after the file name
|
||||
- Line range format is L[start]-L[end]
|
||||
- Provide at least 1 line of context before and after, centered on the line you are commenting about (eg. if you are commenting about lines 5-6, you should link to `L4-7`)
|
||||
10
plugins/commit-commands/.claude-plugin/plugin.json
Normal file
10
plugins/commit-commands/.claude-plugin/plugin.json
Normal 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"
|
||||
}
|
||||
}
|
||||
|
||||
@@ -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"
|
||||
}
|
||||
}
|
||||
72
plugins/explanatory-output-style/README.md
Normal file
72
plugins/explanatory-output-style/README.md
Normal 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!
|
||||
15
plugins/explanatory-output-style/hooks-handlers/session-start.sh
Executable file
15
plugins/explanatory-output-style/hooks-handlers/session-start.sh
Executable 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
|
||||
15
plugins/explanatory-output-style/hooks/hooks.json
Normal file
15
plugins/explanatory-output-style/hooks/hooks.json
Normal 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"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
9
plugins/frontend-design/.claude-plugin/plugin.json
Normal file
9
plugins/frontend-design/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"name": "frontend-design",
|
||||
"version": "1.0.0",
|
||||
"description": "Frontend design skill for UI/UX implementation",
|
||||
"author": {
|
||||
"name": "Prithvi Rajasekaran, Alexander Bricken",
|
||||
"email": "prithvi@anthropic.com, alexander@anthropic.com"
|
||||
}
|
||||
}
|
||||
31
plugins/frontend-design/README.md
Normal file
31
plugins/frontend-design/README.md
Normal file
@@ -0,0 +1,31 @@
|
||||
# Frontend Design Plugin
|
||||
|
||||
Generates distinctive, production-grade frontend interfaces that avoid generic AI aesthetics.
|
||||
|
||||
## What It Does
|
||||
|
||||
Claude automatically uses this skill for frontend work. Creates production-ready code with:
|
||||
|
||||
- Bold aesthetic choices
|
||||
- Distinctive typography and color palettes
|
||||
- High-impact animations and visual details
|
||||
- Context-aware implementation
|
||||
|
||||
## Usage
|
||||
|
||||
```
|
||||
"Create a dashboard for a music streaming app"
|
||||
"Build a landing page for an AI security startup"
|
||||
"Design a settings panel with dark mode"
|
||||
```
|
||||
|
||||
Claude will choose a clear aesthetic direction and implement production code with meticulous attention to detail.
|
||||
|
||||
## Learn More
|
||||
|
||||
See the [Frontend Aesthetics Cookbook](https://github.com/anthropics/claude-cookbooks/blob/main/coding/prompting_for_frontend_aesthetics.ipynb) for detailed guidance on prompting for high-quality frontend design.
|
||||
|
||||
## Authors
|
||||
|
||||
Prithvi Rajasekaran (prithvi@anthropic.com)
|
||||
Alexander Bricken (alexander@anthropic.com)
|
||||
42
plugins/frontend-design/skills/frontend-design/SKILL.md
Normal file
42
plugins/frontend-design/skills/frontend-design/SKILL.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
name: frontend-design
|
||||
description: Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.
|
||||
license: Complete terms in LICENSE.txt
|
||||
---
|
||||
|
||||
This skill guides creation of distinctive, production-grade frontend interfaces that avoid generic "AI slop" aesthetics. Implement real working code with exceptional attention to aesthetic details and creative choices.
|
||||
|
||||
The user provides frontend requirements: a component, page, application, or interface to build. They may include context about the purpose, audience, or technical constraints.
|
||||
|
||||
## Design Thinking
|
||||
|
||||
Before coding, understand the context and commit to a BOLD aesthetic direction:
|
||||
- **Purpose**: What problem does this interface solve? Who uses it?
|
||||
- **Tone**: Pick an extreme: brutally minimal, maximalist chaos, retro-futuristic, organic/natural, luxury/refined, playful/toy-like, editorial/magazine, brutalist/raw, art deco/geometric, soft/pastel, industrial/utilitarian, etc. There are so many flavors to choose from. Use these for inspiration but design one that is true to the aesthetic direction.
|
||||
- **Constraints**: Technical requirements (framework, performance, accessibility).
|
||||
- **Differentiation**: What makes this UNFORGETTABLE? What's the one thing someone will remember?
|
||||
|
||||
**CRITICAL**: Choose a clear conceptual direction and execute it with precision. Bold maximalism and refined minimalism both work - the key is intentionality, not intensity.
|
||||
|
||||
Then implement working code (HTML/CSS/JS, React, Vue, etc.) that is:
|
||||
- Production-grade and functional
|
||||
- Visually striking and memorable
|
||||
- Cohesive with a clear aesthetic point-of-view
|
||||
- Meticulously refined in every detail
|
||||
|
||||
## Frontend Aesthetics Guidelines
|
||||
|
||||
Focus on:
|
||||
- **Typography**: Choose fonts that are beautiful, unique, and interesting. Avoid generic fonts like Arial and Inter; opt instead for distinctive choices that elevate the frontend's aesthetics; unexpected, characterful font choices. Pair a distinctive display font with a refined body font.
|
||||
- **Color & Theme**: Commit to a cohesive aesthetic. Use CSS variables for consistency. Dominant colors with sharp accents outperform timid, evenly-distributed palettes.
|
||||
- **Motion**: Use animations for effects and micro-interactions. Prioritize CSS-only solutions for HTML. Use Motion library for React when available. Focus on high-impact moments: one well-orchestrated page load with staggered reveals (animation-delay) creates more delight than scattered micro-interactions. Use scroll-triggering and hover states that surprise.
|
||||
- **Spatial Composition**: Unexpected layouts. Asymmetry. Overlap. Diagonal flow. Grid-breaking elements. Generous negative space OR controlled density.
|
||||
- **Backgrounds & Visual Details**: Create atmosphere and depth rather than defaulting to solid colors. Add contextual effects and textures that match the overall aesthetic. Apply creative forms like gradient meshes, noise textures, geometric patterns, layered transparencies, dramatic shadows, decorative borders, custom cursors, and grain overlays.
|
||||
|
||||
NEVER use generic AI-generated aesthetics like overused font families (Inter, Roboto, Arial, system fonts), cliched color schemes (particularly purple gradients on white backgrounds), predictable layouts and component patterns, and cookie-cutter design that lacks context-specific character.
|
||||
|
||||
Interpret creatively and make unexpected choices that feel genuinely designed for the context. No design should be the same. Vary between light and dark themes, different fonts, different aesthetics. NEVER converge on common choices (Space Grotesk, for example) across generations.
|
||||
|
||||
**IMPORTANT**: Match implementation complexity to the aesthetic vision. Maximalist designs need elaborate code with extensive animations and effects. Minimalist or refined designs need restraint, precision, and careful attention to spacing, typography, and subtle details. Elegance comes from executing the vision well.
|
||||
|
||||
Remember: Claude is capable of extraordinary creative work. Don't hold back, show what can truly be created when thinking outside the box and committing fully to a distinctive vision.
|
||||
9
plugins/learning-output-style/.claude-plugin/plugin.json
Normal file
9
plugins/learning-output-style/.claude-plugin/plugin.json
Normal 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"
|
||||
}
|
||||
}
|
||||
93
plugins/learning-output-style/README.md
Normal file
93
plugins/learning-output-style/README.md
Normal 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.
|
||||
15
plugins/learning-output-style/hooks-handlers/session-start.sh
Executable file
15
plugins/learning-output-style/hooks-handlers/session-start.sh
Executable 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
|
||||
15
plugins/learning-output-style/hooks/hooks.json
Normal file
15
plugins/learning-output-style/hooks/hooks.json
Normal 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"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
Reference in New Issue
Block a user