mirror of
https://github.com/anthropics/claude-plugins-official.git
synced 2026-01-30 04:22:03 +00:00
creating intital scaffolding for claude code plugins
This commit is contained in:
241
.claude-plugin/marketplace.json
Normal file
241
.claude-plugin/marketplace.json
Normal file
@@ -0,0 +1,241 @@
|
||||
{
|
||||
"$schema": "https://anthropic.com/claude-code/marketplace.schema.json",
|
||||
"name": "claude-code-marketplace",
|
||||
"version": "1.0.0",
|
||||
"description": "Official marketplace for high-quality Claude Code extensions including development tools, productivity plugins, and MCP integrations",
|
||||
"owner": {
|
||||
"name": "Anthropic",
|
||||
"email": "support@anthropic.com"
|
||||
},
|
||||
"plugins": [
|
||||
{
|
||||
"name": "agent-sdk-dev",
|
||||
"description": "Development kit for working with the Claude Agent SDK",
|
||||
"source": "./plugins/agent-sdk-dev",
|
||||
"category": "development"
|
||||
},
|
||||
{
|
||||
"name": "pr-review-toolkit",
|
||||
"description": "Comprehensive PR review agents specializing in comments, tests, error handling, type design, code quality, and code simplification",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Anthropic",
|
||||
"email": "support@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/pr-review-toolkit",
|
||||
"category": "productivity"
|
||||
},
|
||||
{
|
||||
"name": "commit-commands",
|
||||
"description": "Commands for git commit workflows including commit, push, and PR creation",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Anthropic",
|
||||
"email": "support@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/commit-commands",
|
||||
"category": "productivity"
|
||||
},
|
||||
{
|
||||
"name": "feature-dev",
|
||||
"description": "Comprehensive feature development workflow with specialized agents for codebase exploration, architecture design, and quality review",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Siddharth Bidasaria",
|
||||
"email": "sbidasaria@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/feature-dev",
|
||||
"category": "development"
|
||||
},
|
||||
{
|
||||
"name": "security-guidance",
|
||||
"description": "Security reminder hook that warns about potential security issues when editing files, including command injection, XSS, and unsafe code patterns",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "David Dworken",
|
||||
"email": "dworken@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/security-guidance",
|
||||
"category": "security"
|
||||
},
|
||||
{
|
||||
"name": "code-review",
|
||||
"description": "Automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Boris Cherny",
|
||||
"email": "boris@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/code-review",
|
||||
"category": "productivity"
|
||||
},
|
||||
{
|
||||
"name": "explanatory-output-style",
|
||||
"description": "Adds educational insights about implementation choices and codebase patterns (mimics the deprecated Explanatory output style)",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Dickson Tsai",
|
||||
"email": "dickson@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/explanatory-output-style",
|
||||
"category": "learning"
|
||||
},
|
||||
{
|
||||
"name": "learning-output-style",
|
||||
"description": "Interactive learning mode that requests meaningful code contributions at decision points (mimics the unshipped Learning output style)",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Boris Cherny",
|
||||
"email": "boris@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/learning-output-style",
|
||||
"category": "learning"
|
||||
},
|
||||
{
|
||||
"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"
|
||||
},
|
||||
{
|
||||
"name": "ralph-wiggum",
|
||||
"description": "Interactive self-referential AI loops for iterative development. Claude works on the same task repeatedly, seeing its previous work, until completion.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Daisy Hollman",
|
||||
"email": "daisy@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/ralph-wiggum",
|
||||
"category": "development"
|
||||
},
|
||||
{
|
||||
"name": "hookify",
|
||||
"description": "Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or from explicit instructions. Define rules via simple markdown files.",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "Daisy Hollman",
|
||||
"email": "daisy@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/hookify",
|
||||
"category": "productivity"
|
||||
},
|
||||
{
|
||||
"name": "plugin-dev",
|
||||
"description": "Comprehensive toolkit for developing Claude Code plugins. Includes 7 expert skills covering hooks, MCP integration, commands, agents, and best practices. AI-assisted plugin creation and validation.",
|
||||
"version": "0.1.0",
|
||||
"author": {
|
||||
"name": "Daisy Hollman",
|
||||
"email": "daisy@anthropic.com"
|
||||
},
|
||||
"source": "./plugins/plugin-dev",
|
||||
"category": "development"
|
||||
},
|
||||
{
|
||||
"name": "greptile",
|
||||
"description": "AI-powered codebase search and understanding. Query your repositories using natural language to find relevant code, understand dependencies, and get contextual answers about your codebase architecture.",
|
||||
"category": "development",
|
||||
"source": "./external_plugins/greptile"
|
||||
},
|
||||
{
|
||||
"name": "serena",
|
||||
"description": "Semantic code analysis MCP server providing intelligent code understanding, refactoring suggestions, and codebase navigation through language server protocol integration.",
|
||||
"category": "development",
|
||||
"source": "./external_plugins/serena"
|
||||
},
|
||||
{
|
||||
"name": "playwright",
|
||||
"description": "Browser automation and end-to-end testing MCP server by Microsoft. Enables Claude to interact with web pages, take screenshots, fill forms, click elements, and perform automated browser testing workflows.",
|
||||
"category": "testing",
|
||||
"source": "./external_plugins/playwright"
|
||||
},
|
||||
{
|
||||
"name": "github",
|
||||
"description": "Official GitHub MCP server for repository management. Create issues, manage pull requests, review code, search repositories, and interact with GitHub's full API directly from Claude Code.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/github"
|
||||
},
|
||||
{
|
||||
"name": "supabase",
|
||||
"description": "Supabase MCP integration for database operations, authentication, storage, and real-time subscriptions. Manage your Supabase projects, run SQL queries, and interact with your backend directly.",
|
||||
"category": "database",
|
||||
"source": "./external_plugins/supabase"
|
||||
},
|
||||
{
|
||||
"name": "atlassian",
|
||||
"description": "Connect to Atlassian products including Jira and Confluence. Search and create issues, access documentation, manage sprints, and integrate your development workflow with Atlassian's collaboration tools.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/atlassian"
|
||||
},
|
||||
{
|
||||
"name": "laravel-boost",
|
||||
"description": "Laravel development toolkit MCP server. Provides intelligent assistance for Laravel applications including Artisan commands, Eloquent queries, routing, migrations, and framework-specific code generation.",
|
||||
"category": "development",
|
||||
"source": "./external_plugins/laravel-boost"
|
||||
},
|
||||
{
|
||||
"name": "figma",
|
||||
"description": "Figma design platform integration. Access design files, extract component information, read design tokens, and translate designs into code. Bridge the gap between design and development workflows.",
|
||||
"category": "design",
|
||||
"source": "./external_plugins/figma"
|
||||
},
|
||||
{
|
||||
"name": "asana",
|
||||
"description": "Asana project management integration. Create and manage tasks, search projects, update assignments, track progress, and integrate your development workflow with Asana's work management platform.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/asana"
|
||||
},
|
||||
{
|
||||
"name": "linear",
|
||||
"description": "Linear issue tracking integration. Create issues, manage projects, update statuses, search across workspaces, and streamline your software development workflow with Linear's modern issue tracker.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/linear"
|
||||
},
|
||||
{
|
||||
"name": "notion",
|
||||
"description": "Notion workspace integration. Search pages, create and update documents, manage databases, and access your team's knowledge base directly from Claude Code for seamless documentation workflows.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/notion"
|
||||
},
|
||||
{
|
||||
"name": "gitlab",
|
||||
"description": "GitLab DevOps platform integration. Manage repositories, merge requests, CI/CD pipelines, issues, and wikis. Full access to GitLab's comprehensive DevOps lifecycle tools.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/gitlab"
|
||||
},
|
||||
{
|
||||
"name": "sentry",
|
||||
"description": "Sentry error monitoring integration. Access error reports, analyze stack traces, search issues by fingerprint, and debug production errors directly from your development environment.",
|
||||
"category": "monitoring",
|
||||
"source": "./external_plugins/sentry"
|
||||
},
|
||||
{
|
||||
"name": "slack",
|
||||
"description": "Slack workspace integration. Search messages, access channels, read threads, and stay connected with your team's communications while coding. Find relevant discussions and context quickly.",
|
||||
"category": "productivity",
|
||||
"source": "./external_plugins/slack"
|
||||
},
|
||||
{
|
||||
"name": "vercel",
|
||||
"description": "Vercel deployment platform integration. Manage deployments, check build status, access logs, configure domains, and control your frontend infrastructure directly from Claude Code.",
|
||||
"category": "deployment",
|
||||
"source": "./external_plugins/vercel"
|
||||
},
|
||||
{
|
||||
"name": "firebase",
|
||||
"description": "Google Firebase MCP integration. Manage Firestore databases, authentication, cloud functions, hosting, and storage. Build and manage your Firebase backend directly from your development workflow.",
|
||||
"category": "database",
|
||||
"source": "./external_plugins/firebase"
|
||||
},
|
||||
{
|
||||
"name": "context7",
|
||||
"description": "Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.",
|
||||
"category": "development",
|
||||
"source": "./external_plugins/context7"
|
||||
}
|
||||
]
|
||||
}
|
||||
8
external_plugins/asana/.claude-plugin/plugin.json
Normal file
8
external_plugins/asana/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "asana",
|
||||
"description": "Asana project management integration. Create and manage tasks, search projects, update assignments, track progress, and integrate your development workflow with Asana's work management platform.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Asana"
|
||||
}
|
||||
}
|
||||
6
external_plugins/asana/.mcp.json
Normal file
6
external_plugins/asana/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"asana": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.asana.com/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/asana/README.md
Normal file
15
external_plugins/asana/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Asana Plugin
|
||||
|
||||
Asana project management integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Create and manage tasks, search projects, update assignments, track progress, and integrate your development workflow with Asana's work management platform.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Asana account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Asana Connector](https://www.claude.com/connectors/asana) for more information.
|
||||
8
external_plugins/atlassian/.claude-plugin/plugin.json
Normal file
8
external_plugins/atlassian/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "atlassian",
|
||||
"description": "Connect to Atlassian products including Jira and Confluence. Search and create issues, access documentation, manage sprints, and integrate your development workflow with Atlassian's collaboration tools.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Atlassian"
|
||||
}
|
||||
}
|
||||
6
external_plugins/atlassian/.mcp.json
Normal file
6
external_plugins/atlassian/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"atlassian": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.atlassian.com/v1/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/atlassian/README.md
Normal file
15
external_plugins/atlassian/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Atlassian Plugin
|
||||
|
||||
Atlassian integration (Jira & Confluence) for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Connect to Atlassian products including Jira and Confluence. Search and create issues, access documentation, manage sprints, and integrate your development workflow with Atlassian's collaboration tools.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Atlassian account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Atlassian Connector](https://www.claude.com/connectors/atlassian) for more information.
|
||||
8
external_plugins/context7/.claude-plugin/plugin.json
Normal file
8
external_plugins/context7/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "context7",
|
||||
"description": "Upstash Context7 MCP server for up-to-date documentation lookup. Pull version-specific documentation and code examples directly from source repositories into your LLM context.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Upstash"
|
||||
}
|
||||
}
|
||||
6
external_plugins/context7/.mcp.json
Normal file
6
external_plugins/context7/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"context7": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@upstash/context7-mcp"]
|
||||
}
|
||||
}
|
||||
41
external_plugins/context7/README.md
Normal file
41
external_plugins/context7/README.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Context7 Plugin
|
||||
|
||||
Upstash Context7 MCP server for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Pull up-to-date, version-specific documentation and code examples directly from source repositories into your LLM context. Add "use context7" to prompts to fetch relevant documentation.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Node.js >= v18.0.0
|
||||
|
||||
## Optional: API Key for Higher Rate Limits
|
||||
|
||||
For higher rate limits and private repository access, get an API key and configure:
|
||||
|
||||
```json
|
||||
{
|
||||
"context7": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@upstash/context7-mcp", "--api-key", "YOUR_API_KEY"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Or use the remote server:
|
||||
```json
|
||||
{
|
||||
"context7": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.context7.com/mcp",
|
||||
"headers": {
|
||||
"Authorization": "Bearer YOUR_API_KEY"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Context7 GitHub](https://github.com/upstash/context7) for detailed documentation.
|
||||
8
external_plugins/figma/.claude-plugin/plugin.json
Normal file
8
external_plugins/figma/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "figma",
|
||||
"description": "Figma design platform integration. Access design files, extract component information, read design tokens, and translate designs into code. Bridge the gap between design and development workflows.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Figma"
|
||||
}
|
||||
}
|
||||
6
external_plugins/figma/.mcp.json
Normal file
6
external_plugins/figma/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"figma": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.figma.com/v1/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/figma/README.md
Normal file
15
external_plugins/figma/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Figma Plugin
|
||||
|
||||
Figma design platform integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Access design files, extract component information, read design tokens, and translate designs into code. Bridge the gap between design and development workflows.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Figma account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Figma Connector](https://www.claude.com/connectors/figma) for more information.
|
||||
8
external_plugins/firebase/.claude-plugin/plugin.json
Normal file
8
external_plugins/firebase/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "firebase",
|
||||
"description": "Google Firebase MCP integration. Manage Firestore databases, authentication, cloud functions, hosting, and storage. Build and manage your Firebase backend directly from your development workflow.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Google"
|
||||
}
|
||||
}
|
||||
6
external_plugins/firebase/.mcp.json
Normal file
6
external_plugins/firebase/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"firebase": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "firebase-tools@latest", "mcp"]
|
||||
}
|
||||
}
|
||||
32
external_plugins/firebase/README.md
Normal file
32
external_plugins/firebase/README.md
Normal file
@@ -0,0 +1,32 @@
|
||||
# Firebase Plugin
|
||||
|
||||
Google Firebase MCP integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Manage Firestore databases, authentication, cloud functions, hosting, and storage. Build and manage your Firebase backend directly from your development workflow.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Node.js installed
|
||||
- Firebase CLI credentials (logged in via `firebase login` or Application Default Credentials)
|
||||
|
||||
## Optional Configuration
|
||||
|
||||
Add arguments to customize behavior:
|
||||
- `--dir ABSOLUTE_DIR_PATH` - Set project context directory
|
||||
- `--only FEATURE_1,FEATURE_2` - Limit exposed tools (comma-separated)
|
||||
|
||||
Example with options:
|
||||
```json
|
||||
{
|
||||
"firebase": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "firebase-tools@latest", "mcp", "--dir", "/path/to/project", "--only", "auth,firestore"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Firebase MCP Documentation](https://firebase.google.com/docs/ai-assistance/mcp-server) for detailed setup instructions.
|
||||
8
external_plugins/github/.claude-plugin/plugin.json
Normal file
8
external_plugins/github/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "github",
|
||||
"description": "Official GitHub MCP server for repository management. Create issues, manage pull requests, review code, search repositories, and interact with GitHub's full API directly from Claude Code.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "GitHub"
|
||||
}
|
||||
}
|
||||
9
external_plugins/github/.mcp.json
Normal file
9
external_plugins/github/.mcp.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"github": {
|
||||
"type": "http",
|
||||
"url": "https://api.githubcopilot.com/mcp/",
|
||||
"headers": {
|
||||
"Authorization": "Bearer ${GITHUB_PERSONAL_ACCESS_TOKEN}"
|
||||
}
|
||||
}
|
||||
}
|
||||
38
external_plugins/github/README.md
Normal file
38
external_plugins/github/README.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# GitHub Plugin
|
||||
|
||||
Official GitHub MCP server for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Create issues, manage pull requests, review code, search repositories, and interact with GitHub's full API directly from Claude Code.
|
||||
|
||||
## Setup
|
||||
|
||||
1. Create a GitHub Personal Access Token with appropriate scopes
|
||||
2. Set the environment variable:
|
||||
```bash
|
||||
export GITHUB_PERSONAL_ACCESS_TOKEN=your-token-here
|
||||
```
|
||||
|
||||
## Required Environment Variables
|
||||
|
||||
- `GITHUB_PERSONAL_ACCESS_TOKEN` - Your GitHub PAT with appropriate scopes
|
||||
|
||||
## Alternative: Docker Setup
|
||||
|
||||
For local server deployment:
|
||||
```json
|
||||
{
|
||||
"github": {
|
||||
"command": "docker",
|
||||
"args": ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"],
|
||||
"env": {
|
||||
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Learn More
|
||||
|
||||
See [GitHub MCP Server](https://github.com/github/github-mcp-server) for detailed documentation.
|
||||
8
external_plugins/gitlab/.claude-plugin/plugin.json
Normal file
8
external_plugins/gitlab/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "gitlab",
|
||||
"description": "GitLab DevOps platform integration. Manage repositories, merge requests, CI/CD pipelines, issues, and wikis. Full access to GitLab's comprehensive DevOps lifecycle tools.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "GitLab"
|
||||
}
|
||||
}
|
||||
6
external_plugins/gitlab/.mcp.json
Normal file
6
external_plugins/gitlab/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"gitlab": {
|
||||
"type": "http",
|
||||
"url": "https://gitlab.com/api/v4/mcp"
|
||||
}
|
||||
}
|
||||
39
external_plugins/gitlab/README.md
Normal file
39
external_plugins/gitlab/README.md
Normal file
@@ -0,0 +1,39 @@
|
||||
# GitLab Plugin
|
||||
|
||||
GitLab DevOps platform integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Manage repositories, merge requests, CI/CD pipelines, issues, and wikis. Full access to GitLab's comprehensive DevOps lifecycle tools.
|
||||
|
||||
## Setup
|
||||
|
||||
The default configuration uses GitLab.com. For self-hosted GitLab instances, modify the URL in `.mcp.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"gitlab": {
|
||||
"type": "http",
|
||||
"url": "https://your-gitlab-instance.com/api/v4/mcp"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Node.js 20+ (for stdio transport alternative)
|
||||
|
||||
## Alternative: stdio Transport
|
||||
|
||||
```json
|
||||
{
|
||||
"gitlab": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "mcp-remote", "https://gitlab.com/api/v4/mcp"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Learn More
|
||||
|
||||
See [GitLab MCP Documentation](https://docs.gitlab.com/user/gitlab_duo/model_context_protocol/mcp_server/) for detailed setup instructions.
|
||||
8
external_plugins/greptile/.claude-plugin/plugin.json
Normal file
8
external_plugins/greptile/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "greptile",
|
||||
"description": "AI-powered codebase search and understanding. Query your repositories using natural language to find relevant code, understand dependencies, and get contextual answers about your codebase architecture.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Greptile"
|
||||
}
|
||||
}
|
||||
9
external_plugins/greptile/.mcp.json
Normal file
9
external_plugins/greptile/.mcp.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"greptile": {
|
||||
"type": "http",
|
||||
"url": "https://api.greptile.com/mcp",
|
||||
"headers": {
|
||||
"Authorization": "Bearer ${GREPTILE_API_KEY}"
|
||||
}
|
||||
}
|
||||
}
|
||||
23
external_plugins/greptile/README.md
Normal file
23
external_plugins/greptile/README.md
Normal file
@@ -0,0 +1,23 @@
|
||||
# Greptile Plugin
|
||||
|
||||
AI-powered codebase search and understanding for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Greptile enables natural language queries across your repositories to find relevant code, understand dependencies, and get contextual answers about your codebase architecture.
|
||||
|
||||
## Setup
|
||||
|
||||
1. Get your API key from [app.greptile.com](https://app.greptile.com)
|
||||
2. Set the environment variable:
|
||||
```bash
|
||||
export GREPTILE_API_KEY=your-api-key-here
|
||||
```
|
||||
|
||||
## Required Environment Variables
|
||||
|
||||
- `GREPTILE_API_KEY` - Your Greptile API key
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Greptile MCP Documentation](https://www.greptile.com/docs/mcp/setup-ides) for detailed setup instructions.
|
||||
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "laravel-boost",
|
||||
"description": "Laravel development toolkit MCP server. Provides intelligent assistance for Laravel applications including Artisan commands, Eloquent queries, routing, migrations, and framework-specific code generation.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Laravel"
|
||||
}
|
||||
}
|
||||
6
external_plugins/laravel-boost/.mcp.json
Normal file
6
external_plugins/laravel-boost/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"laravel-boost": {
|
||||
"command": "php",
|
||||
"args": ["artisan", "boost:mcp"]
|
||||
}
|
||||
}
|
||||
26
external_plugins/laravel-boost/README.md
Normal file
26
external_plugins/laravel-boost/README.md
Normal file
@@ -0,0 +1,26 @@
|
||||
# Laravel Boost Plugin
|
||||
|
||||
Laravel development toolkit MCP server for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Provides over 15 specialized tools for Laravel development including Artisan commands, Eloquent queries, routing, migrations, and framework-specific code generation.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Laravel project with Boost installed
|
||||
- PHP installed
|
||||
|
||||
## Setup
|
||||
|
||||
1. Install Laravel Boost in your project:
|
||||
```bash
|
||||
composer require laravel/boost
|
||||
php artisan boost:install
|
||||
```
|
||||
|
||||
2. The MCP server is automatically registered during installation
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Laravel Boost GitHub](https://github.com/laravel/boost) for detailed documentation.
|
||||
8
external_plugins/linear/.claude-plugin/plugin.json
Normal file
8
external_plugins/linear/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "linear",
|
||||
"description": "Linear issue tracking integration. Create issues, manage projects, update statuses, search across workspaces, and streamline your software development workflow with Linear's modern issue tracker.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Linear"
|
||||
}
|
||||
}
|
||||
6
external_plugins/linear/.mcp.json
Normal file
6
external_plugins/linear/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"linear": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.linear.app/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/linear/README.md
Normal file
15
external_plugins/linear/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Linear Plugin
|
||||
|
||||
Linear issue tracking integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Create issues, manage projects, update statuses, search across workspaces, and streamline your software development workflow with Linear's modern issue tracker.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Linear account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Linear Connector](https://www.claude.com/connectors/linear) for more information.
|
||||
8
external_plugins/notion/.claude-plugin/plugin.json
Normal file
8
external_plugins/notion/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "notion",
|
||||
"description": "Notion workspace integration. Search pages, create and update documents, manage databases, and access your team's knowledge base directly from Claude Code for seamless documentation workflows.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Notion"
|
||||
}
|
||||
}
|
||||
6
external_plugins/notion/.mcp.json
Normal file
6
external_plugins/notion/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"notion": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.notion.com/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/notion/README.md
Normal file
15
external_plugins/notion/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Notion Plugin
|
||||
|
||||
Notion workspace integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Search pages, create and update documents, manage databases, and access your team's knowledge base directly from Claude Code for seamless documentation workflows.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Notion workspace.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Notion Connector](https://www.claude.com/connectors/notion) for more information.
|
||||
8
external_plugins/playwright/.claude-plugin/plugin.json
Normal file
8
external_plugins/playwright/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "playwright",
|
||||
"description": "Browser automation and end-to-end testing MCP server by Microsoft. Enables Claude to interact with web pages, take screenshots, fill forms, click elements, and perform automated browser testing workflows.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Microsoft"
|
||||
}
|
||||
}
|
||||
6
external_plugins/playwright/.mcp.json
Normal file
6
external_plugins/playwright/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"playwright": {
|
||||
"command": "npx",
|
||||
"args": ["@playwright/mcp@latest"]
|
||||
}
|
||||
}
|
||||
22
external_plugins/playwright/README.md
Normal file
22
external_plugins/playwright/README.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Playwright Plugin
|
||||
|
||||
Browser automation and end-to-end testing MCP server for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Enables Claude to interact with web pages, take screenshots, fill forms, click elements, and perform automated browser testing workflows.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Node.js installed
|
||||
|
||||
## Optional Configuration
|
||||
|
||||
Add arguments to customize behavior:
|
||||
- `--browser` - Specify browser type (chrome, firefox, webkit, msedge)
|
||||
- `--headless` - Run in headless mode
|
||||
- `--viewport-size` - Browser dimensions (e.g., "1280x720")
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Playwright MCP GitHub](https://github.com/microsoft/playwright-mcp) for detailed documentation.
|
||||
8
external_plugins/sentry/.claude-plugin/plugin.json
Normal file
8
external_plugins/sentry/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "sentry",
|
||||
"description": "Sentry error monitoring integration. Access error reports, analyze stack traces, search issues by fingerprint, and debug production errors directly from your development environment.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Sentry"
|
||||
}
|
||||
}
|
||||
6
external_plugins/sentry/.mcp.json
Normal file
6
external_plugins/sentry/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"sentry": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.sentry.dev/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/sentry/README.md
Normal file
15
external_plugins/sentry/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Sentry Plugin
|
||||
|
||||
Sentry error monitoring integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Access error reports, analyze stack traces, search issues by fingerprint, and debug production errors directly from your development environment.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Sentry account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Sentry Connector](https://www.claude.com/connectors/sentry) for more information.
|
||||
8
external_plugins/serena/.claude-plugin/plugin.json
Normal file
8
external_plugins/serena/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "serena",
|
||||
"description": "Semantic code analysis MCP server providing intelligent code understanding, refactoring suggestions, and codebase navigation through language server protocol integration.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Oraios"
|
||||
}
|
||||
}
|
||||
6
external_plugins/serena/.mcp.json
Normal file
6
external_plugins/serena/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"serena": {
|
||||
"command": "uvx",
|
||||
"args": ["--from", "git+https://github.com/oraios/serena", "serena", "start-mcp-server"]
|
||||
}
|
||||
}
|
||||
22
external_plugins/serena/README.md
Normal file
22
external_plugins/serena/README.md
Normal file
@@ -0,0 +1,22 @@
|
||||
# Serena Plugin
|
||||
|
||||
Semantic code analysis MCP server for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Serena provides intelligent code understanding, refactoring suggestions, and codebase navigation through language server protocol integration.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Python with `uv` package manager installed
|
||||
|
||||
## Setup
|
||||
|
||||
The plugin automatically runs via `uvx`. Ensure you have `uv` installed:
|
||||
```bash
|
||||
pip install uv
|
||||
```
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Serena GitHub Repository](https://github.com/oraios/serena) for detailed documentation.
|
||||
8
external_plugins/slack/.claude-plugin/plugin.json
Normal file
8
external_plugins/slack/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "slack",
|
||||
"description": "Slack workspace integration. Search messages, access channels, read threads, and stay connected with your team's communications while coding. Find relevant discussions and context quickly.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Slack"
|
||||
}
|
||||
}
|
||||
6
external_plugins/slack/.mcp.json
Normal file
6
external_plugins/slack/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"slack": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.slack.com/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/slack/README.md
Normal file
15
external_plugins/slack/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Slack Plugin
|
||||
|
||||
Slack workspace integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Search messages, access channels, read threads, and stay connected with your team's communications while coding. Find relevant discussions and context quickly.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Slack workspace.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Slack Connector](https://www.claude.com/connectors/slack) for more information.
|
||||
8
external_plugins/supabase/.claude-plugin/plugin.json
Normal file
8
external_plugins/supabase/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "supabase",
|
||||
"description": "Supabase MCP integration for database operations, authentication, storage, and real-time subscriptions. Manage your Supabase projects, run SQL queries, and interact with your backend directly.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Supabase"
|
||||
}
|
||||
}
|
||||
6
external_plugins/supabase/.mcp.json
Normal file
6
external_plugins/supabase/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"supabase": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.supabase.com/mcp"
|
||||
}
|
||||
}
|
||||
21
external_plugins/supabase/README.md
Normal file
21
external_plugins/supabase/README.md
Normal file
@@ -0,0 +1,21 @@
|
||||
# Supabase Plugin
|
||||
|
||||
Supabase MCP integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Manage your Supabase projects, run SQL queries, handle authentication, storage, and real-time subscriptions directly from Claude Code.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via dynamic client registration in most cases.
|
||||
|
||||
## Optional: CI Environment Configuration
|
||||
|
||||
For CI environments, set these environment variables:
|
||||
- `SUPABASE_PROJECT_REF` - Your Supabase project reference
|
||||
- `SUPABASE_ACCESS_TOKEN` - Personal access token with appropriate scopes
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Supabase MCP Documentation](https://supabase.com/docs/guides/getting-started/mcp) for detailed setup instructions.
|
||||
8
external_plugins/vercel/.claude-plugin/plugin.json
Normal file
8
external_plugins/vercel/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,8 @@
|
||||
{
|
||||
"name": "vercel",
|
||||
"description": "Vercel deployment platform integration. Manage deployments, check build status, access logs, configure domains, and control your frontend infrastructure directly from Claude Code.",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Vercel"
|
||||
}
|
||||
}
|
||||
6
external_plugins/vercel/.mcp.json
Normal file
6
external_plugins/vercel/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"vercel": {
|
||||
"type": "sse",
|
||||
"url": "https://mcp.vercel.com/sse"
|
||||
}
|
||||
}
|
||||
15
external_plugins/vercel/README.md
Normal file
15
external_plugins/vercel/README.md
Normal file
@@ -0,0 +1,15 @@
|
||||
# Vercel Plugin
|
||||
|
||||
Vercel deployment platform integration for Claude Code.
|
||||
|
||||
## What It Does
|
||||
|
||||
Manage deployments, check build status, access logs, configure domains, and control your frontend infrastructure directly from Claude Code.
|
||||
|
||||
## Setup
|
||||
|
||||
Authentication is handled automatically via OAuth when you first use the plugin. You will be prompted to authorize access to your Vercel account.
|
||||
|
||||
## Learn More
|
||||
|
||||
See [Vercel Connector](https://www.claude.com/connectors) for more information.
|
||||
103
plugins/README.md
Normal file
103
plugins/README.md
Normal file
@@ -0,0 +1,103 @@
|
||||
# Claude Code Plugins
|
||||
|
||||
This directory contains some official Claude Code plugins that extend functionality through custom commands, agents, and workflows. These are examples of what's possible with the Claude Code plugin system—many more plugins are available through community marketplaces.
|
||||
|
||||
## What are Claude Code Plugins?
|
||||
|
||||
Claude Code plugins are extensions that enhance Claude Code with custom slash commands, specialized agents, hooks, and MCP servers. Plugins can be shared across projects and teams, providing consistent tooling and workflows.
|
||||
|
||||
Learn more in the [official plugins documentation](https://docs.claude.com/en/docs/claude-code/plugins).
|
||||
|
||||
## Plugins in This Directory
|
||||
|
||||
### [agent-sdk-dev](./agent-sdk-dev/)
|
||||
|
||||
**Claude Agent SDK Development Plugin**
|
||||
|
||||
Streamlines the development of Claude Agent SDK applications with scaffolding commands and verification agents.
|
||||
|
||||
- **Command**: `/new-sdk-app` - Interactive setup for new Agent SDK projects
|
||||
- **Agents**: `agent-sdk-verifier-py` and `agent-sdk-verifier-ts` - Validate SDK applications against best practices
|
||||
- **Use case**: Creating and verifying Claude Agent SDK applications in Python or TypeScript
|
||||
|
||||
### [commit-commands](./commit-commands/)
|
||||
|
||||
**Git Workflow Automation Plugin**
|
||||
|
||||
Simplifies common git operations with streamlined commands for committing, pushing, and creating pull requests.
|
||||
|
||||
- **Commands**:
|
||||
- `/commit` - Create a git commit with appropriate message
|
||||
- `/commit-push-pr` - Commit, push, and create a PR in one command
|
||||
- `/clean_gone` - Clean up stale local branches marked as [gone]
|
||||
- **Use case**: Faster git workflows with less context switching
|
||||
|
||||
### [code-review](./code-review/)
|
||||
|
||||
**Automated Pull Request Code Review Plugin**
|
||||
|
||||
Provides automated code review for pull requests using multiple specialized agents with confidence-based scoring to filter false positives.
|
||||
|
||||
- **Command**:
|
||||
- `/code-review` - Automated PR review workflow
|
||||
- **Use case**: Automated code review on pull requests with high-confidence issue detection (threshold ≥80)
|
||||
|
||||
### [feature-dev](./feature-dev/)
|
||||
|
||||
**Comprehensive Feature Development Workflow Plugin**
|
||||
|
||||
Provides a structured 7-phase approach to feature development with specialized agents for exploration, architecture, and review.
|
||||
|
||||
- **Command**: `/feature-dev` - Guided feature development workflow
|
||||
- **Agents**:
|
||||
- `code-explorer` - Deeply analyzes existing codebase features
|
||||
- `code-architect` - Designs feature architectures and implementation blueprints
|
||||
- `code-reviewer` - Reviews code for bugs, quality issues, and project conventions
|
||||
- **Use case**: Building new features with systematic codebase understanding and quality assurance
|
||||
|
||||
## Installation
|
||||
|
||||
These plugins are included in the Claude Code repository. To use them in your own projects:
|
||||
|
||||
1. Install Claude Code globally:
|
||||
```bash
|
||||
npm install -g @anthropic-ai/claude-code
|
||||
```
|
||||
|
||||
2. Navigate to your project and run Claude Code:
|
||||
```bash
|
||||
claude
|
||||
```
|
||||
|
||||
3. Use the `/plugin` command to install plugins from marketplaces, or configure them in your project's `.claude/settings.json`.
|
||||
|
||||
For detailed plugin installation and configuration, see the [official documentation](https://docs.claude.com/en/docs/claude-code/plugins).
|
||||
|
||||
## Plugin Structure
|
||||
|
||||
Each plugin follows the standard Claude Code plugin structure:
|
||||
|
||||
```
|
||||
plugin-name/
|
||||
├── .claude-plugin/
|
||||
│ └── plugin.json # Plugin metadata
|
||||
├── commands/ # Slash commands (optional)
|
||||
├── agents/ # Specialized agents (optional)
|
||||
└── README.md # Plugin documentation
|
||||
```
|
||||
|
||||
## Contributing
|
||||
|
||||
When adding new plugins to this directory:
|
||||
|
||||
1. Follow the standard plugin structure
|
||||
2. Include a comprehensive README.md
|
||||
3. Add plugin metadata in `.claude-plugin/plugin.json`
|
||||
4. Document all commands and agents
|
||||
5. Provide usage examples
|
||||
|
||||
## Learn More
|
||||
|
||||
- [Claude Code Documentation](https://docs.claude.com/en/docs/claude-code/overview)
|
||||
- [Plugin System Documentation](https://docs.claude.com/en/docs/claude-code/plugins)
|
||||
- [Agent SDK Documentation](https://docs.claude.com/en/api/agent-sdk/overview)
|
||||
9
plugins/agent-sdk-dev/.claude-plugin/plugin.json
Normal file
9
plugins/agent-sdk-dev/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"name": "agent-sdk-dev",
|
||||
"description": "Claude Agent SDK Development Plugin",
|
||||
"version": "1.0.0",
|
||||
"author": {
|
||||
"name": "Ashwin Bhat",
|
||||
"email": "ashwin@anthropic.com"
|
||||
}
|
||||
}
|
||||
208
plugins/agent-sdk-dev/README.md
Normal file
208
plugins/agent-sdk-dev/README.md
Normal file
@@ -0,0 +1,208 @@
|
||||
# Agent SDK Development Plugin
|
||||
|
||||
A comprehensive plugin for creating and verifying Claude Agent SDK applications in Python and TypeScript.
|
||||
|
||||
## Overview
|
||||
|
||||
The Agent SDK Development Plugin streamlines the entire lifecycle of building Agent SDK applications, from initial scaffolding to verification against best practices. It helps you quickly start new projects with the latest SDK versions and ensures your applications follow official documentation patterns.
|
||||
|
||||
## Features
|
||||
|
||||
### Command: `/new-sdk-app`
|
||||
|
||||
Interactive command that guides you through creating a new Claude Agent SDK application.
|
||||
|
||||
**What it does:**
|
||||
- Asks clarifying questions about your project (language, name, agent type, starting point)
|
||||
- Checks for and installs the latest SDK version
|
||||
- Creates all necessary project files and configuration
|
||||
- Sets up proper environment files (.env.example, .gitignore)
|
||||
- Provides a working example tailored to your use case
|
||||
- Runs type checking (TypeScript) or syntax validation (Python)
|
||||
- Automatically verifies the setup using the appropriate verifier agent
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
/new-sdk-app my-project-name
|
||||
```
|
||||
|
||||
Or simply:
|
||||
```bash
|
||||
/new-sdk-app
|
||||
```
|
||||
|
||||
The command will interactively ask you:
|
||||
1. Language choice (TypeScript or Python)
|
||||
2. Project name (if not provided)
|
||||
3. Agent type (coding, business, custom)
|
||||
4. Starting point (minimal, basic, or specific example)
|
||||
5. Tooling preferences (npm/yarn/pnpm or pip/poetry)
|
||||
|
||||
**Example:**
|
||||
```bash
|
||||
/new-sdk-app customer-support-agent
|
||||
# → Creates a new Agent SDK project for a customer support agent
|
||||
# → Sets up TypeScript or Python environment
|
||||
# → Installs latest SDK version
|
||||
# → Verifies the setup automatically
|
||||
```
|
||||
|
||||
### Agent: `agent-sdk-verifier-py`
|
||||
|
||||
Thoroughly verifies Python Agent SDK applications for correct setup and best practices.
|
||||
|
||||
**Verification checks:**
|
||||
- SDK installation and version
|
||||
- Python environment setup (requirements.txt, pyproject.toml)
|
||||
- Correct SDK usage and patterns
|
||||
- Agent initialization and configuration
|
||||
- Environment and security (.env, API keys)
|
||||
- Error handling and functionality
|
||||
- Documentation completeness
|
||||
|
||||
**When to use:**
|
||||
- After creating a new Python SDK project
|
||||
- After modifying an existing Python SDK application
|
||||
- Before deploying a Python SDK application
|
||||
|
||||
**Usage:**
|
||||
The agent runs automatically after `/new-sdk-app` creates a Python project, or you can trigger it by asking:
|
||||
```
|
||||
"Verify my Python Agent SDK application"
|
||||
"Check if my SDK app follows best practices"
|
||||
```
|
||||
|
||||
**Output:**
|
||||
Provides a comprehensive report with:
|
||||
- Overall status (PASS / PASS WITH WARNINGS / FAIL)
|
||||
- Critical issues that prevent functionality
|
||||
- Warnings about suboptimal patterns
|
||||
- List of passed checks
|
||||
- Specific recommendations with SDK documentation references
|
||||
|
||||
### Agent: `agent-sdk-verifier-ts`
|
||||
|
||||
Thoroughly verifies TypeScript Agent SDK applications for correct setup and best practices.
|
||||
|
||||
**Verification checks:**
|
||||
- SDK installation and version
|
||||
- TypeScript configuration (tsconfig.json)
|
||||
- Correct SDK usage and patterns
|
||||
- Type safety and imports
|
||||
- Agent initialization and configuration
|
||||
- Environment and security (.env, API keys)
|
||||
- Error handling and functionality
|
||||
- Documentation completeness
|
||||
|
||||
**When to use:**
|
||||
- After creating a new TypeScript SDK project
|
||||
- After modifying an existing TypeScript SDK application
|
||||
- Before deploying a TypeScript SDK application
|
||||
|
||||
**Usage:**
|
||||
The agent runs automatically after `/new-sdk-app` creates a TypeScript project, or you can trigger it by asking:
|
||||
```
|
||||
"Verify my TypeScript Agent SDK application"
|
||||
"Check if my SDK app follows best practices"
|
||||
```
|
||||
|
||||
**Output:**
|
||||
Provides a comprehensive report with:
|
||||
- Overall status (PASS / PASS WITH WARNINGS / FAIL)
|
||||
- Critical issues that prevent functionality
|
||||
- Warnings about suboptimal patterns
|
||||
- List of passed checks
|
||||
- Specific recommendations with SDK documentation references
|
||||
|
||||
## Workflow Example
|
||||
|
||||
Here's a typical workflow using this plugin:
|
||||
|
||||
1. **Create a new project:**
|
||||
```bash
|
||||
/new-sdk-app code-reviewer-agent
|
||||
```
|
||||
|
||||
2. **Answer the interactive questions:**
|
||||
```
|
||||
Language: TypeScript
|
||||
Agent type: Coding agent (code review)
|
||||
Starting point: Basic agent with common features
|
||||
```
|
||||
|
||||
3. **Automatic verification:**
|
||||
The command automatically runs `agent-sdk-verifier-ts` to ensure everything is correctly set up.
|
||||
|
||||
4. **Start developing:**
|
||||
```bash
|
||||
# Set your API key
|
||||
echo "ANTHROPIC_API_KEY=your_key_here" > .env
|
||||
|
||||
# Run your agent
|
||||
npm start
|
||||
```
|
||||
|
||||
5. **Verify after changes:**
|
||||
```
|
||||
"Verify my SDK application"
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
This plugin is included in the Claude Code repository. To use it:
|
||||
|
||||
1. Ensure Claude Code is installed
|
||||
2. The plugin commands and agents are automatically available
|
||||
|
||||
## Best Practices
|
||||
|
||||
- **Always use the latest SDK version**: `/new-sdk-app` checks for and installs the latest version
|
||||
- **Verify before deploying**: Run the verifier agent before deploying to production
|
||||
- **Keep API keys secure**: Never commit `.env` files or hardcode API keys
|
||||
- **Follow SDK documentation**: The verifier agents check against official patterns
|
||||
- **Type check TypeScript projects**: Run `npx tsc --noEmit` regularly
|
||||
- **Test your agents**: Create test cases for your agent's functionality
|
||||
|
||||
## Resources
|
||||
|
||||
- [Agent SDK Overview](https://docs.claude.com/en/api/agent-sdk/overview)
|
||||
- [TypeScript SDK Reference](https://docs.claude.com/en/api/agent-sdk/typescript)
|
||||
- [Python SDK Reference](https://docs.claude.com/en/api/agent-sdk/python)
|
||||
- [Agent SDK Examples](https://docs.claude.com/en/api/agent-sdk/examples)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Type errors in TypeScript project
|
||||
|
||||
**Issue**: TypeScript project has type errors after creation
|
||||
|
||||
**Solution**:
|
||||
- The `/new-sdk-app` command runs type checking automatically
|
||||
- If errors persist, check that you're using the latest SDK version
|
||||
- Verify your `tsconfig.json` matches SDK requirements
|
||||
|
||||
### Python import errors
|
||||
|
||||
**Issue**: Cannot import from `claude_agent_sdk`
|
||||
|
||||
**Solution**:
|
||||
- Ensure you've installed dependencies: `pip install -r requirements.txt`
|
||||
- Activate your virtual environment if using one
|
||||
- Check that the SDK is installed: `pip show claude-agent-sdk`
|
||||
|
||||
### Verification fails with warnings
|
||||
|
||||
**Issue**: Verifier agent reports warnings
|
||||
|
||||
**Solution**:
|
||||
- Review the specific warnings in the report
|
||||
- Check the SDK documentation references provided
|
||||
- Warnings don't prevent functionality but indicate areas for improvement
|
||||
|
||||
## Author
|
||||
|
||||
Ashwin Bhat (ashwin@anthropic.com)
|
||||
|
||||
## Version
|
||||
|
||||
1.0.0
|
||||
140
plugins/agent-sdk-dev/agents/agent-sdk-verifier-py.md
Normal file
140
plugins/agent-sdk-dev/agents/agent-sdk-verifier-py.md
Normal file
@@ -0,0 +1,140 @@
|
||||
---
|
||||
name: agent-sdk-verifier-py
|
||||
description: Use this agent to verify that a Python Agent SDK application is properly configured, follows SDK best practices and documentation recommendations, and is ready for deployment or testing. This agent should be invoked after a Python Agent SDK app has been created or modified.
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
You are a Python Agent SDK application verifier. Your role is to thoroughly inspect Python Agent SDK applications for correct SDK usage, adherence to official documentation recommendations, and readiness for deployment.
|
||||
|
||||
## Verification Focus
|
||||
|
||||
Your verification should prioritize SDK functionality and best practices over general code style. Focus on:
|
||||
|
||||
1. **SDK Installation and Configuration**:
|
||||
|
||||
- Verify `claude-agent-sdk` is installed (check requirements.txt, pyproject.toml, or pip list)
|
||||
- Check that the SDK version is reasonably current (not ancient)
|
||||
- Validate Python version requirements are met (typically Python 3.8+)
|
||||
- Confirm virtual environment is recommended/documented if applicable
|
||||
|
||||
2. **Python Environment Setup**:
|
||||
|
||||
- Check for requirements.txt or pyproject.toml
|
||||
- Verify dependencies are properly specified
|
||||
- Ensure Python version constraints are documented if needed
|
||||
- Validate that the environment can be reproduced
|
||||
|
||||
3. **SDK Usage and Patterns**:
|
||||
|
||||
- Verify correct imports from `claude_agent_sdk` (or appropriate SDK module)
|
||||
- Check that agents are properly initialized according to SDK docs
|
||||
- Validate that agent configuration follows SDK patterns (system prompts, models, etc.)
|
||||
- Ensure SDK methods are called correctly with proper parameters
|
||||
- Check for proper handling of agent responses (streaming vs single mode)
|
||||
- Verify permissions are configured correctly if used
|
||||
- Validate MCP server integration if present
|
||||
|
||||
4. **Code Quality**:
|
||||
|
||||
- Check for basic syntax errors
|
||||
- Verify imports are correct and available
|
||||
- Ensure proper error handling
|
||||
- Validate that the code structure makes sense for the SDK
|
||||
|
||||
5. **Environment and Security**:
|
||||
|
||||
- Check that `.env.example` exists with `ANTHROPIC_API_KEY`
|
||||
- Verify `.env` is in `.gitignore`
|
||||
- Ensure API keys are not hardcoded in source files
|
||||
- Validate proper error handling around API calls
|
||||
|
||||
6. **SDK Best Practices** (based on official docs):
|
||||
|
||||
- System prompts are clear and well-structured
|
||||
- Appropriate model selection for the use case
|
||||
- Permissions are properly scoped if used
|
||||
- Custom tools (MCP) are correctly integrated if present
|
||||
- Subagents are properly configured if used
|
||||
- Session handling is correct if applicable
|
||||
|
||||
7. **Functionality Validation**:
|
||||
|
||||
- Verify the application structure makes sense for the SDK
|
||||
- Check that agent initialization and execution flow is correct
|
||||
- Ensure error handling covers SDK-specific errors
|
||||
- Validate that the app follows SDK documentation patterns
|
||||
|
||||
8. **Documentation**:
|
||||
- Check for README or basic documentation
|
||||
- Verify setup instructions are present (including virtual environment setup)
|
||||
- Ensure any custom configurations are documented
|
||||
- Confirm installation instructions are clear
|
||||
|
||||
## What NOT to Focus On
|
||||
|
||||
- General code style preferences (PEP 8 formatting, naming conventions, etc.)
|
||||
- Python-specific style choices (snake_case vs camelCase debates)
|
||||
- Import ordering preferences
|
||||
- General Python best practices unrelated to SDK usage
|
||||
|
||||
## Verification Process
|
||||
|
||||
1. **Read the relevant files**:
|
||||
|
||||
- requirements.txt or pyproject.toml
|
||||
- Main application files (main.py, app.py, src/\*, etc.)
|
||||
- .env.example and .gitignore
|
||||
- Any configuration files
|
||||
|
||||
2. **Check SDK Documentation Adherence**:
|
||||
|
||||
- Use WebFetch to reference the official Python SDK docs: https://docs.claude.com/en/api/agent-sdk/python
|
||||
- Compare the implementation against official patterns and recommendations
|
||||
- Note any deviations from documented best practices
|
||||
|
||||
3. **Validate Imports and Syntax**:
|
||||
|
||||
- Check that all imports are correct
|
||||
- Look for obvious syntax errors
|
||||
- Verify SDK is properly imported
|
||||
|
||||
4. **Analyze SDK Usage**:
|
||||
- Verify SDK methods are used correctly
|
||||
- Check that configuration options match SDK documentation
|
||||
- Validate that patterns follow official examples
|
||||
|
||||
## Verification Report Format
|
||||
|
||||
Provide a comprehensive report:
|
||||
|
||||
**Overall Status**: PASS | PASS WITH WARNINGS | FAIL
|
||||
|
||||
**Summary**: Brief overview of findings
|
||||
|
||||
**Critical Issues** (if any):
|
||||
|
||||
- Issues that prevent the app from functioning
|
||||
- Security problems
|
||||
- SDK usage errors that will cause runtime failures
|
||||
- Syntax errors or import problems
|
||||
|
||||
**Warnings** (if any):
|
||||
|
||||
- Suboptimal SDK usage patterns
|
||||
- Missing SDK features that would improve the app
|
||||
- Deviations from SDK documentation recommendations
|
||||
- Missing documentation or setup instructions
|
||||
|
||||
**Passed Checks**:
|
||||
|
||||
- What is correctly configured
|
||||
- SDK features properly implemented
|
||||
- Security measures in place
|
||||
|
||||
**Recommendations**:
|
||||
|
||||
- Specific suggestions for improvement
|
||||
- References to SDK documentation
|
||||
- Next steps for enhancement
|
||||
|
||||
Be thorough but constructive. Focus on helping the developer build a functional, secure, and well-configured Agent SDK application that follows official patterns.
|
||||
145
plugins/agent-sdk-dev/agents/agent-sdk-verifier-ts.md
Normal file
145
plugins/agent-sdk-dev/agents/agent-sdk-verifier-ts.md
Normal file
@@ -0,0 +1,145 @@
|
||||
---
|
||||
name: agent-sdk-verifier-ts
|
||||
description: Use this agent to verify that a TypeScript Agent SDK application is properly configured, follows SDK best practices and documentation recommendations, and is ready for deployment or testing. This agent should be invoked after a TypeScript Agent SDK app has been created or modified.
|
||||
model: sonnet
|
||||
---
|
||||
|
||||
You are a TypeScript Agent SDK application verifier. Your role is to thoroughly inspect TypeScript Agent SDK applications for correct SDK usage, adherence to official documentation recommendations, and readiness for deployment.
|
||||
|
||||
## Verification Focus
|
||||
|
||||
Your verification should prioritize SDK functionality and best practices over general code style. Focus on:
|
||||
|
||||
1. **SDK Installation and Configuration**:
|
||||
|
||||
- Verify `@anthropic-ai/claude-agent-sdk` is installed
|
||||
- Check that the SDK version is reasonably current (not ancient)
|
||||
- Confirm package.json has `"type": "module"` for ES modules support
|
||||
- Validate that Node.js version requirements are met (check package.json engines field if present)
|
||||
|
||||
2. **TypeScript Configuration**:
|
||||
|
||||
- Verify tsconfig.json exists and has appropriate settings for the SDK
|
||||
- Check module resolution settings (should support ES modules)
|
||||
- Ensure target is modern enough for the SDK
|
||||
- Validate that compilation settings won't break SDK imports
|
||||
|
||||
3. **SDK Usage and Patterns**:
|
||||
|
||||
- Verify correct imports from `@anthropic-ai/claude-agent-sdk`
|
||||
- Check that agents are properly initialized according to SDK docs
|
||||
- Validate that agent configuration follows SDK patterns (system prompts, models, etc.)
|
||||
- Ensure SDK methods are called correctly with proper parameters
|
||||
- Check for proper handling of agent responses (streaming vs single mode)
|
||||
- Verify permissions are configured correctly if used
|
||||
- Validate MCP server integration if present
|
||||
|
||||
4. **Type Safety and Compilation**:
|
||||
|
||||
- Run `npx tsc --noEmit` to check for type errors
|
||||
- Verify that all SDK imports have correct type definitions
|
||||
- Ensure the code compiles without errors
|
||||
- Check that types align with SDK documentation
|
||||
|
||||
5. **Scripts and Build Configuration**:
|
||||
|
||||
- Verify package.json has necessary scripts (build, start, typecheck)
|
||||
- Check that scripts are correctly configured for TypeScript/ES modules
|
||||
- Validate that the application can be built and run
|
||||
|
||||
6. **Environment and Security**:
|
||||
|
||||
- Check that `.env.example` exists with `ANTHROPIC_API_KEY`
|
||||
- Verify `.env` is in `.gitignore`
|
||||
- Ensure API keys are not hardcoded in source files
|
||||
- Validate proper error handling around API calls
|
||||
|
||||
7. **SDK Best Practices** (based on official docs):
|
||||
|
||||
- System prompts are clear and well-structured
|
||||
- Appropriate model selection for the use case
|
||||
- Permissions are properly scoped if used
|
||||
- Custom tools (MCP) are correctly integrated if present
|
||||
- Subagents are properly configured if used
|
||||
- Session handling is correct if applicable
|
||||
|
||||
8. **Functionality Validation**:
|
||||
|
||||
- Verify the application structure makes sense for the SDK
|
||||
- Check that agent initialization and execution flow is correct
|
||||
- Ensure error handling covers SDK-specific errors
|
||||
- Validate that the app follows SDK documentation patterns
|
||||
|
||||
9. **Documentation**:
|
||||
- Check for README or basic documentation
|
||||
- Verify setup instructions are present if needed
|
||||
- Ensure any custom configurations are documented
|
||||
|
||||
## What NOT to Focus On
|
||||
|
||||
- General code style preferences (formatting, naming conventions, etc.)
|
||||
- Whether developers use `type` vs `interface` or other TypeScript style choices
|
||||
- Unused variable naming conventions
|
||||
- General TypeScript best practices unrelated to SDK usage
|
||||
|
||||
## Verification Process
|
||||
|
||||
1. **Read the relevant files**:
|
||||
|
||||
- package.json
|
||||
- tsconfig.json
|
||||
- Main application files (index.ts, src/\*, etc.)
|
||||
- .env.example and .gitignore
|
||||
- Any configuration files
|
||||
|
||||
2. **Check SDK Documentation Adherence**:
|
||||
|
||||
- Use WebFetch to reference the official TypeScript SDK docs: https://docs.claude.com/en/api/agent-sdk/typescript
|
||||
- Compare the implementation against official patterns and recommendations
|
||||
- Note any deviations from documented best practices
|
||||
|
||||
3. **Run Type Checking**:
|
||||
|
||||
- Execute `npx tsc --noEmit` to verify no type errors
|
||||
- Report any compilation issues
|
||||
|
||||
4. **Analyze SDK Usage**:
|
||||
- Verify SDK methods are used correctly
|
||||
- Check that configuration options match SDK documentation
|
||||
- Validate that patterns follow official examples
|
||||
|
||||
## Verification Report Format
|
||||
|
||||
Provide a comprehensive report:
|
||||
|
||||
**Overall Status**: PASS | PASS WITH WARNINGS | FAIL
|
||||
|
||||
**Summary**: Brief overview of findings
|
||||
|
||||
**Critical Issues** (if any):
|
||||
|
||||
- Issues that prevent the app from functioning
|
||||
- Security problems
|
||||
- SDK usage errors that will cause runtime failures
|
||||
- Type errors or compilation failures
|
||||
|
||||
**Warnings** (if any):
|
||||
|
||||
- Suboptimal SDK usage patterns
|
||||
- Missing SDK features that would improve the app
|
||||
- Deviations from SDK documentation recommendations
|
||||
- Missing documentation
|
||||
|
||||
**Passed Checks**:
|
||||
|
||||
- What is correctly configured
|
||||
- SDK features properly implemented
|
||||
- Security measures in place
|
||||
|
||||
**Recommendations**:
|
||||
|
||||
- Specific suggestions for improvement
|
||||
- References to SDK documentation
|
||||
- Next steps for enhancement
|
||||
|
||||
Be thorough but constructive. Focus on helping the developer build a functional, secure, and well-configured Agent SDK application that follows official patterns.
|
||||
176
plugins/agent-sdk-dev/commands/new-sdk-app.md
Normal file
176
plugins/agent-sdk-dev/commands/new-sdk-app.md
Normal file
@@ -0,0 +1,176 @@
|
||||
---
|
||||
description: Create and setup a new Claude Agent SDK application
|
||||
argument-hint: [project-name]
|
||||
---
|
||||
|
||||
You are tasked with helping the user create a new Claude Agent SDK application. Follow these steps carefully:
|
||||
|
||||
## Reference Documentation
|
||||
|
||||
Before starting, review the official documentation to ensure you provide accurate and up-to-date guidance. Use WebFetch to read these pages:
|
||||
|
||||
1. **Start with the overview**: https://docs.claude.com/en/api/agent-sdk/overview
|
||||
2. **Based on the user's language choice, read the appropriate SDK reference**:
|
||||
- TypeScript: https://docs.claude.com/en/api/agent-sdk/typescript
|
||||
- Python: https://docs.claude.com/en/api/agent-sdk/python
|
||||
3. **Read relevant guides mentioned in the overview** such as:
|
||||
- Streaming vs Single Mode
|
||||
- Permissions
|
||||
- Custom Tools
|
||||
- MCP integration
|
||||
- Subagents
|
||||
- Sessions
|
||||
- Any other relevant guides based on the user's needs
|
||||
|
||||
**IMPORTANT**: Always check for and use the latest versions of packages. Use WebSearch or WebFetch to verify current versions before installation.
|
||||
|
||||
## Gather Requirements
|
||||
|
||||
IMPORTANT: Ask these questions one at a time. Wait for the user's response before asking the next question. This makes it easier for the user to respond.
|
||||
|
||||
Ask the questions in this order (skip any that the user has already provided via arguments):
|
||||
|
||||
1. **Language** (ask first): "Would you like to use TypeScript or Python?"
|
||||
|
||||
- Wait for response before continuing
|
||||
|
||||
2. **Project name** (ask second): "What would you like to name your project?"
|
||||
|
||||
- If $ARGUMENTS is provided, use that as the project name and skip this question
|
||||
- Wait for response before continuing
|
||||
|
||||
3. **Agent type** (ask third, but skip if #2 was sufficiently detailed): "What kind of agent are you building? Some examples:
|
||||
|
||||
- Coding agent (SRE, security review, code review)
|
||||
- Business agent (customer support, content creation)
|
||||
- Custom agent (describe your use case)"
|
||||
- Wait for response before continuing
|
||||
|
||||
4. **Starting point** (ask fourth): "Would you like:
|
||||
|
||||
- A minimal 'Hello World' example to start
|
||||
- A basic agent with common features
|
||||
- A specific example based on your use case"
|
||||
- Wait for response before continuing
|
||||
|
||||
5. **Tooling choice** (ask fifth): Let the user know what tools you'll use, and confirm with them that these are the tools they want to use (for example, they may prefer pnpm or bun over npm). Respect the user's preferences when executing on the requirements.
|
||||
|
||||
After all questions are answered, proceed to create the setup plan.
|
||||
|
||||
## Setup Plan
|
||||
|
||||
Based on the user's answers, create a plan that includes:
|
||||
|
||||
1. **Project initialization**:
|
||||
|
||||
- Create project directory (if it doesn't exist)
|
||||
- Initialize package manager:
|
||||
- TypeScript: `npm init -y` and setup `package.json` with type: "module" and scripts (include a "typecheck" script)
|
||||
- Python: Create `requirements.txt` or use `poetry init`
|
||||
- Add necessary configuration files:
|
||||
- TypeScript: Create `tsconfig.json` with proper settings for the SDK
|
||||
- Python: Optionally create config files if needed
|
||||
|
||||
2. **Check for Latest Versions**:
|
||||
|
||||
- BEFORE installing, use WebSearch or check npm/PyPI to find the latest version
|
||||
- For TypeScript: Check https://www.npmjs.com/package/@anthropic-ai/claude-agent-sdk
|
||||
- For Python: Check https://pypi.org/project/claude-agent-sdk/
|
||||
- Inform the user which version you're installing
|
||||
|
||||
3. **SDK Installation**:
|
||||
|
||||
- TypeScript: `npm install @anthropic-ai/claude-agent-sdk@latest` (or specify latest version)
|
||||
- Python: `pip install claude-agent-sdk` (pip installs latest by default)
|
||||
- After installation, verify the installed version:
|
||||
- TypeScript: Check package.json or run `npm list @anthropic-ai/claude-agent-sdk`
|
||||
- Python: Run `pip show claude-agent-sdk`
|
||||
|
||||
4. **Create starter files**:
|
||||
|
||||
- TypeScript: Create an `index.ts` or `src/index.ts` with a basic query example
|
||||
- Python: Create a `main.py` with a basic query example
|
||||
- Include proper imports and basic error handling
|
||||
- Use modern, up-to-date syntax and patterns from the latest SDK version
|
||||
|
||||
5. **Environment setup**:
|
||||
|
||||
- Create a `.env.example` file with `ANTHROPIC_API_KEY=your_api_key_here`
|
||||
- Add `.env` to `.gitignore`
|
||||
- Explain how to get an API key from https://console.anthropic.com/
|
||||
|
||||
6. **Optional: Create .claude directory structure**:
|
||||
- Offer to create `.claude/` directory for agents, commands, and settings
|
||||
- Ask if they want any example subagents or slash commands
|
||||
|
||||
## Implementation
|
||||
|
||||
After gathering requirements and getting user confirmation on the plan:
|
||||
|
||||
1. Check for latest package versions using WebSearch or WebFetch
|
||||
2. Execute the setup steps
|
||||
3. Create all necessary files
|
||||
4. Install dependencies (always use latest stable versions)
|
||||
5. Verify installed versions and inform the user
|
||||
6. Create a working example based on their agent type
|
||||
7. Add helpful comments in the code explaining what each part does
|
||||
8. **VERIFY THE CODE WORKS BEFORE FINISHING**:
|
||||
- For TypeScript:
|
||||
- Run `npx tsc --noEmit` to check for type errors
|
||||
- Fix ALL type errors until types pass completely
|
||||
- Ensure imports and types are correct
|
||||
- Only proceed when type checking passes with no errors
|
||||
- For Python:
|
||||
- Verify imports are correct
|
||||
- Check for basic syntax errors
|
||||
- **DO NOT consider the setup complete until the code verifies successfully**
|
||||
|
||||
## Verification
|
||||
|
||||
After all files are created and dependencies are installed, use the appropriate verifier agent to validate that the Agent SDK application is properly configured and ready for use:
|
||||
|
||||
1. **For TypeScript projects**: Launch the **agent-sdk-verifier-ts** agent to validate the setup
|
||||
2. **For Python projects**: Launch the **agent-sdk-verifier-py** agent to validate the setup
|
||||
3. The agent will check SDK usage, configuration, functionality, and adherence to official documentation
|
||||
4. Review the verification report and address any issues
|
||||
|
||||
## Getting Started Guide
|
||||
|
||||
Once setup is complete and verified, provide the user with:
|
||||
|
||||
1. **Next steps**:
|
||||
|
||||
- How to set their API key
|
||||
- How to run their agent:
|
||||
- TypeScript: `npm start` or `node --loader ts-node/esm index.ts`
|
||||
- Python: `python main.py`
|
||||
|
||||
2. **Useful resources**:
|
||||
|
||||
- Link to TypeScript SDK reference: https://docs.claude.com/en/api/agent-sdk/typescript
|
||||
- Link to Python SDK reference: https://docs.claude.com/en/api/agent-sdk/python
|
||||
- Explain key concepts: system prompts, permissions, tools, MCP servers
|
||||
|
||||
3. **Common next steps**:
|
||||
- How to customize the system prompt
|
||||
- How to add custom tools via MCP
|
||||
- How to configure permissions
|
||||
- How to create subagents
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **ALWAYS USE LATEST VERSIONS**: Before installing any packages, check for the latest versions using WebSearch or by checking npm/PyPI directly
|
||||
- **VERIFY CODE RUNS CORRECTLY**:
|
||||
- For TypeScript: Run `npx tsc --noEmit` and fix ALL type errors before finishing
|
||||
- For Python: Verify syntax and imports are correct
|
||||
- Do NOT consider the task complete until the code passes verification
|
||||
- Verify the installed version after installation and inform the user
|
||||
- Check the official documentation for any version-specific requirements (Node.js version, Python version, etc.)
|
||||
- Always check if directories/files already exist before creating them
|
||||
- Use the user's preferred package manager (npm, yarn, pnpm for TypeScript; pip, poetry for Python)
|
||||
- Ensure all code examples are functional and include proper error handling
|
||||
- Use modern syntax and patterns that are compatible with the latest SDK version
|
||||
- Make the experience interactive and educational
|
||||
- **ASK QUESTIONS ONE AT A TIME** - Do not ask multiple questions in a single response
|
||||
|
||||
Begin by asking the FIRST requirement question only. Wait for the user's answer before proceeding to the next question.
|
||||
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
|
||||
92
plugins/code-review/commands/code-review.md
Normal file
92
plugins/code-review/commands/code-review.md
Normal file
@@ -0,0 +1,92 @@
|
||||
---
|
||||
allowed-tools: Bash(gh issue view:*), Bash(gh search:*), Bash(gh issue list:*), Bash(gh pr comment:*), Bash(gh pr diff:*), Bash(gh pr view:*), Bash(gh pr list:*)
|
||||
description: Code review a pull request
|
||||
disable-model-invocation: false
|
||||
---
|
||||
|
||||
Provide a code review for the given pull request.
|
||||
|
||||
To do this, follow these steps precisely:
|
||||
|
||||
1. Use a Haiku agent to check if the pull request (a) is closed, (b) is a draft, (c) does not need a code review (eg. because it is an automated pull request, or is very simple and obviously ok), or (d) already has a code review from you from earlier. If so, do not proceed.
|
||||
2. Use another Haiku agent to give you a list of file paths to (but not the contents of) any relevant CLAUDE.md files from the codebase: the root CLAUDE.md file (if one exists), as well as any CLAUDE.md files in the directories whose files the pull request modified
|
||||
3. Use a Haiku agent to view the pull request, and ask the agent to return a summary of the change
|
||||
4. Then, launch 5 parallel Sonnet agents to independently code review the change. The agents should do the following, then return a list of issues and the reason each issue was flagged (eg. CLAUDE.md adherence, bug, historical git context, etc.):
|
||||
a. Agent #1: Audit the changes to make sure they compily with the CLAUDE.md. Note that CLAUDE.md is guidance for Claude as it writes code, so not all instructions will be applicable during code review.
|
||||
b. Agent #2: Read the file changes in the pull request, then do a shallow scan for obvious bugs. Avoid reading extra context beyond the changes, focusing just on the changes themselves. Focus on large bugs, and avoid small issues and nitpicks. Ignore likely false positives.
|
||||
c. Agent #3: Read the git blame and history of the code modified, to identify any bugs in light of that historical context
|
||||
d. Agent #4: Read previous pull requests that touched these files, and check for any comments on those pull requests that may also apply to the current pull request.
|
||||
e. Agent #5: Read code comments in the modified files, and make sure the changes in the pull request comply with any guidance in the comments.
|
||||
5. For each issue found in #4, launch a parallel Haiku agent that takes the PR, issue description, and list of CLAUDE.md files (from step 2), and returns a score to indicate the agent's level of confidence for whether the issue is real or false positive. To do that, the agent should score each issue on a scale from 0-100, indicating its level of confidence. For issues that were flagged due to CLAUDE.md instructions, the agent should double check that the CLAUDE.md actually calls out that issue specifically. The scale is (give this rubric to the agent verbatim):
|
||||
a. 0: Not confident at all. This is a false positive that doesn't stand up to light scrutiny, or is a pre-existing issue.
|
||||
b. 25: Somewhat confident. This might be a real issue, but may also be a false positive. The agent wasn't able to verify that it's a real issue. If the issue is stylistic, it is one that was not explicitly called out in the relevant CLAUDE.md.
|
||||
c. 50: Moderately confident. The agent was able to verify this is a real issue, but it might be a nitpick or not happen very often in practice. Relative to the rest of the PR, it's not very important.
|
||||
d. 75: Highly confident. The agent double checked the issue, and verified that it is very likely it is a real issue that will be hit in practice. The existing approach in the PR is insufficient. The issue is very important and will directly impact the code's functionality, or it is an issue that is directly mentioned in the relevant CLAUDE.md.
|
||||
e. 100: Absolutely certain. The agent double checked the issue, and confirmed that it is definitely a real issue, that will happen frequently in practice. The evidence directly confirms this.
|
||||
6. Filter out any issues with a score less than 80. If there are no issues that meet this criteria, do not proceed.
|
||||
7. Use a Haiku agent to repeat the eligibility check from #1, to make sure that the pull request is still eligible for code review.
|
||||
8. Finally, use the gh bash command to comment back on the pull request with the result. When writing your comment, keep in mind to:
|
||||
a. Keep your output brief
|
||||
b. Avoid emojis
|
||||
c. Link and cite relevant code, files, and URLs
|
||||
|
||||
Examples of false positives, for steps 4 and 5:
|
||||
|
||||
- Pre-existing issues
|
||||
- Something that looks like a bug but is not actually a bug
|
||||
- Pedantic nitpicks that a senior engineer wouldn't call out
|
||||
- Issues that a linter, typechecker, or compiler would catch (eg. missing or incorrect imports, type errors, broken tests, formatting issues, pedantic style issues like newlines). No need to run these build steps yourself -- it is safe to assume that they will be run separately as part of CI.
|
||||
- General code quality issues (eg. lack of test coverage, general security issues, poor documentation), unless explicitly required in CLAUDE.md
|
||||
- Issues that are called out in CLAUDE.md, but explicitly silenced in the code (eg. due to a lint ignore comment)
|
||||
- Changes in functionality that are likely intentional or are directly related to the broader change
|
||||
- Real issues, but on lines that the user did not modify in their pull request
|
||||
|
||||
Notes:
|
||||
|
||||
- Do not check build signal or attempt to build or typecheck the app. These will run separately, and are not relevant to your code review.
|
||||
- Use `gh` to interact with Github (eg. to fetch a pull request, or to create inline comments), rather than web fetch
|
||||
- Make a todo list first
|
||||
- You must cite and link each bug (eg. if referring to a CLAUDE.md, you must link it)
|
||||
- For your final comment, follow the following format precisely (assuming for this example that you found 3 issues):
|
||||
|
||||
---
|
||||
|
||||
### Code review
|
||||
|
||||
Found 3 issues:
|
||||
|
||||
1. <brief description of bug> (CLAUDE.md says "<...>")
|
||||
|
||||
<link to file and line with full sha1 + line range for context, note that you MUST provide the full sha and not use bash here, eg. https://github.com/anthropics/claude-code/blob/1d54823877c4de72b2316a64032a54afc404e619/README.md#L13-L17>
|
||||
|
||||
2. <brief description of bug> (some/other/CLAUDE.md says "<...>")
|
||||
|
||||
<link to file and line with full sha1 + line range for context>
|
||||
|
||||
3. <brief description of bug> (bug due to <file and code snippet>)
|
||||
|
||||
<link to file and line with full sha1 + line range for context>
|
||||
|
||||
🤖 Generated with [Claude Code](https://claude.ai/code)
|
||||
|
||||
<sub>- If this code review was useful, please react with 👍. Otherwise, react with 👎.</sub>
|
||||
|
||||
---
|
||||
|
||||
- Or, if you found no issues:
|
||||
|
||||
---
|
||||
|
||||
### Code review
|
||||
|
||||
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
|
||||
- You must provide the full sha. Commands like `https://github.com/owner/repo/blob/$(git rev-parse HEAD)/foo/bar` will not work, since your comment will be directly rendered in Markdown.
|
||||
- Repo name must match the repo you're code reviewing
|
||||
- # 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"
|
||||
}
|
||||
}
|
||||
|
||||
225
plugins/commit-commands/README.md
Normal file
225
plugins/commit-commands/README.md
Normal file
@@ -0,0 +1,225 @@
|
||||
# Commit Commands Plugin
|
||||
|
||||
Streamline your git workflow with simple commands for committing, pushing, and creating pull requests.
|
||||
|
||||
## Overview
|
||||
|
||||
The Commit Commands Plugin automates common git operations, reducing context switching and manual command execution. Instead of running multiple git commands, use a single slash command to handle your entire workflow.
|
||||
|
||||
## Commands
|
||||
|
||||
### `/commit`
|
||||
|
||||
Creates a git commit with an automatically generated commit message based on staged and unstaged changes.
|
||||
|
||||
**What it does:**
|
||||
1. Analyzes current git status
|
||||
2. Reviews both staged and unstaged changes
|
||||
3. Examines recent commit messages to match your repository's style
|
||||
4. Drafts an appropriate commit message
|
||||
5. Stages relevant files
|
||||
6. Creates the commit
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
/commit
|
||||
```
|
||||
|
||||
**Example workflow:**
|
||||
```bash
|
||||
# Make some changes to your code
|
||||
# Then simply run:
|
||||
/commit
|
||||
|
||||
# Claude will:
|
||||
# - Review your changes
|
||||
# - Stage the files
|
||||
# - Create a commit with an appropriate message
|
||||
# - Show you the commit status
|
||||
```
|
||||
|
||||
**Features:**
|
||||
- Automatically drafts commit messages that match your repo's style
|
||||
- Follows conventional commit practices
|
||||
- Avoids committing files with secrets (.env, credentials.json)
|
||||
- Includes Claude Code attribution in commit message
|
||||
|
||||
### `/commit-push-pr`
|
||||
|
||||
Complete workflow command that commits, pushes, and creates a pull request in one step.
|
||||
|
||||
**What it does:**
|
||||
1. Creates a new branch (if currently on main)
|
||||
2. Stages and commits changes with an appropriate message
|
||||
3. Pushes the branch to origin
|
||||
4. Creates a pull request using `gh pr create`
|
||||
5. Provides the PR URL
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
/commit-push-pr
|
||||
```
|
||||
|
||||
**Example workflow:**
|
||||
```bash
|
||||
# Make your changes
|
||||
# Then run:
|
||||
/commit-push-pr
|
||||
|
||||
# Claude will:
|
||||
# - Create a feature branch (if needed)
|
||||
# - Commit your changes
|
||||
# - Push to remote
|
||||
# - Open a PR with summary and test plan
|
||||
# - Give you the PR URL to review
|
||||
```
|
||||
|
||||
**Features:**
|
||||
- Analyzes all commits in the branch (not just the latest)
|
||||
- Creates comprehensive PR descriptions with:
|
||||
- Summary of changes (1-3 bullet points)
|
||||
- Test plan checklist
|
||||
- Claude Code attribution
|
||||
- Handles branch creation automatically
|
||||
- Uses GitHub CLI (`gh`) for PR creation
|
||||
|
||||
**Requirements:**
|
||||
- GitHub CLI (`gh`) must be installed and authenticated
|
||||
- Repository must have a remote named `origin`
|
||||
|
||||
### `/clean_gone`
|
||||
|
||||
Cleans up local branches that have been deleted from the remote repository.
|
||||
|
||||
**What it does:**
|
||||
1. Lists all local branches to identify [gone] status
|
||||
2. Identifies and removes worktrees associated with [gone] branches
|
||||
3. Deletes all branches marked as [gone]
|
||||
4. Provides feedback on removed branches
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
/clean_gone
|
||||
```
|
||||
|
||||
**Example workflow:**
|
||||
```bash
|
||||
# After PRs are merged and remote branches are deleted
|
||||
/clean_gone
|
||||
|
||||
# Claude will:
|
||||
# - Find all branches marked as [gone]
|
||||
# - Remove any associated worktrees
|
||||
# - Delete the stale local branches
|
||||
# - Report what was cleaned up
|
||||
```
|
||||
|
||||
**Features:**
|
||||
- Handles both regular branches and worktree branches
|
||||
- Safely removes worktrees before deleting branches
|
||||
- Shows clear feedback about what was removed
|
||||
- Reports if no cleanup was needed
|
||||
|
||||
**When to use:**
|
||||
- After merging and deleting remote branches
|
||||
- When your local branch list is cluttered with stale branches
|
||||
- During regular repository maintenance
|
||||
|
||||
## Installation
|
||||
|
||||
This plugin is included in the Claude Code repository. The commands are automatically available when using Claude Code.
|
||||
|
||||
## Best Practices
|
||||
|
||||
### Using `/commit`
|
||||
- Review the staged changes before committing
|
||||
- Let Claude analyze your changes and match your repo's commit style
|
||||
- Trust the automated message, but verify it's accurate
|
||||
- Use for routine commits during development
|
||||
|
||||
### Using `/commit-push-pr`
|
||||
- Use when you're ready to create a PR
|
||||
- Ensure all your changes are complete and tested
|
||||
- Claude will analyze the full branch history for the PR description
|
||||
- Review the PR description and edit if needed
|
||||
- Use when you want to minimize context switching
|
||||
|
||||
### Using `/clean_gone`
|
||||
- Run periodically to keep your branch list clean
|
||||
- Especially useful after merging multiple PRs
|
||||
- Safe to run - only removes branches already deleted remotely
|
||||
- Helps maintain a tidy local repository
|
||||
|
||||
## Workflow Integration
|
||||
|
||||
### Quick commit workflow:
|
||||
```bash
|
||||
# Write code
|
||||
/commit
|
||||
# Continue development
|
||||
```
|
||||
|
||||
### Feature branch workflow:
|
||||
```bash
|
||||
# Develop feature across multiple commits
|
||||
/commit # First commit
|
||||
# More changes
|
||||
/commit # Second commit
|
||||
# Ready to create PR
|
||||
/commit-push-pr
|
||||
```
|
||||
|
||||
### Maintenance workflow:
|
||||
```bash
|
||||
# After several PRs are merged
|
||||
/clean_gone
|
||||
# Clean workspace ready for next feature
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
- Git must be installed and configured
|
||||
- For `/commit-push-pr`: GitHub CLI (`gh`) must be installed and authenticated
|
||||
- Repository must be a git repository with a remote
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### `/commit` creates empty commit
|
||||
|
||||
**Issue**: No changes to commit
|
||||
|
||||
**Solution**:
|
||||
- Ensure you have unstaged or staged changes
|
||||
- Run `git status` to verify changes exist
|
||||
|
||||
### `/commit-push-pr` fails to create PR
|
||||
|
||||
**Issue**: `gh pr create` command fails
|
||||
|
||||
**Solution**:
|
||||
- Install GitHub CLI: `brew install gh` (macOS) or see [GitHub CLI installation](https://cli.github.com/)
|
||||
- Authenticate: `gh auth login`
|
||||
- Ensure repository has a GitHub remote
|
||||
|
||||
### `/clean_gone` doesn't find branches
|
||||
|
||||
**Issue**: No branches marked as [gone]
|
||||
|
||||
**Solution**:
|
||||
- Run `git fetch --prune` to update remote tracking
|
||||
- Branches must be deleted from the remote to show as [gone]
|
||||
|
||||
## Tips
|
||||
|
||||
- **Combine with other tools**: Use `/commit` during development, then `/commit-push-pr` when ready
|
||||
- **Let Claude draft messages**: The commit message analysis learns from your repo's style
|
||||
- **Regular cleanup**: Run `/clean_gone` weekly to maintain a clean branch list
|
||||
- **Review before pushing**: Always review the commit message and changes before pushing
|
||||
|
||||
## Author
|
||||
|
||||
Anthropic (support@anthropic.com)
|
||||
|
||||
## Version
|
||||
|
||||
1.0.0
|
||||
53
plugins/commit-commands/commands/clean_gone.md
Normal file
53
plugins/commit-commands/commands/clean_gone.md
Normal file
@@ -0,0 +1,53 @@
|
||||
---
|
||||
description: Cleans up all git branches marked as [gone] (branches that have been deleted on the remote but still exist locally), including removing associated worktrees.
|
||||
---
|
||||
|
||||
## Your Task
|
||||
|
||||
You need to execute the following bash commands to clean up stale local branches that have been deleted from the remote repository.
|
||||
|
||||
## Commands to Execute
|
||||
|
||||
1. **First, list branches to identify any with [gone] status**
|
||||
Execute this command:
|
||||
```bash
|
||||
git branch -v
|
||||
```
|
||||
|
||||
Note: Branches with a '+' prefix have associated worktrees and must have their worktrees removed before deletion.
|
||||
|
||||
2. **Next, identify worktrees that need to be removed for [gone] branches**
|
||||
Execute this command:
|
||||
```bash
|
||||
git worktree list
|
||||
```
|
||||
|
||||
3. **Finally, remove worktrees and delete [gone] branches (handles both regular and worktree branches)**
|
||||
Execute this command:
|
||||
```bash
|
||||
# Process all [gone] branches, removing '+' prefix if present
|
||||
git branch -v | grep '\[gone\]' | sed 's/^[+* ]//' | awk '{print $1}' | while read branch; do
|
||||
echo "Processing branch: $branch"
|
||||
# Find and remove worktree if it exists
|
||||
worktree=$(git worktree list | grep "\\[$branch\\]" | awk '{print $1}')
|
||||
if [ ! -z "$worktree" ] && [ "$worktree" != "$(git rev-parse --show-toplevel)" ]; then
|
||||
echo " Removing worktree: $worktree"
|
||||
git worktree remove --force "$worktree"
|
||||
fi
|
||||
# Delete the branch
|
||||
echo " Deleting branch: $branch"
|
||||
git branch -D "$branch"
|
||||
done
|
||||
```
|
||||
|
||||
## Expected Behavior
|
||||
|
||||
After executing these commands, you will:
|
||||
|
||||
- See a list of all local branches with their status
|
||||
- Identify and remove any worktrees associated with [gone] branches
|
||||
- Delete all branches marked as [gone]
|
||||
- Provide feedback on which worktrees and branches were removed
|
||||
|
||||
If no branches are marked as [gone], report that no cleanup was needed.
|
||||
|
||||
20
plugins/commit-commands/commands/commit-push-pr.md
Normal file
20
plugins/commit-commands/commands/commit-push-pr.md
Normal file
@@ -0,0 +1,20 @@
|
||||
---
|
||||
allowed-tools: Bash(git checkout --branch:*), Bash(git add:*), Bash(git status:*), Bash(git push:*), Bash(git commit:*), Bash(gh pr create:*)
|
||||
description: Commit, push, and open a PR
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Current git status: !`git status`
|
||||
- Current git diff (staged and unstaged changes): !`git diff HEAD`
|
||||
- Current branch: !`git branch --show-current`
|
||||
|
||||
## Your task
|
||||
|
||||
Based on the above changes:
|
||||
|
||||
1. Create a new branch if on main
|
||||
2. Create a single commit with an appropriate message
|
||||
3. Push the branch to origin
|
||||
4. Create a pull request using `gh pr create`
|
||||
5. You have the capability to call multiple tools in a single response. You MUST do all of the above in a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.
|
||||
17
plugins/commit-commands/commands/commit.md
Normal file
17
plugins/commit-commands/commands/commit.md
Normal file
@@ -0,0 +1,17 @@
|
||||
---
|
||||
allowed-tools: Bash(git add:*), Bash(git status:*), Bash(git commit:*)
|
||||
description: Create a git commit
|
||||
---
|
||||
|
||||
## Context
|
||||
|
||||
- Current git status: !`git status`
|
||||
- Current git diff (staged and unstaged changes): !`git diff HEAD`
|
||||
- Current branch: !`git branch --show-current`
|
||||
- Recent commits: !`git log --oneline -10`
|
||||
|
||||
## Your task
|
||||
|
||||
Based on the above changes, create a single git commit.
|
||||
|
||||
You have the capability to call multiple tools in a single response. Stage and create the commit using a single message. Do not use any other tools or do anything else. Do not send any other text or messages besides these tool calls.
|
||||
9
plugins/example-plugin/.claude-plugin/plugin.json
Normal file
9
plugins/example-plugin/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"name": "example-plugin",
|
||||
"version": "1.0.0",
|
||||
"description": "A comprehensive example plugin demonstrating all Claude Code extension options including commands, agents, skills, hooks, and MCP servers",
|
||||
"author": {
|
||||
"name": "Your Name",
|
||||
"email": "your.email@example.com"
|
||||
}
|
||||
}
|
||||
6
plugins/example-plugin/.mcp.json
Normal file
6
plugins/example-plugin/.mcp.json
Normal file
@@ -0,0 +1,6 @@
|
||||
{
|
||||
"example-server": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.example.com/api"
|
||||
}
|
||||
}
|
||||
82
plugins/example-plugin/README.md
Normal file
82
plugins/example-plugin/README.md
Normal file
@@ -0,0 +1,82 @@
|
||||
# Example Plugin
|
||||
|
||||
A comprehensive example plugin demonstrating Claude Code extension options.
|
||||
|
||||
## Structure
|
||||
|
||||
```
|
||||
example-plugin/
|
||||
├── .claude-plugin/
|
||||
│ └── plugin.json # Plugin metadata
|
||||
├── .mcp.json # MCP server configuration
|
||||
├── commands/
|
||||
│ └── example-command.md # Slash command definition
|
||||
├── agents/
|
||||
│ └── example-agent.md # Agent definition
|
||||
└── skills/
|
||||
└── example-skill/
|
||||
└── SKILL.md # Skill definition
|
||||
```
|
||||
|
||||
## Extension Options
|
||||
|
||||
### Commands (`commands/`)
|
||||
|
||||
Slash commands are user-invoked via `/command-name`. Define them as markdown files with frontmatter:
|
||||
|
||||
```yaml
|
||||
---
|
||||
description: Short description for /help
|
||||
argument-hint: <arg1> [optional-arg]
|
||||
allowed-tools: [Read, Glob, Grep]
|
||||
---
|
||||
```
|
||||
|
||||
### Agents (`agents/`)
|
||||
|
||||
Agents are spawned by Claude via the Task tool. Define them as markdown files:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: agent-name
|
||||
description: When to use this agent
|
||||
tools: Glob, Grep, Read, Write
|
||||
model: sonnet
|
||||
color: blue
|
||||
---
|
||||
```
|
||||
|
||||
### Skills (`skills/`)
|
||||
|
||||
Skills are model-invoked capabilities. Create a `SKILL.md` in a subdirectory:
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: skill-name
|
||||
description: Trigger conditions for this skill
|
||||
version: 1.0.0
|
||||
---
|
||||
```
|
||||
|
||||
### MCP Servers (`.mcp.json`)
|
||||
|
||||
Configure external tool integration via Model Context Protocol:
|
||||
|
||||
```json
|
||||
{
|
||||
"server-name": {
|
||||
"type": "http",
|
||||
"url": "https://mcp.example.com/api"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
Copy or symlink this plugin directory to your Claude Code plugins location.
|
||||
|
||||
## Usage
|
||||
|
||||
- `/example-command [args]` - Run the example slash command
|
||||
- The example agent is available for Claude to spawn when relevant
|
||||
- The example skill activates based on task context
|
||||
57
plugins/example-plugin/agents/example-agent.md
Normal file
57
plugins/example-plugin/agents/example-agent.md
Normal file
@@ -0,0 +1,57 @@
|
||||
---
|
||||
name: example-agent
|
||||
description: An example agent that demonstrates agent definition structure and frontmatter options. Use this agent when the user asks to perform example tasks or needs a template reference.
|
||||
tools: Glob, Grep, Read, Write, Edit, Bash, WebFetch, WebSearch, TodoWrite
|
||||
model: sonnet
|
||||
color: blue
|
||||
---
|
||||
|
||||
You are an example agent that demonstrates the agent definition format for Claude Code plugins.
|
||||
|
||||
## Agent Purpose
|
||||
|
||||
This agent serves as a template showing:
|
||||
- Required and optional frontmatter fields
|
||||
- Recommended prompt structure
|
||||
- How to define agent capabilities and behavior
|
||||
|
||||
## Frontmatter Options Reference
|
||||
|
||||
Agents support these frontmatter fields:
|
||||
|
||||
- **name** (required): Agent identifier used in Task tool
|
||||
- **description** (required): When to use this agent - Claude reads this to decide which agent to spawn
|
||||
- **tools** (required): Comma-separated list of allowed tools
|
||||
- **model** (optional): "haiku", "sonnet", or "opus" (defaults to parent model)
|
||||
- **color** (optional): Terminal color for agent output (red, green, blue, yellow, magenta, cyan)
|
||||
|
||||
## Available Tools
|
||||
|
||||
Common tools to include:
|
||||
- **Glob**: Find files by pattern
|
||||
- **Grep**: Search file contents
|
||||
- **Read**: Read file contents
|
||||
- **Write**: Create new files
|
||||
- **Edit**: Modify existing files
|
||||
- **Bash**: Execute shell commands
|
||||
- **WebFetch**: Fetch web content
|
||||
- **WebSearch**: Search the web
|
||||
- **TodoWrite**: Track task progress
|
||||
- **NotebookRead**: Read Jupyter notebooks
|
||||
- **LSP**: Language server operations
|
||||
|
||||
## Agent Behavior
|
||||
|
||||
When spawned, this agent should:
|
||||
|
||||
1. Understand the task from the prompt
|
||||
2. Use available tools systematically
|
||||
3. Report findings or complete the requested work
|
||||
4. Return a clear summary to the parent conversation
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Write clear, actionable descriptions so Claude knows when to spawn this agent
|
||||
- Only include tools the agent actually needs
|
||||
- Use appropriate model based on task complexity
|
||||
- Structure prompts with clear sections and instructions
|
||||
37
plugins/example-plugin/commands/example-command.md
Normal file
37
plugins/example-plugin/commands/example-command.md
Normal file
@@ -0,0 +1,37 @@
|
||||
---
|
||||
description: An example slash command that demonstrates command frontmatter options
|
||||
argument-hint: <required-arg> [optional-arg]
|
||||
allowed-tools: [Read, Glob, Grep, Bash]
|
||||
---
|
||||
|
||||
# Example Command
|
||||
|
||||
This command demonstrates slash command structure and frontmatter options.
|
||||
|
||||
## Arguments
|
||||
|
||||
The user invoked this command with: $ARGUMENTS
|
||||
|
||||
## Instructions
|
||||
|
||||
When this command is invoked:
|
||||
|
||||
1. Parse the arguments provided by the user
|
||||
2. Perform the requested action using allowed tools
|
||||
3. Report results back to the user
|
||||
|
||||
## Frontmatter Options Reference
|
||||
|
||||
Commands support these frontmatter fields:
|
||||
|
||||
- **description**: Short description shown in /help
|
||||
- **argument-hint**: Hints for command arguments shown to user
|
||||
- **allowed-tools**: Pre-approved tools for this command (reduces permission prompts)
|
||||
- **model**: Override the model (e.g., "haiku", "sonnet", "opus")
|
||||
|
||||
## Example Usage
|
||||
|
||||
```
|
||||
/example-command my-argument
|
||||
/example-command arg1 arg2
|
||||
```
|
||||
84
plugins/example-plugin/skills/example-skill/SKILL.md
Normal file
84
plugins/example-plugin/skills/example-skill/SKILL.md
Normal file
@@ -0,0 +1,84 @@
|
||||
---
|
||||
name: example-skill
|
||||
description: This skill should be used when the user asks to "demonstrate skills", "show skill format", "create a skill template", or discusses skill development patterns. Provides a reference template for creating Claude Code plugin skills.
|
||||
version: 1.0.0
|
||||
---
|
||||
|
||||
# Example Skill
|
||||
|
||||
This skill demonstrates the structure and format for Claude Code plugin skills.
|
||||
|
||||
## Overview
|
||||
|
||||
Skills are model-invoked capabilities that Claude autonomously uses based on task context. Unlike commands (user-invoked) or agents (spawned by Claude), skills provide contextual guidance that Claude incorporates into its responses.
|
||||
|
||||
## When This Skill Applies
|
||||
|
||||
This skill activates when the user's request involves:
|
||||
- Creating or understanding plugin skills
|
||||
- Skill template or reference needs
|
||||
- Skill development patterns
|
||||
|
||||
## Skill Structure
|
||||
|
||||
### Required Files
|
||||
|
||||
```
|
||||
skills/
|
||||
└── skill-name/
|
||||
└── SKILL.md # Main skill definition (required)
|
||||
```
|
||||
|
||||
### Optional Supporting Files
|
||||
|
||||
```
|
||||
skills/
|
||||
└── skill-name/
|
||||
├── SKILL.md # Main skill definition
|
||||
├── README.md # Additional documentation
|
||||
├── references/ # Reference materials
|
||||
│ └── patterns.md
|
||||
├── examples/ # Example files
|
||||
│ └── sample.md
|
||||
└── scripts/ # Helper scripts
|
||||
└── helper.sh
|
||||
```
|
||||
|
||||
## Frontmatter Options
|
||||
|
||||
Skills support these frontmatter fields:
|
||||
|
||||
- **name** (required): Skill identifier
|
||||
- **description** (required): Trigger conditions - describe when Claude should use this skill
|
||||
- **version** (optional): Semantic version number
|
||||
- **license** (optional): License information or reference
|
||||
|
||||
## Writing Effective Descriptions
|
||||
|
||||
The description field is crucial - it tells Claude when to invoke the skill.
|
||||
|
||||
**Good description patterns:**
|
||||
```yaml
|
||||
description: This skill should be used when the user asks to "specific phrase", "another phrase", mentions "keyword", or discusses topic-area.
|
||||
```
|
||||
|
||||
**Include:**
|
||||
- Specific trigger phrases users might say
|
||||
- Keywords that indicate relevance
|
||||
- Topic areas the skill covers
|
||||
|
||||
## Skill Content Guidelines
|
||||
|
||||
1. **Clear purpose**: State what the skill helps with
|
||||
2. **When to use**: Define activation conditions
|
||||
3. **Structured guidance**: Organize information logically
|
||||
4. **Actionable instructions**: Provide concrete steps
|
||||
5. **Examples**: Include practical examples when helpful
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Keep skills focused on a single domain
|
||||
- Write descriptions that clearly indicate when to activate
|
||||
- Include reference materials in subdirectories for complex skills
|
||||
- Test that the skill activates for expected queries
|
||||
- Avoid overlap with other skills' trigger conditions
|
||||
@@ -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 @@
|
||||
#!/usr/bin/env 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/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"
|
||||
}
|
||||
}
|
||||
412
plugins/feature-dev/README.md
Normal file
412
plugins/feature-dev/README.md
Normal file
@@ -0,0 +1,412 @@
|
||||
# Feature Development Plugin
|
||||
|
||||
A comprehensive, structured workflow for feature development with specialized agents for codebase exploration, architecture design, and quality review.
|
||||
|
||||
## Overview
|
||||
|
||||
The Feature Development Plugin provides a systematic 7-phase approach to building new features. Instead of jumping straight into code, it guides you through understanding the codebase, asking clarifying questions, designing architecture, and ensuring quality—resulting in better-designed features that integrate seamlessly with your existing code.
|
||||
|
||||
## Philosophy
|
||||
|
||||
Building features requires more than just writing code. You need to:
|
||||
- **Understand the codebase** before making changes
|
||||
- **Ask questions** to clarify ambiguous requirements
|
||||
- **Design thoughtfully** before implementing
|
||||
- **Review for quality** after building
|
||||
|
||||
This plugin embeds these practices into a structured workflow that runs automatically when you use the `/feature-dev` command.
|
||||
|
||||
## Command: `/feature-dev`
|
||||
|
||||
Launches a guided feature development workflow with 7 distinct phases.
|
||||
|
||||
**Usage:**
|
||||
```bash
|
||||
/feature-dev Add user authentication with OAuth
|
||||
```
|
||||
|
||||
Or simply:
|
||||
```bash
|
||||
/feature-dev
|
||||
```
|
||||
|
||||
The command will guide you through the entire process interactively.
|
||||
|
||||
## The 7-Phase Workflow
|
||||
|
||||
### Phase 1: Discovery
|
||||
|
||||
**Goal**: Understand what needs to be built
|
||||
|
||||
**What happens:**
|
||||
- Clarifies the feature request if it's unclear
|
||||
- Asks what problem you're solving
|
||||
- Identifies constraints and requirements
|
||||
- Summarizes understanding and confirms with you
|
||||
|
||||
**Example:**
|
||||
```
|
||||
You: /feature-dev Add caching
|
||||
Claude: Let me understand what you need...
|
||||
- What should be cached? (API responses, computed values, etc.)
|
||||
- What are your performance requirements?
|
||||
- Do you have a preferred caching solution?
|
||||
```
|
||||
|
||||
### Phase 2: Codebase Exploration
|
||||
|
||||
**Goal**: Understand relevant existing code and patterns
|
||||
|
||||
**What happens:**
|
||||
- Launches 2-3 `code-explorer` agents in parallel
|
||||
- Each agent explores different aspects (similar features, architecture, UI patterns)
|
||||
- Agents return comprehensive analyses with key files to read
|
||||
- Claude reads all identified files to build deep understanding
|
||||
- Presents comprehensive summary of findings
|
||||
|
||||
**Agents launched:**
|
||||
- "Find features similar to [feature] and trace implementation"
|
||||
- "Map the architecture and abstractions for [area]"
|
||||
- "Analyze current implementation of [related feature]"
|
||||
|
||||
**Example output:**
|
||||
```
|
||||
Found similar features:
|
||||
- User authentication (src/auth/): Uses JWT tokens, middleware pattern
|
||||
- Session management (src/session/): Redis-backed, 24hr expiry
|
||||
- API security (src/api/middleware/): Rate limiting, CORS
|
||||
|
||||
Key files to understand:
|
||||
- src/auth/AuthService.ts:45 - Core authentication logic
|
||||
- src/middleware/authMiddleware.ts:12 - Request authentication
|
||||
- src/config/security.ts:8 - Security configuration
|
||||
```
|
||||
|
||||
### Phase 3: Clarifying Questions
|
||||
|
||||
**Goal**: Fill in gaps and resolve all ambiguities
|
||||
|
||||
**What happens:**
|
||||
- Reviews codebase findings and feature request
|
||||
- Identifies underspecified aspects:
|
||||
- Edge cases
|
||||
- Error handling
|
||||
- Integration points
|
||||
- Backward compatibility
|
||||
- Performance needs
|
||||
- Presents all questions in an organized list
|
||||
- **Waits for your answers before proceeding**
|
||||
|
||||
**Example:**
|
||||
```
|
||||
Before designing the architecture, I need to clarify:
|
||||
|
||||
1. OAuth provider: Which OAuth providers? (Google, GitHub, custom?)
|
||||
2. User data: Store OAuth tokens or just user profile?
|
||||
3. Existing auth: Replace current auth or add alongside?
|
||||
4. Sessions: Integrate with existing session management?
|
||||
5. Error handling: How to handle OAuth failures?
|
||||
```
|
||||
|
||||
**Critical**: This phase ensures nothing is ambiguous before design begins.
|
||||
|
||||
### Phase 4: Architecture Design
|
||||
|
||||
**Goal**: Design multiple implementation approaches
|
||||
|
||||
**What happens:**
|
||||
- Launches 2-3 `code-architect` agents with different focuses:
|
||||
- **Minimal changes**: Smallest change, maximum reuse
|
||||
- **Clean architecture**: Maintainability, elegant abstractions
|
||||
- **Pragmatic balance**: Speed + quality
|
||||
- Reviews all approaches
|
||||
- Forms opinion on which fits best for this task
|
||||
- Presents comparison with trade-offs and recommendation
|
||||
- **Asks which approach you prefer**
|
||||
|
||||
**Example output:**
|
||||
```
|
||||
I've designed 3 approaches:
|
||||
|
||||
Approach 1: Minimal Changes
|
||||
- Extend existing AuthService with OAuth methods
|
||||
- Add new OAuth routes to existing auth router
|
||||
- Minimal refactoring required
|
||||
Pros: Fast, low risk
|
||||
Cons: Couples OAuth to existing auth, harder to test
|
||||
|
||||
Approach 2: Clean Architecture
|
||||
- New OAuthService with dedicated interface
|
||||
- Separate OAuth router and middleware
|
||||
- Refactor AuthService to use common interface
|
||||
Pros: Clean separation, testable, maintainable
|
||||
Cons: More files, more refactoring
|
||||
|
||||
Approach 3: Pragmatic Balance
|
||||
- New OAuthProvider abstraction
|
||||
- Integrate into existing AuthService
|
||||
- Minimal refactoring, good boundaries
|
||||
Pros: Balanced complexity and cleanliness
|
||||
Cons: Some coupling remains
|
||||
|
||||
Recommendation: Approach 3 - gives you clean boundaries without
|
||||
excessive refactoring, and fits your existing architecture well.
|
||||
|
||||
Which approach would you like to use?
|
||||
```
|
||||
|
||||
### Phase 5: Implementation
|
||||
|
||||
**Goal**: Build the feature
|
||||
|
||||
**What happens:**
|
||||
- **Waits for explicit approval** before starting
|
||||
- Reads all relevant files identified in previous phases
|
||||
- Implements following chosen architecture
|
||||
- Follows codebase conventions strictly
|
||||
- Writes clean, well-documented code
|
||||
- Updates todos as progress is made
|
||||
|
||||
**Notes:**
|
||||
- Implementation only starts after you approve
|
||||
- Follows patterns discovered in Phase 2
|
||||
- Uses architecture designed in Phase 4
|
||||
- Continuously tracks progress
|
||||
|
||||
### Phase 6: Quality Review
|
||||
|
||||
**Goal**: Ensure code is simple, DRY, elegant, and functionally correct
|
||||
|
||||
**What happens:**
|
||||
- Launches 3 `code-reviewer` agents in parallel with different focuses:
|
||||
- **Simplicity/DRY/Elegance**: Code quality and maintainability
|
||||
- **Bugs/Correctness**: Functional correctness and logic errors
|
||||
- **Conventions/Abstractions**: Project standards and patterns
|
||||
- Consolidates findings
|
||||
- Identifies highest severity issues
|
||||
- **Presents findings and asks what you want to do**:
|
||||
- Fix now
|
||||
- Fix later
|
||||
- Proceed as-is
|
||||
- Addresses issues based on your decision
|
||||
|
||||
**Example output:**
|
||||
```
|
||||
Code Review Results:
|
||||
|
||||
High Priority Issues:
|
||||
1. Missing error handling in OAuth callback (src/auth/oauth.ts:67)
|
||||
2. Memory leak: OAuth state not cleaned up (src/auth/oauth.ts:89)
|
||||
|
||||
Medium Priority:
|
||||
1. Could simplify token refresh logic (src/auth/oauth.ts:120)
|
||||
2. Consider extracting OAuth config validation
|
||||
|
||||
All tests pass. Code follows project conventions.
|
||||
|
||||
What would you like to do?
|
||||
```
|
||||
|
||||
### Phase 7: Summary
|
||||
|
||||
**Goal**: Document what was accomplished
|
||||
|
||||
**What happens:**
|
||||
- Marks all todos complete
|
||||
- Summarizes:
|
||||
- What was built
|
||||
- Key decisions made
|
||||
- Files modified
|
||||
- Suggested next steps
|
||||
|
||||
**Example:**
|
||||
```
|
||||
Feature Complete: OAuth Authentication
|
||||
|
||||
What was built:
|
||||
- OAuth provider abstraction supporting Google and GitHub
|
||||
- OAuth routes and middleware integrated with existing auth
|
||||
- Token refresh and session integration
|
||||
- Error handling for all OAuth flows
|
||||
|
||||
Key decisions:
|
||||
- Used pragmatic approach with OAuthProvider abstraction
|
||||
- Integrated with existing session management
|
||||
- Added OAuth state to prevent CSRF
|
||||
|
||||
Files modified:
|
||||
- src/auth/OAuthProvider.ts (new)
|
||||
- src/auth/AuthService.ts
|
||||
- src/routes/auth.ts
|
||||
- src/middleware/authMiddleware.ts
|
||||
|
||||
Suggested next steps:
|
||||
- Add tests for OAuth flows
|
||||
- Add more OAuth providers (Microsoft, Apple)
|
||||
- Update documentation
|
||||
```
|
||||
|
||||
## Agents
|
||||
|
||||
### `code-explorer`
|
||||
|
||||
**Purpose**: Deeply analyzes existing codebase features by tracing execution paths
|
||||
|
||||
**Focus areas:**
|
||||
- Entry points and call chains
|
||||
- Data flow and transformations
|
||||
- Architecture layers and patterns
|
||||
- Dependencies and integrations
|
||||
- Implementation details
|
||||
|
||||
**When triggered:**
|
||||
- Automatically in Phase 2
|
||||
- Can be invoked manually when exploring code
|
||||
|
||||
**Output:**
|
||||
- Entry points with file:line references
|
||||
- Step-by-step execution flow
|
||||
- Key components and responsibilities
|
||||
- Architecture insights
|
||||
- List of essential files to read
|
||||
|
||||
### `code-architect`
|
||||
|
||||
**Purpose**: Designs feature architectures and implementation blueprints
|
||||
|
||||
**Focus areas:**
|
||||
- Codebase pattern analysis
|
||||
- Architecture decisions
|
||||
- Component design
|
||||
- Implementation roadmap
|
||||
- Data flow and build sequence
|
||||
|
||||
**When triggered:**
|
||||
- Automatically in Phase 4
|
||||
- Can be invoked manually for architecture design
|
||||
|
||||
**Output:**
|
||||
- Patterns and conventions found
|
||||
- Architecture decision with rationale
|
||||
- Complete component design
|
||||
- Implementation map with specific files
|
||||
- Build sequence with phases
|
||||
|
||||
### `code-reviewer`
|
||||
|
||||
**Purpose**: Reviews code for bugs, quality issues, and project conventions
|
||||
|
||||
**Focus areas:**
|
||||
- Project guideline compliance (CLAUDE.md)
|
||||
- Bug detection
|
||||
- Code quality issues
|
||||
- Confidence-based filtering (only reports high-confidence issues ≥80)
|
||||
|
||||
**When triggered:**
|
||||
- Automatically in Phase 6
|
||||
- Can be invoked manually after writing code
|
||||
|
||||
**Output:**
|
||||
- Critical issues (confidence 75-100)
|
||||
- Important issues (confidence 50-74)
|
||||
- Specific fixes with file:line references
|
||||
- Project guideline references
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
### Full workflow (recommended for new features):
|
||||
```bash
|
||||
/feature-dev Add rate limiting to API endpoints
|
||||
```
|
||||
|
||||
Let the workflow guide you through all 7 phases.
|
||||
|
||||
### Manual agent invocation:
|
||||
|
||||
**Explore a feature:**
|
||||
```
|
||||
"Launch code-explorer to trace how authentication works"
|
||||
```
|
||||
|
||||
**Design architecture:**
|
||||
```
|
||||
"Launch code-architect to design the caching layer"
|
||||
```
|
||||
|
||||
**Review code:**
|
||||
```
|
||||
"Launch code-reviewer to check my recent changes"
|
||||
```
|
||||
|
||||
## Best Practices
|
||||
|
||||
1. **Use the full workflow for complex features**: The 7 phases ensure thorough planning
|
||||
2. **Answer clarifying questions thoughtfully**: Phase 3 prevents future confusion
|
||||
3. **Choose architecture deliberately**: Phase 4 gives you options for a reason
|
||||
4. **Don't skip code review**: Phase 6 catches issues before they reach production
|
||||
5. **Read the suggested files**: Phase 2 identifies key files—read them to understand context
|
||||
|
||||
## When to Use This Plugin
|
||||
|
||||
**Use for:**
|
||||
- New features that touch multiple files
|
||||
- Features requiring architectural decisions
|
||||
- Complex integrations with existing code
|
||||
- Features where requirements are somewhat unclear
|
||||
|
||||
**Don't use for:**
|
||||
- Single-line bug fixes
|
||||
- Trivial changes
|
||||
- Well-defined, simple tasks
|
||||
- Urgent hotfixes
|
||||
|
||||
## Requirements
|
||||
|
||||
- Claude Code installed
|
||||
- Git repository (for code review)
|
||||
- Project with existing codebase (workflow assumes existing code to learn from)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Agents take too long
|
||||
|
||||
**Issue**: Code exploration or architecture agents are slow
|
||||
|
||||
**Solution**:
|
||||
- This is normal for large codebases
|
||||
- Agents run in parallel when possible
|
||||
- The thoroughness pays off in better understanding
|
||||
|
||||
### Too many clarifying questions
|
||||
|
||||
**Issue**: Phase 3 asks too many questions
|
||||
|
||||
**Solution**:
|
||||
- Be more specific in your initial feature request
|
||||
- Provide context about constraints upfront
|
||||
- Say "whatever you think is best" if truly no preference
|
||||
|
||||
### Architecture options overwhelming
|
||||
|
||||
**Issue**: Too many architecture options in Phase 4
|
||||
|
||||
**Solution**:
|
||||
- Trust the recommendation—it's based on codebase analysis
|
||||
- If still unsure, ask for more explanation
|
||||
- Pick the pragmatic option when in doubt
|
||||
|
||||
## Tips
|
||||
|
||||
- **Be specific in your feature request**: More detail = fewer clarifying questions
|
||||
- **Trust the process**: Each phase builds on the previous one
|
||||
- **Review agent outputs**: Agents provide valuable insights about your codebase
|
||||
- **Don't skip phases**: Each phase serves a purpose
|
||||
- **Use for learning**: The exploration phase teaches you about your own codebase
|
||||
|
||||
## Author
|
||||
|
||||
Sid Bidasaria (sbidasaria@anthropic.com)
|
||||
|
||||
## Version
|
||||
|
||||
1.0.0
|
||||
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/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/hookify/.claude-plugin/plugin.json
Normal file
9
plugins/hookify/.claude-plugin/plugin.json
Normal file
@@ -0,0 +1,9 @@
|
||||
{
|
||||
"name": "hookify",
|
||||
"version": "0.1.0",
|
||||
"description": "Easily create hooks to prevent unwanted behaviors by analyzing conversation patterns",
|
||||
"author": {
|
||||
"name": "Daisy Hollman",
|
||||
"email": "daisy@anthropic.com"
|
||||
}
|
||||
}
|
||||
30
plugins/hookify/.gitignore
vendored
Normal file
30
plugins/hookify/.gitignore
vendored
Normal file
@@ -0,0 +1,30 @@
|
||||
# Python
|
||||
__pycache__/
|
||||
*.py[cod]
|
||||
*$py.class
|
||||
*.so
|
||||
.Python
|
||||
|
||||
# Virtual environments
|
||||
venv/
|
||||
env/
|
||||
ENV/
|
||||
|
||||
# IDE
|
||||
.vscode/
|
||||
.idea/
|
||||
*.swp
|
||||
*.swo
|
||||
|
||||
# OS
|
||||
.DS_Store
|
||||
Thumbs.db
|
||||
|
||||
# Testing
|
||||
.pytest_cache/
|
||||
.coverage
|
||||
htmlcov/
|
||||
|
||||
# Local configuration (should not be committed)
|
||||
.claude/*.local.md
|
||||
.claude/*.local.json
|
||||
340
plugins/hookify/README.md
Normal file
340
plugins/hookify/README.md
Normal file
@@ -0,0 +1,340 @@
|
||||
# Hookify Plugin
|
||||
|
||||
Easily create custom hooks to prevent unwanted behaviors by analyzing conversation patterns or from explicit instructions.
|
||||
|
||||
## Overview
|
||||
|
||||
The hookify plugin makes it simple to create hooks without editing complex `hooks.json` files. Instead, you create lightweight markdown configuration files that define patterns to watch for and messages to show when those patterns match.
|
||||
|
||||
**Key features:**
|
||||
- 🎯 Analyze conversations to find unwanted behaviors automatically
|
||||
- 📝 Simple markdown configuration files with YAML frontmatter
|
||||
- 🔍 Regex pattern matching for powerful rules
|
||||
- 🚀 No coding required - just describe the behavior
|
||||
- 🔄 Easy enable/disable without restarting
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Create Your First Rule
|
||||
|
||||
```bash
|
||||
/hookify Warn me when I use rm -rf commands
|
||||
```
|
||||
|
||||
This analyzes your request and creates `.claude/hookify.warn-rm.local.md`.
|
||||
|
||||
### 2. Test It Immediately
|
||||
|
||||
**No restart needed!** Rules take effect on the very next tool use.
|
||||
|
||||
Ask Claude to run a command that should trigger the rule:
|
||||
```
|
||||
Run rm -rf /tmp/test
|
||||
```
|
||||
|
||||
You should see the warning message immediately!
|
||||
|
||||
## Usage
|
||||
|
||||
### Main Command: /hookify
|
||||
|
||||
**With arguments:**
|
||||
```
|
||||
/hookify Don't use console.log in TypeScript files
|
||||
```
|
||||
Creates a rule from your explicit instructions.
|
||||
|
||||
**Without arguments:**
|
||||
```
|
||||
/hookify
|
||||
```
|
||||
Analyzes recent conversation to find behaviors you've corrected or been frustrated by.
|
||||
|
||||
### Helper Commands
|
||||
|
||||
**List all rules:**
|
||||
```
|
||||
/hookify:list
|
||||
```
|
||||
|
||||
**Configure rules interactively:**
|
||||
```
|
||||
/hookify:configure
|
||||
```
|
||||
Enable/disable existing rules through an interactive interface.
|
||||
|
||||
**Get help:**
|
||||
```
|
||||
/hookify:help
|
||||
```
|
||||
|
||||
## Rule Configuration Format
|
||||
|
||||
### Simple Rule (Single Pattern)
|
||||
|
||||
`.claude/hookify.dangerous-rm.local.md`:
|
||||
```markdown
|
||||
---
|
||||
name: block-dangerous-rm
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: rm\s+-rf
|
||||
action: block
|
||||
---
|
||||
|
||||
⚠️ **Dangerous rm command detected!**
|
||||
|
||||
This command could delete important files. Please:
|
||||
- Verify the path is correct
|
||||
- Consider using a safer approach
|
||||
- Make sure you have backups
|
||||
```
|
||||
|
||||
**Action field:**
|
||||
- `warn`: Shows warning but allows operation (default)
|
||||
- `block`: Prevents operation from executing (PreToolUse) or stops session (Stop events)
|
||||
|
||||
### Advanced Rule (Multiple Conditions)
|
||||
|
||||
`.claude/hookify.sensitive-files.local.md`:
|
||||
```markdown
|
||||
---
|
||||
name: warn-sensitive-files
|
||||
enabled: true
|
||||
event: file
|
||||
action: warn
|
||||
conditions:
|
||||
- field: file_path
|
||||
operator: regex_match
|
||||
pattern: \.env$|credentials|secrets
|
||||
- field: new_text
|
||||
operator: contains
|
||||
pattern: KEY
|
||||
---
|
||||
|
||||
🔐 **Sensitive file edit detected!**
|
||||
|
||||
Ensure credentials are not hardcoded and file is in .gitignore.
|
||||
```
|
||||
|
||||
**All conditions must match** for the rule to trigger.
|
||||
|
||||
## Event Types
|
||||
|
||||
- **`bash`**: Triggers on Bash tool commands
|
||||
- **`file`**: Triggers on Edit, Write, MultiEdit tools
|
||||
- **`stop`**: Triggers when Claude wants to stop (for completion checks)
|
||||
- **`prompt`**: Triggers on user prompt submission
|
||||
- **`all`**: Triggers on all events
|
||||
|
||||
## Pattern Syntax
|
||||
|
||||
Use Python regex syntax:
|
||||
|
||||
| Pattern | Matches | Example |
|
||||
|---------|---------|---------|
|
||||
| `rm\s+-rf` | rm -rf | rm -rf /tmp |
|
||||
| `console\.log\(` | console.log( | console.log("test") |
|
||||
| `(eval\|exec)\(` | eval( or exec( | eval("code") |
|
||||
| `\.env$` | files ending in .env | .env, .env.local |
|
||||
| `chmod\s+777` | chmod 777 | chmod 777 file.txt |
|
||||
|
||||
**Tips:**
|
||||
- Use `\s` for whitespace
|
||||
- Escape special chars: `\.` for literal dot
|
||||
- Use `|` for OR: `(foo|bar)`
|
||||
- Use `.*` to match anything
|
||||
- Set `action: block` for dangerous operations
|
||||
- Set `action: warn` (or omit) for informational warnings
|
||||
|
||||
## Examples
|
||||
|
||||
### Example 1: Block Dangerous Commands
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: block-destructive-ops
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: rm\s+-rf|dd\s+if=|mkfs|format
|
||||
action: block
|
||||
---
|
||||
|
||||
🛑 **Destructive operation detected!**
|
||||
|
||||
This command can cause data loss. Operation blocked for safety.
|
||||
Please verify the exact path and use a safer approach.
|
||||
```
|
||||
|
||||
**This rule blocks the operation** - Claude will not be allowed to execute these commands.
|
||||
|
||||
### Example 2: Warn About Debug Code
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: warn-debug-code
|
||||
enabled: true
|
||||
event: file
|
||||
pattern: console\.log\(|debugger;|print\(
|
||||
action: warn
|
||||
---
|
||||
|
||||
🐛 **Debug code detected**
|
||||
|
||||
Remember to remove debugging statements before committing.
|
||||
```
|
||||
|
||||
**This rule warns but allows** - Claude sees the message but can still proceed.
|
||||
|
||||
### Example 3: Require Tests Before Stopping
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: require-tests-run
|
||||
enabled: false
|
||||
event: stop
|
||||
action: block
|
||||
conditions:
|
||||
- field: transcript
|
||||
operator: not_contains
|
||||
pattern: npm test|pytest|cargo test
|
||||
---
|
||||
|
||||
**Tests not detected in transcript!**
|
||||
|
||||
Before stopping, please run tests to verify your changes work correctly.
|
||||
```
|
||||
|
||||
**This blocks Claude from stopping** if no test commands appear in the session transcript. Enable only when you want strict enforcement.
|
||||
|
||||
## Advanced Usage
|
||||
|
||||
### Multiple Conditions
|
||||
|
||||
Check multiple fields simultaneously:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: api-key-in-typescript
|
||||
enabled: true
|
||||
event: file
|
||||
conditions:
|
||||
- field: file_path
|
||||
operator: regex_match
|
||||
pattern: \.tsx?$
|
||||
- field: new_text
|
||||
operator: regex_match
|
||||
pattern: (API_KEY|SECRET|TOKEN)\s*=\s*["']
|
||||
---
|
||||
|
||||
🔐 **Hardcoded credential in TypeScript!**
|
||||
|
||||
Use environment variables instead of hardcoded values.
|
||||
```
|
||||
|
||||
### Operators Reference
|
||||
|
||||
- `regex_match`: Pattern must match (most common)
|
||||
- `contains`: String must contain pattern
|
||||
- `equals`: Exact string match
|
||||
- `not_contains`: String must NOT contain pattern
|
||||
- `starts_with`: String starts with pattern
|
||||
- `ends_with`: String ends with pattern
|
||||
|
||||
### Field Reference
|
||||
|
||||
**For bash events:**
|
||||
- `command`: The bash command string
|
||||
|
||||
**For file events:**
|
||||
- `file_path`: Path to file being edited
|
||||
- `new_text`: New content being added (Edit, Write)
|
||||
- `old_text`: Old content being replaced (Edit only)
|
||||
- `content`: File content (Write only)
|
||||
|
||||
**For prompt events:**
|
||||
- `user_prompt`: The user's submitted prompt text
|
||||
|
||||
**For stop events:**
|
||||
- Use general matching on session state
|
||||
|
||||
## Management
|
||||
|
||||
### Enable/Disable Rules
|
||||
|
||||
**Temporarily disable:**
|
||||
Edit the `.local.md` file and set `enabled: false`
|
||||
|
||||
**Re-enable:**
|
||||
Set `enabled: true`
|
||||
|
||||
**Or use interactive tool:**
|
||||
```
|
||||
/hookify:configure
|
||||
```
|
||||
|
||||
### Delete Rules
|
||||
|
||||
Simply delete the `.local.md` file:
|
||||
```bash
|
||||
rm .claude/hookify.my-rule.local.md
|
||||
```
|
||||
|
||||
### View All Rules
|
||||
|
||||
```
|
||||
/hookify:list
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
This plugin is part of the Claude Code Marketplace. It should be auto-discovered when the marketplace is installed.
|
||||
|
||||
**Manual testing:**
|
||||
```bash
|
||||
cc --plugin-dir /path/to/hookify
|
||||
```
|
||||
|
||||
## Requirements
|
||||
|
||||
- Python 3.7+
|
||||
- No external dependencies (uses stdlib only)
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Rule not triggering:**
|
||||
1. Check rule file exists in `.claude/` directory (in project root, not plugin directory)
|
||||
2. Verify `enabled: true` in frontmatter
|
||||
3. Test regex pattern separately
|
||||
4. Rules should work immediately - no restart needed
|
||||
5. Try `/hookify:list` to see if rule is loaded
|
||||
|
||||
**Import errors:**
|
||||
- Ensure Python 3 is available: `python3 --version`
|
||||
- Check hookify plugin is installed
|
||||
|
||||
**Pattern not matching:**
|
||||
- Test regex: `python3 -c "import re; print(re.search(r'pattern', 'text'))"`
|
||||
- Use unquoted patterns in YAML to avoid escaping issues
|
||||
- Start simple, then add complexity
|
||||
|
||||
**Hook seems slow:**
|
||||
- Keep patterns simple (avoid complex regex)
|
||||
- Use specific event types (bash, file) instead of "all"
|
||||
- Limit number of active rules
|
||||
|
||||
## Contributing
|
||||
|
||||
Found a useful rule pattern? Consider sharing example files via PR!
|
||||
|
||||
## Future Enhancements
|
||||
|
||||
- Severity levels (error/warning/info distinctions)
|
||||
- Rule templates library
|
||||
- Interactive pattern builder
|
||||
- Hook testing utilities
|
||||
- JSON format support (in addition to markdown)
|
||||
|
||||
## License
|
||||
|
||||
MIT License
|
||||
176
plugins/hookify/agents/conversation-analyzer.md
Normal file
176
plugins/hookify/agents/conversation-analyzer.md
Normal file
@@ -0,0 +1,176 @@
|
||||
---
|
||||
name: conversation-analyzer
|
||||
description: Use this agent when analyzing conversation transcripts to find behaviors worth preventing with hooks. Examples: <example>Context: User is running /hookify command without arguments\nuser: "/hookify"\nassistant: "I'll analyze the conversation to find behaviors you want to prevent"\n<commentary>The /hookify command without arguments triggers conversation analysis to find unwanted behaviors.</commentary></example><example>Context: User wants to create hooks from recent frustrations\nuser: "Can you look back at this conversation and help me create hooks for the mistakes you made?"\nassistant: "I'll use the conversation-analyzer agent to identify the issues and suggest hooks."\n<commentary>User explicitly asks to analyze conversation for mistakes that should be prevented.</commentary></example>
|
||||
model: inherit
|
||||
color: yellow
|
||||
tools: ["Read", "Grep"]
|
||||
---
|
||||
|
||||
You are a conversation analysis specialist that identifies problematic behaviors in Claude Code sessions that could be prevented with hooks.
|
||||
|
||||
**Your Core Responsibilities:**
|
||||
1. Read and analyze user messages to find frustration signals
|
||||
2. Identify specific tool usage patterns that caused issues
|
||||
3. Extract actionable patterns that can be matched with regex
|
||||
4. Categorize issues by severity and type
|
||||
5. Provide structured findings for hook rule generation
|
||||
|
||||
**Analysis Process:**
|
||||
|
||||
### 1. Search for User Messages Indicating Issues
|
||||
|
||||
Read through user messages in reverse chronological order (most recent first). Look for:
|
||||
|
||||
**Explicit correction requests:**
|
||||
- "Don't use X"
|
||||
- "Stop doing Y"
|
||||
- "Please don't Z"
|
||||
- "Avoid..."
|
||||
- "Never..."
|
||||
|
||||
**Frustrated reactions:**
|
||||
- "Why did you do X?"
|
||||
- "I didn't ask for that"
|
||||
- "That's not what I meant"
|
||||
- "That was wrong"
|
||||
|
||||
**Corrections and reversions:**
|
||||
- User reverting changes Claude made
|
||||
- User fixing issues Claude created
|
||||
- User providing step-by-step corrections
|
||||
|
||||
**Repeated issues:**
|
||||
- Same type of mistake multiple times
|
||||
- User having to remind multiple times
|
||||
- Pattern of similar problems
|
||||
|
||||
### 2. Identify Tool Usage Patterns
|
||||
|
||||
For each issue, determine:
|
||||
- **Which tool**: Bash, Edit, Write, MultiEdit
|
||||
- **What action**: Specific command or code pattern
|
||||
- **When it happened**: During what task/phase
|
||||
- **Why problematic**: User's stated reason or implicit concern
|
||||
|
||||
**Extract concrete examples:**
|
||||
- For Bash: Actual command that was problematic
|
||||
- For Edit/Write: Code pattern that was added
|
||||
- For Stop: What was missing before stopping
|
||||
|
||||
### 3. Create Regex Patterns
|
||||
|
||||
Convert behaviors into matchable patterns:
|
||||
|
||||
**Bash command patterns:**
|
||||
- `rm\s+-rf` for dangerous deletes
|
||||
- `sudo\s+` for privilege escalation
|
||||
- `chmod\s+777` for permission issues
|
||||
|
||||
**Code patterns (Edit/Write):**
|
||||
- `console\.log\(` for debug logging
|
||||
- `eval\(|new Function\(` for dangerous eval
|
||||
- `innerHTML\s*=` for XSS risks
|
||||
|
||||
**File path patterns:**
|
||||
- `\.env$` for environment files
|
||||
- `/node_modules/` for dependency files
|
||||
- `dist/|build/` for generated files
|
||||
|
||||
### 4. Categorize Severity
|
||||
|
||||
**High severity (should block in future):**
|
||||
- Dangerous commands (rm -rf, chmod 777)
|
||||
- Security issues (hardcoded secrets, eval)
|
||||
- Data loss risks
|
||||
|
||||
**Medium severity (warn):**
|
||||
- Style violations (console.log in production)
|
||||
- Wrong file types (editing generated files)
|
||||
- Missing best practices
|
||||
|
||||
**Low severity (optional):**
|
||||
- Preferences (coding style)
|
||||
- Non-critical patterns
|
||||
|
||||
### 5. Output Format
|
||||
|
||||
Return your findings as structured text in this format:
|
||||
|
||||
```
|
||||
## Hookify Analysis Results
|
||||
|
||||
### Issue 1: Dangerous rm Commands
|
||||
**Severity**: High
|
||||
**Tool**: Bash
|
||||
**Pattern**: `rm\s+-rf`
|
||||
**Occurrences**: 3 times
|
||||
**Context**: Used rm -rf on /tmp directories without verification
|
||||
**User Reaction**: "Please be more careful with rm commands"
|
||||
|
||||
**Suggested Rule:**
|
||||
- Name: warn-dangerous-rm
|
||||
- Event: bash
|
||||
- Pattern: rm\s+-rf
|
||||
- Message: "Dangerous rm command detected. Verify path before proceeding."
|
||||
|
||||
---
|
||||
|
||||
### Issue 2: Console.log in TypeScript
|
||||
**Severity**: Medium
|
||||
**Tool**: Edit/Write
|
||||
**Pattern**: `console\.log\(`
|
||||
**Occurrences**: 2 times
|
||||
**Context**: Added console.log statements to production TypeScript files
|
||||
**User Reaction**: "Don't use console.log in production code"
|
||||
|
||||
**Suggested Rule:**
|
||||
- Name: warn-console-log
|
||||
- Event: file
|
||||
- Pattern: console\.log\(
|
||||
- Message: "Console.log detected. Use proper logging library instead."
|
||||
|
||||
---
|
||||
|
||||
[Continue for each issue found...]
|
||||
|
||||
## Summary
|
||||
|
||||
Found {N} behaviors worth preventing:
|
||||
- {N} high severity
|
||||
- {N} medium severity
|
||||
- {N} low severity
|
||||
|
||||
Recommend creating rules for high and medium severity issues.
|
||||
```
|
||||
|
||||
**Quality Standards:**
|
||||
- Be specific about patterns (don't be overly broad)
|
||||
- Include actual examples from conversation
|
||||
- Explain why each issue matters
|
||||
- Provide ready-to-use regex patterns
|
||||
- Don't false-positive on discussions about what NOT to do
|
||||
|
||||
**Edge Cases:**
|
||||
|
||||
**User discussing hypotheticals:**
|
||||
- "What would happen if I used rm -rf?"
|
||||
- Don't treat as problematic behavior
|
||||
|
||||
**Teaching moments:**
|
||||
- "Here's what you shouldn't do: ..."
|
||||
- Context indicates explanation, not actual problem
|
||||
|
||||
**One-time accidents:**
|
||||
- Single occurrence, already fixed
|
||||
- Mention but mark as low priority
|
||||
|
||||
**Subjective preferences:**
|
||||
- "I prefer X over Y"
|
||||
- Mark as low severity, let user decide
|
||||
|
||||
**Return Results:**
|
||||
Provide your analysis in the structured format above. The /hookify command will use this to:
|
||||
1. Present findings to user
|
||||
2. Ask which rules to create
|
||||
3. Generate .local.md configuration files
|
||||
4. Save rules to .claude directory
|
||||
128
plugins/hookify/commands/configure.md
Normal file
128
plugins/hookify/commands/configure.md
Normal file
@@ -0,0 +1,128 @@
|
||||
---
|
||||
description: Enable or disable hookify rules interactively
|
||||
allowed-tools: ["Glob", "Read", "Edit", "AskUserQuestion", "Skill"]
|
||||
---
|
||||
|
||||
# Configure Hookify Rules
|
||||
|
||||
**Load hookify:writing-rules skill first** to understand rule format.
|
||||
|
||||
Enable or disable existing hookify rules using an interactive interface.
|
||||
|
||||
## Steps
|
||||
|
||||
### 1. Find Existing Rules
|
||||
|
||||
Use Glob tool to find all hookify rule files:
|
||||
```
|
||||
pattern: ".claude/hookify.*.local.md"
|
||||
```
|
||||
|
||||
If no rules found, inform user:
|
||||
```
|
||||
No hookify rules configured yet. Use `/hookify` to create your first rule.
|
||||
```
|
||||
|
||||
### 2. Read Current State
|
||||
|
||||
For each rule file:
|
||||
- Read the file
|
||||
- Extract `name` and `enabled` fields from frontmatter
|
||||
- Build list of rules with current state
|
||||
|
||||
### 3. Ask User Which Rules to Toggle
|
||||
|
||||
Use AskUserQuestion to let user select rules:
|
||||
|
||||
```json
|
||||
{
|
||||
"questions": [
|
||||
{
|
||||
"question": "Which rules would you like to enable or disable?",
|
||||
"header": "Configure",
|
||||
"multiSelect": true,
|
||||
"options": [
|
||||
{
|
||||
"label": "warn-dangerous-rm (currently enabled)",
|
||||
"description": "Warns about rm -rf commands"
|
||||
},
|
||||
{
|
||||
"label": "warn-console-log (currently disabled)",
|
||||
"description": "Warns about console.log in code"
|
||||
},
|
||||
{
|
||||
"label": "require-tests (currently enabled)",
|
||||
"description": "Requires tests before stopping"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
**Option format:**
|
||||
- Label: `{rule-name} (currently {enabled|disabled})`
|
||||
- Description: Brief description from rule's message or pattern
|
||||
|
||||
### 4. Parse User Selection
|
||||
|
||||
For each selected rule:
|
||||
- Determine current state from label (enabled/disabled)
|
||||
- Toggle state: enabled → disabled, disabled → enabled
|
||||
|
||||
### 5. Update Rule Files
|
||||
|
||||
For each rule to toggle:
|
||||
- Use Read tool to read current content
|
||||
- Use Edit tool to change `enabled: true` to `enabled: false` (or vice versa)
|
||||
- Handle both with and without quotes
|
||||
|
||||
**Edit pattern for enabling:**
|
||||
```
|
||||
old_string: "enabled: false"
|
||||
new_string: "enabled: true"
|
||||
```
|
||||
|
||||
**Edit pattern for disabling:**
|
||||
```
|
||||
old_string: "enabled: true"
|
||||
new_string: "enabled: false"
|
||||
```
|
||||
|
||||
### 6. Confirm Changes
|
||||
|
||||
Show user what was changed:
|
||||
|
||||
```
|
||||
## Hookify Rules Updated
|
||||
|
||||
**Enabled:**
|
||||
- warn-console-log
|
||||
|
||||
**Disabled:**
|
||||
- warn-dangerous-rm
|
||||
|
||||
**Unchanged:**
|
||||
- require-tests
|
||||
|
||||
Changes apply immediately - no restart needed
|
||||
```
|
||||
|
||||
## Important Notes
|
||||
|
||||
- Changes take effect immediately on next tool use
|
||||
- You can also manually edit .claude/hookify.*.local.md files
|
||||
- To permanently remove a rule, delete its .local.md file
|
||||
- Use `/hookify:list` to see all configured rules
|
||||
|
||||
## Edge Cases
|
||||
|
||||
**No rules to configure:**
|
||||
- Show message about using `/hookify` to create rules first
|
||||
|
||||
**User selects no rules:**
|
||||
- Inform that no changes were made
|
||||
|
||||
**File read/write errors:**
|
||||
- Inform user of specific error
|
||||
- Suggest manual editing as fallback
|
||||
175
plugins/hookify/commands/help.md
Normal file
175
plugins/hookify/commands/help.md
Normal file
@@ -0,0 +1,175 @@
|
||||
---
|
||||
description: Get help with the hookify plugin
|
||||
allowed-tools: ["Read"]
|
||||
---
|
||||
|
||||
# Hookify Plugin Help
|
||||
|
||||
Explain how the hookify plugin works and how to use it.
|
||||
|
||||
## Overview
|
||||
|
||||
The hookify plugin makes it easy to create custom hooks that prevent unwanted behaviors. Instead of editing `hooks.json` files, users create simple markdown configuration files that define patterns to watch for.
|
||||
|
||||
## How It Works
|
||||
|
||||
### 1. Hook System
|
||||
|
||||
Hookify installs generic hooks that run on these events:
|
||||
- **PreToolUse**: Before any tool executes (Bash, Edit, Write, etc.)
|
||||
- **PostToolUse**: After a tool executes
|
||||
- **Stop**: When Claude wants to stop working
|
||||
- **UserPromptSubmit**: When user submits a prompt
|
||||
|
||||
These hooks read configuration files from `.claude/hookify.*.local.md` and check if any rules match the current operation.
|
||||
|
||||
### 2. Configuration Files
|
||||
|
||||
Users create rules in `.claude/hookify.{rule-name}.local.md` files:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: warn-dangerous-rm
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: rm\s+-rf
|
||||
---
|
||||
|
||||
⚠️ **Dangerous rm command detected!**
|
||||
|
||||
This command could delete important files. Please verify the path.
|
||||
```
|
||||
|
||||
**Key fields:**
|
||||
- `name`: Unique identifier for the rule
|
||||
- `enabled`: true/false to activate/deactivate
|
||||
- `event`: bash, file, stop, prompt, or all
|
||||
- `pattern`: Regex pattern to match
|
||||
|
||||
The message body is what Claude sees when the rule triggers.
|
||||
|
||||
### 3. Creating Rules
|
||||
|
||||
**Option A: Use /hookify command**
|
||||
```
|
||||
/hookify Don't use console.log in production files
|
||||
```
|
||||
|
||||
This analyzes your request and creates the appropriate rule file.
|
||||
|
||||
**Option B: Create manually**
|
||||
Create `.claude/hookify.my-rule.local.md` with the format above.
|
||||
|
||||
**Option C: Analyze conversation**
|
||||
```
|
||||
/hookify
|
||||
```
|
||||
|
||||
Without arguments, hookify analyzes recent conversation to find behaviors you want to prevent.
|
||||
|
||||
## Available Commands
|
||||
|
||||
- **`/hookify`** - Create hooks from conversation analysis or explicit instructions
|
||||
- **`/hookify:help`** - Show this help (what you're reading now)
|
||||
- **`/hookify:list`** - List all configured hooks
|
||||
- **`/hookify:configure`** - Enable/disable existing hooks interactively
|
||||
|
||||
## Example Use Cases
|
||||
|
||||
**Prevent dangerous commands:**
|
||||
```markdown
|
||||
---
|
||||
name: block-chmod-777
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: chmod\s+777
|
||||
---
|
||||
|
||||
Don't use chmod 777 - it's a security risk. Use specific permissions instead.
|
||||
```
|
||||
|
||||
**Warn about debugging code:**
|
||||
```markdown
|
||||
---
|
||||
name: warn-console-log
|
||||
enabled: true
|
||||
event: file
|
||||
pattern: console\.log\(
|
||||
---
|
||||
|
||||
Console.log detected. Remember to remove debug logging before committing.
|
||||
```
|
||||
|
||||
**Require tests before stopping:**
|
||||
```markdown
|
||||
---
|
||||
name: require-tests
|
||||
enabled: true
|
||||
event: stop
|
||||
pattern: .*
|
||||
---
|
||||
|
||||
Did you run tests before finishing? Make sure `npm test` or equivalent was executed.
|
||||
```
|
||||
|
||||
## Pattern Syntax
|
||||
|
||||
Use Python regex syntax:
|
||||
- `\s` - whitespace
|
||||
- `\.` - literal dot
|
||||
- `|` - OR
|
||||
- `+` - one or more
|
||||
- `*` - zero or more
|
||||
- `\d` - digit
|
||||
- `[abc]` - character class
|
||||
|
||||
**Examples:**
|
||||
- `rm\s+-rf` - matches "rm -rf"
|
||||
- `console\.log\(` - matches "console.log("
|
||||
- `(eval|exec)\(` - matches "eval(" or "exec("
|
||||
- `\.env$` - matches files ending in .env
|
||||
|
||||
## Important Notes
|
||||
|
||||
**No Restart Needed**: Hookify rules (`.local.md` files) take effect immediately on the next tool use. The hookify hooks are already loaded and read your rules dynamically.
|
||||
|
||||
**Block or Warn**: Rules can either `block` operations (prevent execution) or `warn` (show message but allow). Set `action: block` or `action: warn` in the rule's frontmatter.
|
||||
|
||||
**Rule Files**: Keep rules in `.claude/hookify.*.local.md` - they should be git-ignored (add to .gitignore if needed).
|
||||
|
||||
**Disable Rules**: Set `enabled: false` in frontmatter or delete the file.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**Hook not triggering:**
|
||||
- Check rule file is in `.claude/` directory
|
||||
- Verify `enabled: true` in frontmatter
|
||||
- Confirm pattern is valid regex
|
||||
- Test pattern: `python3 -c "import re; print(re.search('your_pattern', 'test_text'))"`
|
||||
- Rules take effect immediately - no restart needed
|
||||
|
||||
**Import errors:**
|
||||
- Check Python 3 is available: `python3 --version`
|
||||
- Verify hookify plugin is installed correctly
|
||||
|
||||
**Pattern not matching:**
|
||||
- Test regex separately
|
||||
- Check for escaping issues (use unquoted patterns in YAML)
|
||||
- Try simpler pattern first, then refine
|
||||
|
||||
## Getting Started
|
||||
|
||||
1. Create your first rule:
|
||||
```
|
||||
/hookify Warn me when I try to use rm -rf
|
||||
```
|
||||
|
||||
2. Try to trigger it:
|
||||
- Ask Claude to run `rm -rf /tmp/test`
|
||||
- You should see the warning
|
||||
|
||||
4. Refine the rule by editing `.claude/hookify.warn-rm.local.md`
|
||||
|
||||
5. Create more rules as you encounter unwanted behaviors
|
||||
|
||||
For more examples, check the `${CLAUDE_PLUGIN_ROOT}/examples/` directory.
|
||||
231
plugins/hookify/commands/hookify.md
Normal file
231
plugins/hookify/commands/hookify.md
Normal file
@@ -0,0 +1,231 @@
|
||||
---
|
||||
description: Create hooks to prevent unwanted behaviors from conversation analysis or explicit instructions
|
||||
argument-hint: Optional specific behavior to address
|
||||
allowed-tools: ["Read", "Write", "AskUserQuestion", "Task", "Grep", "TodoWrite", "Skill"]
|
||||
---
|
||||
|
||||
# Hookify - Create Hooks from Unwanted Behaviors
|
||||
|
||||
**FIRST: Load the hookify:writing-rules skill** using the Skill tool to understand rule file format and syntax.
|
||||
|
||||
Create hook rules to prevent problematic behaviors by analyzing the conversation or from explicit user instructions.
|
||||
|
||||
## Your Task
|
||||
|
||||
You will help the user create hookify rules to prevent unwanted behaviors. Follow these steps:
|
||||
|
||||
### Step 1: Gather Behavior Information
|
||||
|
||||
**If $ARGUMENTS is provided:**
|
||||
- User has given specific instructions: `$ARGUMENTS`
|
||||
- Still analyze recent conversation (last 10-15 user messages) for additional context
|
||||
- Look for examples of the behavior happening
|
||||
|
||||
**If $ARGUMENTS is empty:**
|
||||
- Launch the conversation-analyzer agent to find problematic behaviors
|
||||
- Agent will scan user prompts for frustration signals
|
||||
- Agent will return structured findings
|
||||
|
||||
**To analyze conversation:**
|
||||
Use the Task tool to launch conversation-analyzer agent:
|
||||
```
|
||||
{
|
||||
"subagent_type": "general-purpose",
|
||||
"description": "Analyze conversation for unwanted behaviors",
|
||||
"prompt": "You are analyzing a Claude Code conversation to find behaviors the user wants to prevent.
|
||||
|
||||
Read user messages in the current conversation and identify:
|
||||
1. Explicit requests to avoid something (\"don't do X\", \"stop doing Y\")
|
||||
2. Corrections or reversions (user fixing Claude's actions)
|
||||
3. Frustrated reactions (\"why did you do X?\", \"I didn't ask for that\")
|
||||
4. Repeated issues (same problem multiple times)
|
||||
|
||||
For each issue found, extract:
|
||||
- What tool was used (Bash, Edit, Write, etc.)
|
||||
- Specific pattern or command
|
||||
- Why it was problematic
|
||||
- User's stated reason
|
||||
|
||||
Return findings as a structured list with:
|
||||
- category: Type of issue
|
||||
- tool: Which tool was involved
|
||||
- pattern: Regex or literal pattern to match
|
||||
- context: What happened
|
||||
- severity: high/medium/low
|
||||
|
||||
Focus on the most recent issues (last 20-30 messages). Don't go back further unless explicitly asked."
|
||||
}
|
||||
```
|
||||
|
||||
### Step 2: Present Findings to User
|
||||
|
||||
After gathering behaviors (from arguments or agent), present to user using AskUserQuestion:
|
||||
|
||||
**Question 1: Which behaviors to hookify?**
|
||||
- Header: "Create Rules"
|
||||
- multiSelect: true
|
||||
- Options: List each detected behavior (max 4)
|
||||
- Label: Short description (e.g., "Block rm -rf")
|
||||
- Description: Why it's problematic
|
||||
|
||||
**Question 2: For each selected behavior, ask about action:**
|
||||
- "Should this block the operation or just warn?"
|
||||
- Options:
|
||||
- "Just warn" (action: warn - shows message but allows)
|
||||
- "Block operation" (action: block - prevents execution)
|
||||
|
||||
**Question 3: Ask for example patterns:**
|
||||
- "What patterns should trigger this rule?"
|
||||
- Show detected patterns
|
||||
- Allow user to refine or add more
|
||||
|
||||
### Step 3: Generate Rule Files
|
||||
|
||||
For each confirmed behavior, create a `.claude/hookify.{rule-name}.local.md` file:
|
||||
|
||||
**Rule naming convention:**
|
||||
- Use kebab-case
|
||||
- Be descriptive: `block-dangerous-rm`, `warn-console-log`, `require-tests-before-stop`
|
||||
- Start with action verb: block, warn, prevent, require
|
||||
|
||||
**File format:**
|
||||
```markdown
|
||||
---
|
||||
name: {rule-name}
|
||||
enabled: true
|
||||
event: {bash|file|stop|prompt|all}
|
||||
pattern: {regex pattern}
|
||||
action: {warn|block}
|
||||
---
|
||||
|
||||
{Message to show Claude when rule triggers}
|
||||
```
|
||||
|
||||
**Action values:**
|
||||
- `warn`: Show message but allow operation (default)
|
||||
- `block`: Prevent operation or stop session
|
||||
|
||||
**For more complex rules (multiple conditions):**
|
||||
```markdown
|
||||
---
|
||||
name: {rule-name}
|
||||
enabled: true
|
||||
event: file
|
||||
conditions:
|
||||
- field: file_path
|
||||
operator: regex_match
|
||||
pattern: \.env$
|
||||
- field: new_text
|
||||
operator: contains
|
||||
pattern: API_KEY
|
||||
---
|
||||
|
||||
{Warning message}
|
||||
```
|
||||
|
||||
### Step 4: Create Files and Confirm
|
||||
|
||||
**IMPORTANT**: Rule files must be created in the current working directory's `.claude/` folder, NOT the plugin directory.
|
||||
|
||||
Use the current working directory (where Claude Code was started) as the base path.
|
||||
|
||||
1. Check if `.claude/` directory exists in current working directory
|
||||
- If not, create it first with: `mkdir -p .claude`
|
||||
|
||||
2. Use Write tool to create each `.claude/hookify.{name}.local.md` file
|
||||
- Use relative path from current working directory: `.claude/hookify.{name}.local.md`
|
||||
- The path should resolve to the project's .claude directory, not the plugin's
|
||||
|
||||
3. Show user what was created:
|
||||
```
|
||||
Created 3 hookify rules:
|
||||
- .claude/hookify.dangerous-rm.local.md
|
||||
- .claude/hookify.console-log.local.md
|
||||
- .claude/hookify.sensitive-files.local.md
|
||||
|
||||
These rules will trigger on:
|
||||
- dangerous-rm: Bash commands matching "rm -rf"
|
||||
- console-log: Edits adding console.log statements
|
||||
- sensitive-files: Edits to .env or credentials files
|
||||
```
|
||||
|
||||
4. Verify files were created in the correct location by listing them
|
||||
|
||||
5. Inform user: **"Rules are active immediately - no restart needed!"**
|
||||
|
||||
The hookify hooks are already loaded and will read your new rules on the next tool use.
|
||||
|
||||
## Event Types Reference
|
||||
|
||||
- **bash**: Matches Bash tool commands
|
||||
- **file**: Matches Edit, Write, MultiEdit tools
|
||||
- **stop**: Matches when agent wants to stop (use for completion checks)
|
||||
- **prompt**: Matches when user submits prompts
|
||||
- **all**: Matches all events
|
||||
|
||||
## Pattern Writing Tips
|
||||
|
||||
**Bash patterns:**
|
||||
- Match dangerous commands: `rm\s+-rf|chmod\s+777|dd\s+if=`
|
||||
- Match specific tools: `npm\s+install\s+|pip\s+install`
|
||||
|
||||
**File patterns:**
|
||||
- Match code patterns: `console\.log\(|eval\(|innerHTML\s*=`
|
||||
- Match file paths: `\.env$|\.git/|node_modules/`
|
||||
|
||||
**Stop patterns:**
|
||||
- Check for missing steps: (check transcript or completion criteria)
|
||||
|
||||
## Example Workflow
|
||||
|
||||
**User says**: "/hookify Don't use rm -rf without asking me first"
|
||||
|
||||
**Your response**:
|
||||
1. Analyze: User wants to prevent rm -rf commands
|
||||
2. Ask: "Should I block this command or just warn you?"
|
||||
3. User selects: "Just warn"
|
||||
4. Create `.claude/hookify.dangerous-rm.local.md`:
|
||||
```markdown
|
||||
---
|
||||
name: warn-dangerous-rm
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: rm\s+-rf
|
||||
---
|
||||
|
||||
⚠️ **Dangerous rm command detected**
|
||||
|
||||
You requested to be warned before using rm -rf.
|
||||
Please verify the path is correct.
|
||||
```
|
||||
5. Confirm: "Created hookify rule. It's active immediately - try triggering it!"
|
||||
|
||||
## Important Notes
|
||||
|
||||
- **No restart needed**: Rules take effect immediately on the next tool use
|
||||
- **File location**: Create files in project's `.claude/` directory (current working directory), NOT the plugin's .claude/
|
||||
- **Regex syntax**: Use Python regex syntax (raw strings, no need to escape in YAML)
|
||||
- **Action types**: Rules can `warn` (default) or `block` operations
|
||||
- **Testing**: Test rules immediately after creating them
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
**If rule file creation fails:**
|
||||
1. Check current working directory with pwd
|
||||
2. Ensure `.claude/` directory exists (create with mkdir if needed)
|
||||
3. Use absolute path if needed: `{cwd}/.claude/hookify.{name}.local.md`
|
||||
4. Verify file was created with Glob or ls
|
||||
|
||||
**If rule doesn't trigger after creation:**
|
||||
1. Verify file is in project `.claude/` not plugin `.claude/`
|
||||
2. Check file with Read tool to ensure pattern is correct
|
||||
3. Test pattern with: `python3 -c "import re; print(re.search(r'pattern', 'test text'))"`
|
||||
4. Verify `enabled: true` in frontmatter
|
||||
5. Remember: Rules work immediately, no restart needed
|
||||
|
||||
**If blocking seems too strict:**
|
||||
1. Change `action: block` to `action: warn` in the rule file
|
||||
2. Or adjust the pattern to be more specific
|
||||
3. Changes take effect on next tool use
|
||||
|
||||
Use TodoWrite to track your progress through the steps.
|
||||
82
plugins/hookify/commands/list.md
Normal file
82
plugins/hookify/commands/list.md
Normal file
@@ -0,0 +1,82 @@
|
||||
---
|
||||
description: List all configured hookify rules
|
||||
allowed-tools: ["Glob", "Read", "Skill"]
|
||||
---
|
||||
|
||||
# List Hookify Rules
|
||||
|
||||
**Load hookify:writing-rules skill first** to understand rule format.
|
||||
|
||||
Show all configured hookify rules in the project.
|
||||
|
||||
## Steps
|
||||
|
||||
1. Use Glob tool to find all hookify rule files:
|
||||
```
|
||||
pattern: ".claude/hookify.*.local.md"
|
||||
```
|
||||
|
||||
2. For each file found:
|
||||
- Use Read tool to read the file
|
||||
- Extract frontmatter fields: name, enabled, event, pattern
|
||||
- Extract message preview (first 100 chars)
|
||||
|
||||
3. Present results in a table:
|
||||
|
||||
```
|
||||
## Configured Hookify Rules
|
||||
|
||||
| Name | Enabled | Event | Pattern | File |
|
||||
|------|---------|-------|---------|------|
|
||||
| warn-dangerous-rm | ✅ Yes | bash | rm\s+-rf | hookify.dangerous-rm.local.md |
|
||||
| warn-console-log | ✅ Yes | file | console\.log\( | hookify.console-log.local.md |
|
||||
| check-tests | ❌ No | stop | .* | hookify.require-tests.local.md |
|
||||
|
||||
**Total**: 3 rules (2 enabled, 1 disabled)
|
||||
```
|
||||
|
||||
4. For each rule, show a brief preview:
|
||||
```
|
||||
### warn-dangerous-rm
|
||||
**Event**: bash
|
||||
**Pattern**: `rm\s+-rf`
|
||||
**Message**: "⚠️ **Dangerous rm command detected!** This command could delete..."
|
||||
|
||||
**Status**: ✅ Active
|
||||
**File**: .claude/hookify.dangerous-rm.local.md
|
||||
```
|
||||
|
||||
5. Add helpful footer:
|
||||
```
|
||||
---
|
||||
|
||||
To modify a rule: Edit the .local.md file directly
|
||||
To disable a rule: Set `enabled: false` in frontmatter
|
||||
To enable a rule: Set `enabled: true` in frontmatter
|
||||
To delete a rule: Remove the .local.md file
|
||||
To create a rule: Use `/hookify` command
|
||||
|
||||
**Remember**: Changes take effect immediately - no restart needed
|
||||
```
|
||||
|
||||
## If No Rules Found
|
||||
|
||||
If no hookify rules exist:
|
||||
|
||||
```
|
||||
## No Hookify Rules Configured
|
||||
|
||||
You haven't created any hookify rules yet.
|
||||
|
||||
To get started:
|
||||
1. Use `/hookify` to analyze conversation and create rules
|
||||
2. Or manually create `.claude/hookify.my-rule.local.md` files
|
||||
3. See `/hookify:help` for documentation
|
||||
|
||||
Example:
|
||||
```
|
||||
/hookify Warn me when I use console.log
|
||||
```
|
||||
|
||||
Check `${CLAUDE_PLUGIN_ROOT}/examples/` for example rule files.
|
||||
```
|
||||
0
plugins/hookify/core/__init__.py
Normal file
0
plugins/hookify/core/__init__.py
Normal file
297
plugins/hookify/core/config_loader.py
Normal file
297
plugins/hookify/core/config_loader.py
Normal file
@@ -0,0 +1,297 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Configuration loader for hookify plugin.
|
||||
|
||||
Loads and parses .claude/hookify.*.local.md files.
|
||||
"""
|
||||
|
||||
import os
|
||||
import sys
|
||||
import glob
|
||||
import re
|
||||
from typing import List, Optional, Dict, Any
|
||||
from dataclasses import dataclass, field
|
||||
|
||||
|
||||
@dataclass
|
||||
class Condition:
|
||||
"""A single condition for matching."""
|
||||
field: str # "command", "new_text", "old_text", "file_path", etc.
|
||||
operator: str # "regex_match", "contains", "equals", etc.
|
||||
pattern: str # Pattern to match
|
||||
|
||||
@classmethod
|
||||
def from_dict(cls, data: Dict[str, Any]) -> 'Condition':
|
||||
"""Create Condition from dict."""
|
||||
return cls(
|
||||
field=data.get('field', ''),
|
||||
operator=data.get('operator', 'regex_match'),
|
||||
pattern=data.get('pattern', '')
|
||||
)
|
||||
|
||||
|
||||
@dataclass
|
||||
class Rule:
|
||||
"""A hookify rule."""
|
||||
name: str
|
||||
enabled: bool
|
||||
event: str # "bash", "file", "stop", "all", etc.
|
||||
pattern: Optional[str] = None # Simple pattern (legacy)
|
||||
conditions: List[Condition] = field(default_factory=list)
|
||||
action: str = "warn" # "warn" or "block" (future)
|
||||
tool_matcher: Optional[str] = None # Override tool matching
|
||||
message: str = "" # Message body from markdown
|
||||
|
||||
@classmethod
|
||||
def from_dict(cls, frontmatter: Dict[str, Any], message: str) -> 'Rule':
|
||||
"""Create Rule from frontmatter dict and message body."""
|
||||
# Handle both simple pattern and complex conditions
|
||||
conditions = []
|
||||
|
||||
# New style: explicit conditions list
|
||||
if 'conditions' in frontmatter:
|
||||
cond_list = frontmatter['conditions']
|
||||
if isinstance(cond_list, list):
|
||||
conditions = [Condition.from_dict(c) for c in cond_list]
|
||||
|
||||
# Legacy style: simple pattern field
|
||||
simple_pattern = frontmatter.get('pattern')
|
||||
if simple_pattern and not conditions:
|
||||
# Convert simple pattern to condition
|
||||
# Infer field from event
|
||||
event = frontmatter.get('event', 'all')
|
||||
if event == 'bash':
|
||||
field = 'command'
|
||||
elif event == 'file':
|
||||
field = 'new_text'
|
||||
else:
|
||||
field = 'content'
|
||||
|
||||
conditions = [Condition(
|
||||
field=field,
|
||||
operator='regex_match',
|
||||
pattern=simple_pattern
|
||||
)]
|
||||
|
||||
return cls(
|
||||
name=frontmatter.get('name', 'unnamed'),
|
||||
enabled=frontmatter.get('enabled', True),
|
||||
event=frontmatter.get('event', 'all'),
|
||||
pattern=simple_pattern,
|
||||
conditions=conditions,
|
||||
action=frontmatter.get('action', 'warn'),
|
||||
tool_matcher=frontmatter.get('tool_matcher'),
|
||||
message=message.strip()
|
||||
)
|
||||
|
||||
|
||||
def extract_frontmatter(content: str) -> tuple[Dict[str, Any], str]:
|
||||
"""Extract YAML frontmatter and message body from markdown.
|
||||
|
||||
Returns (frontmatter_dict, message_body).
|
||||
|
||||
Supports multi-line dictionary items in lists by preserving indentation.
|
||||
"""
|
||||
if not content.startswith('---'):
|
||||
return {}, content
|
||||
|
||||
# Split on --- markers
|
||||
parts = content.split('---', 2)
|
||||
if len(parts) < 3:
|
||||
return {}, content
|
||||
|
||||
frontmatter_text = parts[1]
|
||||
message = parts[2].strip()
|
||||
|
||||
# Simple YAML parser that handles indented list items
|
||||
frontmatter = {}
|
||||
lines = frontmatter_text.split('\n')
|
||||
|
||||
current_key = None
|
||||
current_list = []
|
||||
current_dict = {}
|
||||
in_list = False
|
||||
in_dict_item = False
|
||||
|
||||
for line in lines:
|
||||
# Skip empty lines and comments
|
||||
stripped = line.strip()
|
||||
if not stripped or stripped.startswith('#'):
|
||||
continue
|
||||
|
||||
# Check indentation level
|
||||
indent = len(line) - len(line.lstrip())
|
||||
|
||||
# Top-level key (no indentation or minimal)
|
||||
if indent == 0 and ':' in line and not line.strip().startswith('-'):
|
||||
# Save previous list/dict if any
|
||||
if in_list and current_key:
|
||||
if in_dict_item and current_dict:
|
||||
current_list.append(current_dict)
|
||||
current_dict = {}
|
||||
frontmatter[current_key] = current_list
|
||||
in_list = False
|
||||
in_dict_item = False
|
||||
current_list = []
|
||||
|
||||
key, value = line.split(':', 1)
|
||||
key = key.strip()
|
||||
value = value.strip()
|
||||
|
||||
if not value:
|
||||
# Empty value - list or nested structure follows
|
||||
current_key = key
|
||||
in_list = True
|
||||
current_list = []
|
||||
else:
|
||||
# Simple key-value pair
|
||||
value = value.strip('"').strip("'")
|
||||
if value.lower() == 'true':
|
||||
value = True
|
||||
elif value.lower() == 'false':
|
||||
value = False
|
||||
frontmatter[key] = value
|
||||
|
||||
# List item (starts with -)
|
||||
elif stripped.startswith('-') and in_list:
|
||||
# Save previous dict item if any
|
||||
if in_dict_item and current_dict:
|
||||
current_list.append(current_dict)
|
||||
current_dict = {}
|
||||
|
||||
item_text = stripped[1:].strip()
|
||||
|
||||
# Check if this is an inline dict (key: value on same line)
|
||||
if ':' in item_text and ',' in item_text:
|
||||
# Inline comma-separated dict: "- field: command, operator: regex_match"
|
||||
item_dict = {}
|
||||
for part in item_text.split(','):
|
||||
if ':' in part:
|
||||
k, v = part.split(':', 1)
|
||||
item_dict[k.strip()] = v.strip().strip('"').strip("'")
|
||||
current_list.append(item_dict)
|
||||
in_dict_item = False
|
||||
elif ':' in item_text:
|
||||
# Start of multi-line dict item: "- field: command"
|
||||
in_dict_item = True
|
||||
k, v = item_text.split(':', 1)
|
||||
current_dict = {k.strip(): v.strip().strip('"').strip("'")}
|
||||
else:
|
||||
# Simple list item
|
||||
current_list.append(item_text.strip('"').strip("'"))
|
||||
in_dict_item = False
|
||||
|
||||
# Continuation of dict item (indented under list item)
|
||||
elif indent > 2 and in_dict_item and ':' in line:
|
||||
# This is a field of the current dict item
|
||||
k, v = stripped.split(':', 1)
|
||||
current_dict[k.strip()] = v.strip().strip('"').strip("'")
|
||||
|
||||
# Save final list/dict if any
|
||||
if in_list and current_key:
|
||||
if in_dict_item and current_dict:
|
||||
current_list.append(current_dict)
|
||||
frontmatter[current_key] = current_list
|
||||
|
||||
return frontmatter, message
|
||||
|
||||
|
||||
def load_rules(event: Optional[str] = None) -> List[Rule]:
|
||||
"""Load all hookify rules from .claude directory.
|
||||
|
||||
Args:
|
||||
event: Optional event filter ("bash", "file", "stop", etc.)
|
||||
|
||||
Returns:
|
||||
List of enabled Rule objects matching the event.
|
||||
"""
|
||||
rules = []
|
||||
|
||||
# Find all hookify.*.local.md files
|
||||
pattern = os.path.join('.claude', 'hookify.*.local.md')
|
||||
files = glob.glob(pattern)
|
||||
|
||||
for file_path in files:
|
||||
try:
|
||||
rule = load_rule_file(file_path)
|
||||
if not rule:
|
||||
continue
|
||||
|
||||
# Filter by event if specified
|
||||
if event:
|
||||
if rule.event != 'all' and rule.event != event:
|
||||
continue
|
||||
|
||||
# Only include enabled rules
|
||||
if rule.enabled:
|
||||
rules.append(rule)
|
||||
|
||||
except (IOError, OSError, PermissionError) as e:
|
||||
# File I/O errors - log and continue
|
||||
print(f"Warning: Failed to read {file_path}: {e}", file=sys.stderr)
|
||||
continue
|
||||
except (ValueError, KeyError, AttributeError, TypeError) as e:
|
||||
# Parsing errors - log and continue
|
||||
print(f"Warning: Failed to parse {file_path}: {e}", file=sys.stderr)
|
||||
continue
|
||||
except Exception as e:
|
||||
# Unexpected errors - log with type details
|
||||
print(f"Warning: Unexpected error loading {file_path} ({type(e).__name__}): {e}", file=sys.stderr)
|
||||
continue
|
||||
|
||||
return rules
|
||||
|
||||
|
||||
def load_rule_file(file_path: str) -> Optional[Rule]:
|
||||
"""Load a single rule file.
|
||||
|
||||
Returns:
|
||||
Rule object or None if file is invalid.
|
||||
"""
|
||||
try:
|
||||
with open(file_path, 'r') as f:
|
||||
content = f.read()
|
||||
|
||||
frontmatter, message = extract_frontmatter(content)
|
||||
|
||||
if not frontmatter:
|
||||
print(f"Warning: {file_path} missing YAML frontmatter (must start with ---)", file=sys.stderr)
|
||||
return None
|
||||
|
||||
rule = Rule.from_dict(frontmatter, message)
|
||||
return rule
|
||||
|
||||
except (IOError, OSError, PermissionError) as e:
|
||||
print(f"Error: Cannot read {file_path}: {e}", file=sys.stderr)
|
||||
return None
|
||||
except (ValueError, KeyError, AttributeError, TypeError) as e:
|
||||
print(f"Error: Malformed rule file {file_path}: {e}", file=sys.stderr)
|
||||
return None
|
||||
except UnicodeDecodeError as e:
|
||||
print(f"Error: Invalid encoding in {file_path}: {e}", file=sys.stderr)
|
||||
return None
|
||||
except Exception as e:
|
||||
print(f"Error: Unexpected error parsing {file_path} ({type(e).__name__}): {e}", file=sys.stderr)
|
||||
return None
|
||||
|
||||
|
||||
# For testing
|
||||
if __name__ == '__main__':
|
||||
import sys
|
||||
|
||||
# Test frontmatter parsing
|
||||
test_content = """---
|
||||
name: test-rule
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: "rm -rf"
|
||||
---
|
||||
|
||||
⚠️ Dangerous command detected!
|
||||
"""
|
||||
|
||||
fm, msg = extract_frontmatter(test_content)
|
||||
print("Frontmatter:", fm)
|
||||
print("Message:", msg)
|
||||
|
||||
rule = Rule.from_dict(fm, msg)
|
||||
print("Rule:", rule)
|
||||
313
plugins/hookify/core/rule_engine.py
Normal file
313
plugins/hookify/core/rule_engine.py
Normal file
@@ -0,0 +1,313 @@
|
||||
#!/usr/bin/env python3
|
||||
"""Rule evaluation engine for hookify plugin."""
|
||||
|
||||
import re
|
||||
import sys
|
||||
from functools import lru_cache
|
||||
from typing import List, Dict, Any, Optional
|
||||
|
||||
# Import from local module
|
||||
from hookify.core.config_loader import Rule, Condition
|
||||
|
||||
|
||||
# Cache compiled regexes (max 128 patterns)
|
||||
@lru_cache(maxsize=128)
|
||||
def compile_regex(pattern: str) -> re.Pattern:
|
||||
"""Compile regex pattern with caching.
|
||||
|
||||
Args:
|
||||
pattern: Regex pattern string
|
||||
|
||||
Returns:
|
||||
Compiled regex pattern
|
||||
"""
|
||||
return re.compile(pattern, re.IGNORECASE)
|
||||
|
||||
|
||||
class RuleEngine:
|
||||
"""Evaluates rules against hook input data."""
|
||||
|
||||
def __init__(self):
|
||||
"""Initialize rule engine."""
|
||||
# No need for instance cache anymore - using global lru_cache
|
||||
pass
|
||||
|
||||
def evaluate_rules(self, rules: List[Rule], input_data: Dict[str, Any]) -> Dict[str, Any]:
|
||||
"""Evaluate all rules and return combined results.
|
||||
|
||||
Checks all rules and accumulates matches. Blocking rules take priority
|
||||
over warning rules. All matching rule messages are combined.
|
||||
|
||||
Args:
|
||||
rules: List of Rule objects to evaluate
|
||||
input_data: Hook input JSON (tool_name, tool_input, etc.)
|
||||
|
||||
Returns:
|
||||
Response dict with systemMessage, hookSpecificOutput, etc.
|
||||
Empty dict {} if no rules match.
|
||||
"""
|
||||
hook_event = input_data.get('hook_event_name', '')
|
||||
blocking_rules = []
|
||||
warning_rules = []
|
||||
|
||||
for rule in rules:
|
||||
if self._rule_matches(rule, input_data):
|
||||
if rule.action == 'block':
|
||||
blocking_rules.append(rule)
|
||||
else:
|
||||
warning_rules.append(rule)
|
||||
|
||||
# If any blocking rules matched, block the operation
|
||||
if blocking_rules:
|
||||
messages = [f"**[{r.name}]**\n{r.message}" for r in blocking_rules]
|
||||
combined_message = "\n\n".join(messages)
|
||||
|
||||
# Use appropriate blocking format based on event type
|
||||
if hook_event == 'Stop':
|
||||
return {
|
||||
"decision": "block",
|
||||
"reason": combined_message,
|
||||
"systemMessage": combined_message
|
||||
}
|
||||
elif hook_event in ['PreToolUse', 'PostToolUse']:
|
||||
return {
|
||||
"hookSpecificOutput": {
|
||||
"hookEventName": hook_event,
|
||||
"permissionDecision": "deny"
|
||||
},
|
||||
"systemMessage": combined_message
|
||||
}
|
||||
else:
|
||||
# For other events, just show message
|
||||
return {
|
||||
"systemMessage": combined_message
|
||||
}
|
||||
|
||||
# If only warnings, show them but allow operation
|
||||
if warning_rules:
|
||||
messages = [f"**[{r.name}]**\n{r.message}" for r in warning_rules]
|
||||
return {
|
||||
"systemMessage": "\n\n".join(messages)
|
||||
}
|
||||
|
||||
# No matches - allow operation
|
||||
return {}
|
||||
|
||||
def _rule_matches(self, rule: Rule, input_data: Dict[str, Any]) -> bool:
|
||||
"""Check if rule matches input data.
|
||||
|
||||
Args:
|
||||
rule: Rule to evaluate
|
||||
input_data: Hook input data
|
||||
|
||||
Returns:
|
||||
True if rule matches, False otherwise
|
||||
"""
|
||||
# Extract tool information
|
||||
tool_name = input_data.get('tool_name', '')
|
||||
tool_input = input_data.get('tool_input', {})
|
||||
|
||||
# Check tool matcher if specified
|
||||
if rule.tool_matcher:
|
||||
if not self._matches_tool(rule.tool_matcher, tool_name):
|
||||
return False
|
||||
|
||||
# If no conditions, don't match
|
||||
# (Rules must have at least one condition to be valid)
|
||||
if not rule.conditions:
|
||||
return False
|
||||
|
||||
# All conditions must match
|
||||
for condition in rule.conditions:
|
||||
if not self._check_condition(condition, tool_name, tool_input, input_data):
|
||||
return False
|
||||
|
||||
return True
|
||||
|
||||
def _matches_tool(self, matcher: str, tool_name: str) -> bool:
|
||||
"""Check if tool_name matches the matcher pattern.
|
||||
|
||||
Args:
|
||||
matcher: Pattern like "Bash", "Edit|Write", "*"
|
||||
tool_name: Actual tool name
|
||||
|
||||
Returns:
|
||||
True if matches
|
||||
"""
|
||||
if matcher == '*':
|
||||
return True
|
||||
|
||||
# Split on | for OR matching
|
||||
patterns = matcher.split('|')
|
||||
return tool_name in patterns
|
||||
|
||||
def _check_condition(self, condition: Condition, tool_name: str,
|
||||
tool_input: Dict[str, Any], input_data: Dict[str, Any] = None) -> bool:
|
||||
"""Check if a single condition matches.
|
||||
|
||||
Args:
|
||||
condition: Condition to check
|
||||
tool_name: Tool being used
|
||||
tool_input: Tool input dict
|
||||
input_data: Full hook input data (for Stop events, etc.)
|
||||
|
||||
Returns:
|
||||
True if condition matches
|
||||
"""
|
||||
# Extract the field value to check
|
||||
field_value = self._extract_field(condition.field, tool_name, tool_input, input_data)
|
||||
if field_value is None:
|
||||
return False
|
||||
|
||||
# Apply operator
|
||||
operator = condition.operator
|
||||
pattern = condition.pattern
|
||||
|
||||
if operator == 'regex_match':
|
||||
return self._regex_match(pattern, field_value)
|
||||
elif operator == 'contains':
|
||||
return pattern in field_value
|
||||
elif operator == 'equals':
|
||||
return pattern == field_value
|
||||
elif operator == 'not_contains':
|
||||
return pattern not in field_value
|
||||
elif operator == 'starts_with':
|
||||
return field_value.startswith(pattern)
|
||||
elif operator == 'ends_with':
|
||||
return field_value.endswith(pattern)
|
||||
else:
|
||||
# Unknown operator
|
||||
return False
|
||||
|
||||
def _extract_field(self, field: str, tool_name: str,
|
||||
tool_input: Dict[str, Any], input_data: Dict[str, Any] = None) -> Optional[str]:
|
||||
"""Extract field value from tool input or hook input data.
|
||||
|
||||
Args:
|
||||
field: Field name like "command", "new_text", "file_path", "reason", "transcript"
|
||||
tool_name: Tool being used (may be empty for Stop events)
|
||||
tool_input: Tool input dict
|
||||
input_data: Full hook input (for accessing transcript_path, reason, etc.)
|
||||
|
||||
Returns:
|
||||
Field value as string, or None if not found
|
||||
"""
|
||||
# Direct tool_input fields
|
||||
if field in tool_input:
|
||||
value = tool_input[field]
|
||||
if isinstance(value, str):
|
||||
return value
|
||||
return str(value)
|
||||
|
||||
# For Stop events and other non-tool events, check input_data
|
||||
if input_data:
|
||||
# Stop event specific fields
|
||||
if field == 'reason':
|
||||
return input_data.get('reason', '')
|
||||
elif field == 'transcript':
|
||||
# Read transcript file if path provided
|
||||
transcript_path = input_data.get('transcript_path')
|
||||
if transcript_path:
|
||||
try:
|
||||
with open(transcript_path, 'r') as f:
|
||||
return f.read()
|
||||
except FileNotFoundError:
|
||||
print(f"Warning: Transcript file not found: {transcript_path}", file=sys.stderr)
|
||||
return ''
|
||||
except PermissionError:
|
||||
print(f"Warning: Permission denied reading transcript: {transcript_path}", file=sys.stderr)
|
||||
return ''
|
||||
except (IOError, OSError) as e:
|
||||
print(f"Warning: Error reading transcript {transcript_path}: {e}", file=sys.stderr)
|
||||
return ''
|
||||
except UnicodeDecodeError as e:
|
||||
print(f"Warning: Encoding error in transcript {transcript_path}: {e}", file=sys.stderr)
|
||||
return ''
|
||||
elif field == 'user_prompt':
|
||||
# For UserPromptSubmit events
|
||||
return input_data.get('user_prompt', '')
|
||||
|
||||
# Handle special cases by tool type
|
||||
if tool_name == 'Bash':
|
||||
if field == 'command':
|
||||
return tool_input.get('command', '')
|
||||
|
||||
elif tool_name in ['Write', 'Edit']:
|
||||
if field == 'content':
|
||||
# Write uses 'content', Edit has 'new_string'
|
||||
return tool_input.get('content') or tool_input.get('new_string', '')
|
||||
elif field == 'new_text' or field == 'new_string':
|
||||
return tool_input.get('new_string', '')
|
||||
elif field == 'old_text' or field == 'old_string':
|
||||
return tool_input.get('old_string', '')
|
||||
elif field == 'file_path':
|
||||
return tool_input.get('file_path', '')
|
||||
|
||||
elif tool_name == 'MultiEdit':
|
||||
if field == 'file_path':
|
||||
return tool_input.get('file_path', '')
|
||||
elif field in ['new_text', 'content']:
|
||||
# Concatenate all edits
|
||||
edits = tool_input.get('edits', [])
|
||||
return ' '.join(e.get('new_string', '') for e in edits)
|
||||
|
||||
return None
|
||||
|
||||
def _regex_match(self, pattern: str, text: str) -> bool:
|
||||
"""Check if pattern matches text using regex.
|
||||
|
||||
Args:
|
||||
pattern: Regex pattern
|
||||
text: Text to match against
|
||||
|
||||
Returns:
|
||||
True if pattern matches
|
||||
"""
|
||||
try:
|
||||
# Use cached compiled regex (LRU cache with max 128 patterns)
|
||||
regex = compile_regex(pattern)
|
||||
return bool(regex.search(text))
|
||||
|
||||
except re.error as e:
|
||||
print(f"Invalid regex pattern '{pattern}': {e}", file=sys.stderr)
|
||||
return False
|
||||
|
||||
|
||||
# For testing
|
||||
if __name__ == '__main__':
|
||||
from hookify.core.config_loader import Condition, Rule
|
||||
|
||||
# Test rule evaluation
|
||||
rule = Rule(
|
||||
name="test-rm",
|
||||
enabled=True,
|
||||
event="bash",
|
||||
conditions=[
|
||||
Condition(field="command", operator="regex_match", pattern=r"rm\s+-rf")
|
||||
],
|
||||
message="Dangerous rm command!"
|
||||
)
|
||||
|
||||
engine = RuleEngine()
|
||||
|
||||
# Test matching input
|
||||
test_input = {
|
||||
"tool_name": "Bash",
|
||||
"tool_input": {
|
||||
"command": "rm -rf /tmp/test"
|
||||
}
|
||||
}
|
||||
|
||||
result = engine.evaluate_rules([rule], test_input)
|
||||
print("Match result:", result)
|
||||
|
||||
# Test non-matching input
|
||||
test_input2 = {
|
||||
"tool_name": "Bash",
|
||||
"tool_input": {
|
||||
"command": "ls -la"
|
||||
}
|
||||
}
|
||||
|
||||
result2 = engine.evaluate_rules([rule], test_input2)
|
||||
print("Non-match result:", result2)
|
||||
14
plugins/hookify/examples/console-log-warning.local.md
Normal file
14
plugins/hookify/examples/console-log-warning.local.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: warn-console-log
|
||||
enabled: true
|
||||
event: file
|
||||
pattern: console\.log\(
|
||||
action: warn
|
||||
---
|
||||
|
||||
🔍 **Console.log detected**
|
||||
|
||||
You're adding a console.log statement. Please consider:
|
||||
- Is this for debugging or should it be proper logging?
|
||||
- Will this ship to production?
|
||||
- Should this use a logging library instead?
|
||||
14
plugins/hookify/examples/dangerous-rm.local.md
Normal file
14
plugins/hookify/examples/dangerous-rm.local.md
Normal file
@@ -0,0 +1,14 @@
|
||||
---
|
||||
name: block-dangerous-rm
|
||||
enabled: true
|
||||
event: bash
|
||||
pattern: rm\s+-rf
|
||||
action: block
|
||||
---
|
||||
|
||||
⚠️ **Dangerous rm command detected!**
|
||||
|
||||
This command could delete important files. Please:
|
||||
- Verify the path is correct
|
||||
- Consider using a safer approach
|
||||
- Make sure you have backups
|
||||
22
plugins/hookify/examples/require-tests-stop.local.md
Normal file
22
plugins/hookify/examples/require-tests-stop.local.md
Normal file
@@ -0,0 +1,22 @@
|
||||
---
|
||||
name: require-tests-run
|
||||
enabled: false
|
||||
event: stop
|
||||
action: block
|
||||
conditions:
|
||||
- field: transcript
|
||||
operator: not_contains
|
||||
pattern: npm test|pytest|cargo test
|
||||
---
|
||||
|
||||
**Tests not detected in transcript!**
|
||||
|
||||
Before stopping, please run tests to verify your changes work correctly.
|
||||
|
||||
Look for test commands like:
|
||||
- `npm test`
|
||||
- `pytest`
|
||||
- `cargo test`
|
||||
|
||||
**Note:** This rule blocks stopping if no test commands appear in the transcript.
|
||||
Enable this rule only when you want strict test enforcement.
|
||||
18
plugins/hookify/examples/sensitive-files-warning.local.md
Normal file
18
plugins/hookify/examples/sensitive-files-warning.local.md
Normal file
@@ -0,0 +1,18 @@
|
||||
---
|
||||
name: warn-sensitive-files
|
||||
enabled: true
|
||||
event: file
|
||||
action: warn
|
||||
conditions:
|
||||
- field: file_path
|
||||
operator: regex_match
|
||||
pattern: \.env$|\.env\.|credentials|secrets
|
||||
---
|
||||
|
||||
🔐 **Sensitive file detected**
|
||||
|
||||
You're editing a file that may contain sensitive data:
|
||||
- Ensure credentials are not hardcoded
|
||||
- Use environment variables for secrets
|
||||
- Verify this file is in .gitignore
|
||||
- Consider using a secrets manager
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user