Plugin Structure
AnthropicOfficialPublished by Anthropic
- Skill
- Guidelines
- Agent tooling
- Apache-2.0
- No issues found
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides the architectural blueprint for creating Claude Code plugins. It defines the mandatory directory structure, manifest configuration requirements, and component organization patterns (commands, agents, skills, hooks, and MCP servers) necessary for seamless integration and automatic discovery within the Claude Code environment. It emphasizes the use of portable path references and consistent naming conventions to ensure plugin maintainability and cross-system compatibility.
What it does
- Defines the required .claude-plugin/plugin.json manifest structure
- Outlines the standard directory layout for commands, agents, skills, and hooks
- Explains the auto-discovery mechanism for plugin components
- Provides guidance on using ${CLAUDE_PLUGIN_ROOT} for portable file references
- Details naming conventions and best practices for plugin organization
- Offers patterns for scaling plugins from simple commands to complex workflows
When to use it
- When starting the development of a new Claude Code plugin
- When organizing plugin components to ensure they are correctly discovered
- When configuring plugin manifests or custom component paths
- When troubleshooting issues with component loading or path resolution
- When seeking best practices for structuring complex plugin architectures
Advantages
- Ensures compatibility with Claude Code's automatic discovery system
- Promotes consistent, maintainable plugin structures
- Prevents hardcoded path errors using environment-aware references
- Facilitates modular development through clear component separation
Usage examples
- “How should I structure my new Claude Code plugin?”
- The agent provides the standard directory tree, including the .claude-plugin/ directory, and explains where to place commands, agents, and skills for automatic discovery.
- “How do I reference a script inside my plugin safely?”
- The agent explains the use of the ${CLAUDE_PLUGIN_ROOT} variable to ensure paths remain valid regardless of where the plugin is installed.
- “What are the requirements for the plugin.json manifest?”
- The agent lists the required fields like 'name', explains the kebab-case naming convention, and shows how to add optional metadata and custom component paths.
- “How do I add a custom command to my plugin?”
- The agent guides you to create a markdown file with YAML frontmatter in the commands/ directory and explains how it will be automatically registered as a slash command.
Install
Download the skill as a ZIP:
https://autogineer.com/agent-skills/anthropics/plugin-structure/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip plugin-structure.zip -d .agents/skills
Documentation by Anthropic
Plugin Structure for Claude Code
Overview
Claude Code plugins follow a standardized directory structure with automatic component discovery. Understanding this structure enables creating well-organized, maintainable plugins that integrate seamlessly with Claude Code.
Key concepts:
Conventional directory layout for automatic discovery
Manifest-driven configuration in
.claude-plugin/plugin.jsonComponent-based organization (commands, agents, skills, hooks)
Portable path references using
${CLAUDE_PLUGIN_ROOT}Explicit vs. auto-discovered component loading
Directory Structure
Every Claude Code plugin follows this organizational pattern:
plugin-name/
├── .claude-plugin/
│ └── plugin.json # Required: Plugin manifest
├── commands/ # Slash commands (.md files)
├── agents/ # Subagent definitions (.md files)
├── skills/ # Agent skills (subdirectories)
│ └── skill-name/
│ └── SKILL.md # Required for each skill
├── hooks/
│ └── hooks.json # Event handler configuration
├── .mcp.json # MCP server definitions
└── scripts/ # Helper scripts and utilitiesCritical rules:
Manifest location: The
plugin.jsonmanifest MUST be in.claude-plugin/directoryComponent locations: All component directories (commands, agents, skills, hooks) MUST be at plugin root level, NOT nested inside
.claude-plugin/Optional components: Only create directories for components the plugin actually uses
Naming convention: Use kebab-case for all directory and file names
Plugin Manifest (plugin.json)
The manifest defines plugin metadata and configuration. Located at .claude-plugin/plugin.json:
Required Fields
{
"name": "plugin-name"
}Name requirements:
Use kebab-case format (lowercase with hyphens)
Must be unique across installed plugins
No spaces or special characters
Example:
code-review-assistant,test-runner,api-docs
Recommended Metadata
{
"name": "plugin-name",
"version": "1.0.0",
"description": "Brief explanation of plugin purpose",
"author": {
"name": "Author Name",
"email": "[email protected]",
"url": "https://example.com"
},
"homepage": "https://docs.example.com",
"repository": "https://github.com/user/plugin-name",
"license": "MIT",
"keywords": ["testing", "automation", "ci-cd"]
}Version format: Follow semantic versioning (MAJOR.MINOR.PATCH) Keywords: Use for plugin discovery and categorization
Component Path Configuration
Specify custom paths for components (supplements default directories):
{
"name": "plugin-name",
"commands": "./custom-commands",
"agents": ["./agents", "./specialized-agents"],
"hooks": "./config/hooks.json",
"mcpServers": "./.mcp.json"
}Important: Custom paths supplement defaults—they don't replace them. Components in both default directories and custom paths will load.
Path rules:
Must be relative to plugin root
Must start with
./Cannot use absolute paths
Support arrays for multiple locations
Component Organization
Commands
Location: commands/ directory
Format: Markdown files with YAML frontmatter
Auto-discovery: All .md files in commands/ load automatically
Example structure:
commands/
├── review.md # /review command
├── test.md # /test command
└── deploy.md # /deploy commandFile format:
---
name: command-name
description: Command description
---
Command implementation instructions...Usage: Commands integrate as native slash commands in Claude Code
Agents
Location: agents/ directory
Format: Markdown files with YAML frontmatter
Auto-discovery: All .md files in agents/ load automatically
Example structure:
agents/
├── code-reviewer.md
├── test-generator.md
└── refactorer.mdFile format:
---
description: Agent role and expertise
capabilities:
- Specific task 1
- Specific task 2
---
Detailed agent instructions and knowledge...Usage: Users can invoke agents manually, or Claude Code selects them automatically based on task context
Skills
Location: skills/ directory with subdirectories per skill
Format: Each skill in its own directory with SKILL.md file
Auto-discovery: All SKILL.md files in skill subdirectories load automatically
Example structure:
skills/
├── api-testing/
│ ├── SKILL.md
│ ├── scripts/
│ │ └── test-runner.py
│ └── references/
│ └── api-spec.md
└── database-migrations/
├── SKILL.md
└── examples/
└── migration-template.sqlSKILL.md format:
---
name: Skill Name
description: When to use this skill
version: 1.0.0
---
Skill instructions and guidance...Supporting files: Skills can include scripts, references, examples, or assets in subdirectories
Usage: Claude Code autonomously activates skills based on task context matching the description
Hooks
Location: hooks/hooks.json or inline in plugin.json
Format: JSON configuration defining event handlers
Registration: Hooks register automatically when plugin enables
Example structure:
hooks/
├── hooks.json # Hook configuration
└── scripts/
├── validate.sh # Hook script
└── check-style.sh # Hook scriptConfiguration format:
{
"PreToolUse": [{
"matcher": "Write|Edit",
"hooks": [{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/validate.sh",
"timeout": 30
}]
}]
}Available events: PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification
Usage: Hooks execute automatically in response to Claude Code events
MCP Servers
Location: .mcp.json at plugin root or inline in plugin.json
Format: JSON configuration for MCP server definitions
Auto-start: Servers start automatically when plugin enables
Example format:
{
"mcpServers": {
"server-name": {
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/servers/server.js"],
"env": {
"API_KEY": "${API_KEY}"
}
}
}
}Usage: MCP servers integrate seamlessly with Claude Code's tool system
Portable Path References
${CLAUDE_PLUGIN_ROOT}
Use ${CLAUDE_PLUGIN_ROOT} environment variable for all intra-plugin path references:
{
"command": "bash ${CLAUDE_PLUGIN_ROOT}/scripts/run.sh"
}Why it matters: Plugins install in different locations depending on:
User installation method (marketplace, local, npm)
Operating system conventions
User preferences
Where to use it:
Hook command paths
MCP server command arguments
Script execution references
Resource file paths
Never use:
Hardcoded absolute paths (
/Users/name/plugins/...)Relative paths from working directory (
./scripts/...in commands)Home directory shortcuts (
~/plugins/...)
Path Resolution Rules
In manifest JSON fields (hooks, MCP servers):
"command": "${CLAUDE_PLUGIN_ROOT}/scripts/tool.sh"In component files (commands, agents, skills):
Reference scripts at: ${CLAUDE_PLUGIN_ROOT}/scripts/helper.pyIn executed scripts:
#!/bin/bash
# ${CLAUDE_PLUGIN_ROOT} available as environment variable
source "${CLAUDE_PLUGIN_ROOT}/lib/common.sh"File Naming Conventions
Component Files
Commands: Use kebab-case .md files
code-review.md→/code-reviewrun-tests.md→/run-testsapi-docs.md→/api-docs
Agents: Use kebab-case .md files describing role
test-generator.mdcode-reviewer.mdperformance-analyzer.md
Skills: Use kebab-case directory names
api-testing/database-migrations/error-handling/
Supporting Files
Scripts: Use descriptive kebab-case names with appropriate extensions
validate-input.shgenerate-report.pyprocess-data.js
Documentation: Use kebab-case markdown files
api-reference.mdmigration-guide.mdbest-practices.md
Configuration: Use standard names
hooks.json.mcp.jsonplugin.json
Auto-Discovery Mechanism
Claude Code automatically discovers and loads components:
Plugin manifest: Reads
.claude-plugin/plugin.jsonwhen plugin enablesCommands: Scans
commands/directory for.mdfilesAgents: Scans
agents/directory for.mdfilesSkills: Scans
skills/for subdirectories containingSKILL.mdHooks: Loads configuration from
hooks/hooks.jsonor manifestMCP servers: Loads configuration from
.mcp.jsonor manifest
Discovery timing:
Plugin installation: Components register with Claude Code
Plugin enable: Components become available for use
No restart required: Changes take effect on next Claude Code session
Override behavior: Custom paths in plugin.json supplement (not replace) default directories
Best Practices
Organization
Logical grouping: Group related components together
Put test-related commands, agents, and skills together
Create subdirectories in
scripts/for different purposes
Minimal manifest: Keep
plugin.jsonleanOnly specify custom paths when necessary
Rely on auto-discovery for standard layouts
Use inline configuration only for simple cases
Documentation: Include README files
Plugin root: Overall purpose and usage
Component directories: Specific guidance
Script directories: Usage and requirements
Naming
Consistency: Use consistent naming across components
If command is
test-runner, name related agenttest-runner-agentMatch skill directory names to their purpose
Clarity: Use descriptive names that indicate purpose
Good:
api-integration-testing/,code-quality-checker.mdAvoid:
utils/,misc.md,temp.sh
Length: Balance brevity with clarity
Commands: 2-3 words (
review-pr,run-ci)Agents: Describe role clearly (
code-reviewer,test-generator)Skills: Topic-focused (
error-handling,api-design)
Portability
Always use ${CLAUDE_PLUGIN_ROOT}: Never hardcode paths
Test on multiple systems: Verify on macOS, Linux, Windows
Document dependencies: List required tools and versions
Avoid system-specific features: Use portable bash/Python constructs
Maintenance
Version consistently: Update version in plugin.json for releases
Deprecate gracefully: Mark old components clearly before removal
Document breaking changes: Note changes affecting existing users
Test thoroughly: Verify all components work after changes
Common Patterns
Minimal Plugin
Single command with no dependencies:
my-plugin/
├── .claude-plugin/
│ └── plugin.json # Just name field
└── commands/
└── hello.md # Single commandFull-Featured Plugin
Complete plugin with all component types:
my-plugin/
├── .claude-plugin/
│ └── plugin.json
├── commands/ # User-facing commands
├── agents/ # Specialized subagents
├── skills/ # Auto-activating skills
├── hooks/ # Event handlers
│ ├── hooks.json
│ └── scripts/
├── .mcp.json # External integrations
└── scripts/ # Shared utilitiesSkill-Focused Plugin
Plugin providing only skills:
my-plugin/
├── .claude-plugin/
│ └── plugin.json
└── skills/
├── skill-one/
│ └── SKILL.md
└── skill-two/
└── SKILL.mdTroubleshooting
Component not loading:
Verify file is in correct directory with correct extension
Check YAML frontmatter syntax (commands, agents, skills)
Ensure skill has
SKILL.md(notREADME.mdor other name)Confirm plugin is enabled in Claude Code settings
Path resolution errors:
Replace all hardcoded paths with
${CLAUDE_PLUGIN_ROOT}Verify paths are relative and start with
./in manifestCheck that referenced files exist at specified paths
Test with
echo $CLAUDE_PLUGIN_ROOTin hook scripts
Auto-discovery not working:
Confirm directories are at plugin root (not in
.claude-plugin/)Check file naming follows conventions (kebab-case, correct extensions)
Verify custom paths in manifest are correct
Restart Claude Code to reload plugin configuration
Conflicts between plugins:
Use unique, descriptive component names
Namespace commands with plugin name if needed
Document potential conflicts in plugin README
Consider command prefixes for related functionality
For detailed examples and advanced patterns, see files in references/ and examples/ directories.
Files
- ATTRIBUTION.mdAdded by AutoGineer970 B
- LICENSELicence file added by AutoGineer11.1 KiB
- README.md3.1 KiB
- SKILL.md13.5 KiB
- examples/advanced-plugin.md18.3 KiB
- examples/minimal-plugin.md1.7 KiB
- examples/standard-plugin.md13.0 KiB
- references/component-patterns.md11.8 KiB
- references/manifest-reference.md11.8 KiB
examples/standard-plugin.md
Standard Plugin Example
A well-structured plugin with commands, agents, and skills.
Directory Structure
code-quality/
├── .claude-plugin/
│ └── plugin.json
├── commands/
│ ├── lint.md
│ ├── test.md
│ └── review.md
├── agents/
│ ├── code-reviewer.md
│ └── test-generator.md
├── skills/
│ ├── code-standards/
│ │ ├── SKILL.md
│ │ └── references/
│ │ └── style-guide.md
│ └── testing-patterns/
│ ├── SKILL.md
│ └── examples/
│ ├── unit-test.js
│ └── integration-test.js
├── hooks/
│ ├── hooks.json
│ └── scripts/
│ └── validate-commit.sh
└── scripts/
├── run-linter.sh
└── generate-report.pyFile Contents
.claude-plugin/plugin.json
{
"name": "code-quality",
"version": "1.0.0",
"description": "Comprehensive code quality tools including linting, testing, and review automation",
"author": {
"name": "Quality Team",
"email": "[email protected]"
},
"homepage": "https://docs.example.com/plugins/code-quality",
"repository": "https://github.com/example/code-quality-plugin",
"license": "MIT",
"keywords": ["code-quality", "linting", "testing", "code-review", "automation"]
}commands/lint.md
---
name: lint
description: Run linting checks on the codebase
---
# Lint Command
Run comprehensive linting checks on the project codebase.
## Process
1. Detect project type and installed linters
2. Run appropriate linters (ESLint, Pylint, RuboCop, etc.)
3. Collect and format results
4. Report issues with file locations and severity
## Implementation
Execute the linting script:
\`\`\`bash
bash ${CLAUDE_PLUGIN_ROOT}/scripts/run-linter.sh
\`\`\`
Parse the output and present issues organized by:
- Critical issues (must fix)
- Warnings (should fix)
- Style suggestions (optional)
For each issue, show:
- File path and line number
- Issue description
- Suggested fix (if available)commands/test.md
---
name: test
description: Run test suite with coverage reporting
---
# Test Command
Execute the project test suite and generate coverage reports.
## Process
1. Identify test framework (Jest, pytest, RSpec, etc.)
2. Run all tests
3. Generate coverage report
4. Identify untested code
## Output
Present results in structured format:
- Test summary (passed/failed/skipped)
- Coverage percentage by file
- Critical untested areas
- Failed test details
## Integration
After test completion, offer to:
- Fix failing tests
- Generate tests for untested code (using test-generator agent)
- Update documentation based on test changesagents/code-reviewer.md
---
description: Expert code reviewer specializing in identifying bugs, security issues, and improvement opportunities
capabilities:
- Analyze code for potential bugs and logic errors
- Identify security vulnerabilities
- Suggest performance improvements
- Ensure code follows project standards
- Review test coverage adequacy
---
# Code Reviewer Agent
Specialized agent for comprehensive code review.
## Expertise
- **Bug detection**: Logic errors, edge cases, error handling
- **Security analysis**: Injection vulnerabilities, authentication issues, data exposure
- **Performance**: Algorithm efficiency, resource usage, optimization opportunities
- **Standards compliance**: Style guide adherence, naming conventions, documentation
- **Test coverage**: Adequacy of test cases, missing scenarios
## Review Process
1. **Initial scan**: Quick pass for obvious issues
2. **Deep analysis**: Line-by-line review of changed code
3. **Context evaluation**: Check impact on related code
4. **Best practices**: Compare against project and language standards
5. **Recommendations**: Prioritized list of improvements
## Integration with Skills
Automatically loads `code-standards` skill for project-specific guidelines.
## Output Format
For each file reviewed:
- Overall assessment
- Critical issues (must fix before merge)
- Important issues (should fix)
- Suggestions (nice to have)
- Positive feedback (what was done well)agents/test-generator.md
---
description: Generates comprehensive test suites from code analysis
capabilities:
- Analyze code structure and logic flow
- Generate unit tests for functions and methods
- Create integration tests for modules
- Design edge case and error condition tests
- Suggest test fixtures and mocks
---
# Test Generator Agent
Specialized agent for generating comprehensive test suites.
## Expertise
- **Unit testing**: Individual function/method tests
- **Integration testing**: Module interaction tests
- **Edge cases**: Boundary conditions, error paths
- **Test organization**: Proper test structure and naming
- **Mocking**: Appropriate use of mocks and stubs
## Generation Process
1. **Code analysis**: Understand function purpose and logic
2. **Path identification**: Map all execution paths
3. **Input design**: Create test inputs covering all paths
4. **Assertion design**: Define expected outputs
5. **Test generation**: Write tests in project's framework
## Integration with Skills
Automatically loads `testing-patterns` skill for project-specific test conventions.
## Test Quality
Generated tests include:
- Happy path scenarios
- Edge cases and boundary conditions
- Error handling verification
- Mock data for external dependencies
- Clear test descriptionsskills/code-standards/SKILL.md
---
name: Code Standards
description: This skill should be used when reviewing code, enforcing style guidelines, checking naming conventions, or ensuring code quality standards. Provides project-specific coding standards and best practices.
version: 1.0.0
---
# Code Standards
Comprehensive coding standards and best practices for maintaining code quality.
## Overview
Enforce consistent code quality through standardized conventions for:
- Code style and formatting
- Naming conventions
- Documentation requirements
- Error handling patterns
- Security practices
## Style Guidelines
### Formatting
- **Indentation**: 2 spaces (JavaScript/TypeScript), 4 spaces (Python)
- **Line length**: Maximum 100 characters
- **Braces**: Same line for opening brace (K&R style)
- **Whitespace**: Space after commas, around operators
### Naming Conventions
- **Variables**: camelCase for JavaScript, snake_case for Python
- **Functions**: camelCase, descriptive verb-noun pairs
- **Classes**: PascalCase
- **Constants**: UPPER_SNAKE_CASE
- **Files**: kebab-case for modules
## Documentation Requirements
### Function Documentation
Every function must include:
- Purpose description
- Parameter descriptions with types
- Return value description with type
- Example usage (for public functions)
### Module Documentation
Every module must include:
- Module purpose
- Public API overview
- Usage examples
- Dependencies
## Error Handling
### Required Practices
- Never swallow errors silently
- Always log errors with context
- Use specific error types
- Provide actionable error messages
- Clean up resources in finally blocks
### Example Pattern
\`\`\`javascript
async function processData(data) {
try {
const result = await transform(data)
return result
} catch (error) {
logger.error('Data processing failed', {
data: sanitize(data),
error: error.message,
stack: error.stack
})
throw new DataProcessingError('Failed to process data', { cause: error })
}
}
\`\`\`
## Security Practices
- Validate all external input
- Sanitize data before output
- Use parameterized queries
- Never log sensitive information
- Keep dependencies updated
## Detailed Guidelines
For comprehensive style guides by language, see:
- `references/style-guide.md`skills/code-standards/references/style-guide.md
# Comprehensive Style Guide
Detailed style guidelines for all supported languages.
## JavaScript/TypeScript
### Variable Declarations
Use `const` by default, `let` when reassignment needed, never `var`:
\`\`\`javascript
// Good
const MAX_RETRIES = 3
let currentTry = 0
// Bad
var MAX_RETRIES = 3
\`\`\`
### Function Declarations
Use function expressions for consistency:
\`\`\`javascript
// Good
const calculateTotal = (items) => {
return items.reduce((sum, item) => sum + item.price, 0)
}
// Bad (inconsistent style)
function calculateTotal(items) {
return items.reduce((sum, item) => sum + item.price, 0)
}
\`\`\`
### Async/Await
Prefer async/await over promise chains:
\`\`\`javascript
// Good
async function fetchUserData(userId) {
const user = await db.getUser(userId)
const orders = await db.getOrders(user.id)
return { user, orders }
}
// Bad
function fetchUserData(userId) {
return db.getUser(userId)
.then(user => db.getOrders(user.id)
.then(orders => ({ user, orders })))
}
\`\`\`
## Python
### Import Organization
Order imports: standard library, third-party, local:
\`\`\`python
# Good
import os
import sys
import numpy as np
import pandas as pd
from app.models import User
from app.utils import helper
# Bad - mixed order
from app.models import User
import numpy as np
import os
\`\`\`
### Type Hints
Use type hints for all function signatures:
\`\`\`python
# Good
def calculate_average(numbers: list[float]) -> float:
return sum(numbers) / len(numbers)
# Bad
def calculate_average(numbers):
return sum(numbers) / len(numbers)
\`\`\`
## Additional Languages
See language-specific guides for:
- Go: `references/go-style.md`
- Rust: `references/rust-style.md`
- Ruby: `references/ruby-style.md`hooks/hooks.json
{
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "prompt",
"prompt": "Before modifying code, verify it meets our coding standards from the code-standards skill. Check formatting, naming conventions, and documentation. If standards aren't met, suggest improvements.",
"timeout": 30
}
]
}
],
"Stop": [
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/validate-commit.sh",
"timeout": 45
}
]
}
]
}hooks/scripts/validate-commit.sh
#!/bin/bash
# Validate code quality before task completion
set -e
# Check if there are any uncommitted changes
if [[ -z $(git status -s) ]]; then
echo '{"systemMessage": "No changes to validate. Task complete."}'
exit 0
fi
# Run linter on changed files
CHANGED_FILES=$(git diff --name-only --cached | grep -E '\.(js|ts|py)$' || true)
if [[ -z "$CHANGED_FILES" ]]; then
echo '{"systemMessage": "No code files changed. Validation passed."}'
exit 0
fi
# Run appropriate linters
ISSUES=0
for file in $CHANGED_FILES; do
case "$file" in
*.js|*.ts)
if ! npx eslint "$file" --quiet; then
ISSUES=$((ISSUES + 1))
fi
;;
*.py)
if ! python -m pylint "$file" --errors-only; then
ISSUES=$((ISSUES + 1))
fi
;;
esac
done
if [[ $ISSUES -gt 0 ]]; then
echo "{\"systemMessage\": \"Found $ISSUES code quality issues. Please fix before completing.\"}"
exit 1
fi
echo '{"systemMessage": "Code quality checks passed. Ready to commit."}'
exit 0Usage Examples
Running Commands
$ claude
> /lint
Running linter checks...
Critical Issues (2):
src/api/users.js:45 - SQL injection vulnerability
src/utils/helpers.js:12 - Unhandled promise rejection
Warnings (5):
src/components/Button.tsx:23 - Missing PropTypes
...
Style Suggestions (8):
src/index.js:1 - Use const instead of let
...
> /test
Running test suite...
Test Results:
✓ 245 passed
✗ 3 failed
○ 2 skipped
Coverage: 87.3%
Untested Files:
src/utils/cache.js - 0% coverage
src/api/webhooks.js - 23% coverage
Failed Tests:
1. User API › GET /users › should handle pagination
Expected 200, received 500
...Using Agents
> Review the changes in src/api/users.js
[code-reviewer agent selected automatically]
Code Review: src/api/users.js
Critical Issues:
1. Line 45: SQL injection vulnerability
- Using string concatenation for SQL query
- Replace with parameterized query
- Priority: CRITICAL
2. Line 67: Missing error handling
- Database query without try/catch
- Could crash server on DB error
- Priority: HIGH
Suggestions:
1. Line 23: Consider caching user data
- Frequent DB queries for same users
- Add Redis caching layer
- Priority: MEDIUMKey Points
Complete manifest: All recommended metadata fields
Multiple components: Commands, agents, skills, hooks
Rich skills: References and examples for detailed information
Automation: Hooks enforce standards automatically
Integration: Components work together cohesively
When to Use This Pattern
Production plugins for distribution
Team collaboration tools
Plugins requiring consistency enforcement
Complex workflows with multiple entry points
Requirements and compatibility
Written for: Claude Code, Claude apps
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Needs an MCP server, Needs an API key, Needs Node.js
Security
No issues found by our static scan· No issues found
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Anthropic
- Publisher
- Anthropic (Official)
- Source
- anthropics/claude-plugins-official · plugins/plugin-dev/skills/plugin-structure · commit 0412be7
- Licence
- Apache License 2.0 (redistribution allowed)
- LICENSE (added by AutoGineer from plugins/plugin-dev/LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Anthropic or Anthropic.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download plugin-structure.zip