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/advanced-plugin.md
Advanced Plugin Example
A complex, enterprise-grade plugin with MCP integration and advanced organization.
Directory Structure
enterprise-devops/
├── .claude-plugin/
│ └── plugin.json
├── commands/
│ ├── ci/
│ │ ├── build.md
│ │ ├── test.md
│ │ └── deploy.md
│ ├── monitoring/
│ │ ├── status.md
│ │ └── logs.md
│ └── admin/
│ ├── configure.md
│ └── manage.md
├── agents/
│ ├── orchestration/
│ │ ├── deployment-orchestrator.md
│ │ └── rollback-manager.md
│ └── specialized/
│ ├── kubernetes-expert.md
│ ├── terraform-expert.md
│ └── security-auditor.md
├── skills/
│ ├── kubernetes-ops/
│ │ ├── SKILL.md
│ │ ├── references/
│ │ │ ├── deployment-patterns.md
│ │ │ ├── troubleshooting.md
│ │ │ └── security.md
│ │ ├── examples/
│ │ │ ├── basic-deployment.yaml
│ │ │ ├── stateful-set.yaml
│ │ │ └── ingress-config.yaml
│ │ └── scripts/
│ │ ├── validate-manifest.sh
│ │ └── health-check.sh
│ ├── terraform-iac/
│ │ ├── SKILL.md
│ │ ├── references/
│ │ │ └── best-practices.md
│ │ └── examples/
│ │ └── module-template/
│ └── ci-cd-pipelines/
│ ├── SKILL.md
│ └── references/
│ └── pipeline-patterns.md
├── hooks/
│ ├── hooks.json
│ └── scripts/
│ ├── security/
│ │ ├── scan-secrets.sh
│ │ ├── validate-permissions.sh
│ │ └── audit-changes.sh
│ ├── quality/
│ │ ├── check-config.sh
│ │ └── verify-tests.sh
│ └── workflow/
│ ├── notify-team.sh
│ └── update-status.sh
├── .mcp.json
├── servers/
│ ├── kubernetes-mcp/
│ │ ├── index.js
│ │ ├── package.json
│ │ └── lib/
│ ├── terraform-mcp/
│ │ ├── main.py
│ │ └── requirements.txt
│ └── github-actions-mcp/
│ ├── server.js
│ └── package.json
├── lib/
│ ├── core/
│ │ ├── logger.js
│ │ ├── config.js
│ │ └── auth.js
│ ├── integrations/
│ │ ├── slack.js
│ │ ├── pagerduty.js
│ │ └── datadog.js
│ └── utils/
│ ├── retry.js
│ └── validation.js
└── config/
├── environments/
│ ├── production.json
│ ├── staging.json
│ └── development.json
└── templates/
├── deployment.yaml
└── service.yamlFile Contents
.claude-plugin/plugin.json
{
"name": "enterprise-devops",
"version": "2.3.1",
"description": "Comprehensive DevOps automation for enterprise CI/CD pipelines, infrastructure management, and monitoring",
"author": {
"name": "DevOps Platform Team",
"email": "[email protected]",
"url": "https://company.com/teams/devops"
},
"homepage": "https://docs.company.com/plugins/devops",
"repository": {
"type": "git",
"url": "https://github.com/company/devops-plugin.git"
},
"license": "Apache-2.0",
"keywords": [
"devops",
"ci-cd",
"kubernetes",
"terraform",
"automation",
"infrastructure",
"deployment",
"monitoring"
],
"commands": [
"./commands/ci",
"./commands/monitoring",
"./commands/admin"
],
"agents": [
"./agents/orchestration",
"./agents/specialized"
],
"hooks": "./hooks/hooks.json",
"mcpServers": "./.mcp.json"
}.mcp.json
{
"mcpServers": {
"kubernetes": {
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/servers/kubernetes-mcp/index.js"],
"env": {
"KUBECONFIG": "${KUBECONFIG}",
"K8S_NAMESPACE": "${K8S_NAMESPACE:-default}"
}
},
"terraform": {
"command": "python",
"args": ["${CLAUDE_PLUGIN_ROOT}/servers/terraform-mcp/main.py"],
"env": {
"TF_STATE_BUCKET": "${TF_STATE_BUCKET}",
"AWS_REGION": "${AWS_REGION}"
}
},
"github-actions": {
"command": "node",
"args": ["${CLAUDE_PLUGIN_ROOT}/servers/github-actions-mcp/server.js"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}",
"GITHUB_ORG": "${GITHUB_ORG}"
}
}
}
}commands/ci/build.md
---
name: build
description: Trigger and monitor CI build pipeline
---
# Build Command
Trigger CI/CD build pipeline and monitor progress in real-time.
## Process
1. **Validation**: Check prerequisites
- Verify branch status
- Check for uncommitted changes
- Validate configuration files
2. **Trigger**: Start build via MCP server
\`\`\`javascript
// Uses github-actions MCP server
const build = await tools.github_actions_trigger_workflow({
workflow: 'build.yml',
ref: currentBranch
})
\`\`\`
3. **Monitor**: Track build progress
- Display real-time logs
- Show test results as they complete
- Alert on failures
4. **Report**: Summarize results
- Build status
- Test coverage
- Performance metrics
- Deploy readiness
## Integration
After successful build:
- Offer to deploy to staging
- Suggest performance optimizations
- Generate deployment checklistagents/orchestration/deployment-orchestrator.md
---
description: Orchestrates complex multi-environment deployments with rollback capabilities and health monitoring
capabilities:
- Plan and execute multi-stage deployments
- Coordinate service dependencies
- Monitor deployment health
- Execute automated rollbacks
- Manage deployment approvals
---
# Deployment Orchestrator Agent
Specialized agent for orchestrating complex deployments across multiple environments.
## Expertise
- **Deployment strategies**: Blue-green, canary, rolling updates
- **Dependency management**: Service startup ordering, dependency injection
- **Health monitoring**: Service health checks, metric validation
- **Rollback automation**: Automatic rollback on failure detection
- **Approval workflows**: Multi-stage approval processes
## Orchestration Process
1. **Planning Phase**
- Analyze deployment requirements
- Identify service dependencies
- Generate deployment plan
- Calculate rollback strategy
2. **Validation Phase**
- Verify environment readiness
- Check resource availability
- Validate configurations
- Run pre-deployment tests
3. **Execution Phase**
- Deploy services in dependency order
- Monitor health after each stage
- Validate metrics and logs
- Proceed to next stage on success
4. **Verification Phase**
- Run smoke tests
- Validate service integration
- Check performance metrics
- Confirm deployment success
5. **Rollback Phase** (if needed)
- Detect failure conditions
- Execute rollback plan
- Restore previous state
- Notify stakeholders
## MCP Integration
Uses multiple MCP servers:
- `kubernetes`: Deploy and manage containers
- `terraform`: Provision infrastructure
- `github-actions`: Trigger deployment pipelines
## Monitoring Integration
Integrates with monitoring tools via lib:
\`\`\`javascript
const { DatadogClient } = require('${CLAUDE_PLUGIN_ROOT}/lib/integrations/datadog')
const metrics = await DatadogClient.getMetrics(service, timeRange)
\`\`\`
## Notification Integration
Sends updates via Slack and PagerDuty:
\`\`\`javascript
const { SlackClient } = require('${CLAUDE_PLUGIN_ROOT}/lib/integrations/slack')
await SlackClient.notify({
channel: '#deployments',
message: 'Deployment started',
metadata: deploymentPlan
})
\`\`\`skills/kubernetes-ops/SKILL.md
---
name: Kubernetes Operations
description: This skill should be used when deploying to Kubernetes, managing K8s resources, troubleshooting cluster issues, configuring ingress/services, scaling deployments, or working with Kubernetes manifests. Provides comprehensive Kubernetes operational knowledge and best practices.
version: 2.0.0
---
# Kubernetes Operations
Comprehensive operational knowledge for managing Kubernetes clusters and workloads.
## Overview
Manage Kubernetes infrastructure effectively through:
- Deployment strategies and patterns
- Resource configuration and optimization
- Troubleshooting and debugging
- Security best practices
- Performance tuning
## Core Concepts
### Resource Management
**Deployments**: Use for stateless applications
- Rolling updates for zero-downtime deployments
- Rollback capabilities for failed deployments
- Replica management for scaling
**StatefulSets**: Use for stateful applications
- Stable network identities
- Persistent storage
- Ordered deployment and scaling
**DaemonSets**: Use for node-level services
- Log collectors
- Monitoring agents
- Network plugins
### Configuration
**ConfigMaps**: Store non-sensitive configuration
- Environment-specific settings
- Application configuration files
- Feature flags
**Secrets**: Store sensitive data
- API keys and tokens
- Database credentials
- TLS certificates
Use external secret management (Vault, AWS Secrets Manager) for production.
### Networking
**Services**: Expose applications internally
- ClusterIP for internal communication
- NodePort for external access (non-production)
- LoadBalancer for external access (production)
**Ingress**: HTTP/HTTPS routing
- Path-based routing
- Host-based routing
- TLS termination
- Load balancing
## Deployment Strategies
### Rolling Update
Default strategy, gradual replacement:
\`\`\`yaml
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 0
\`\`\`
**When to use**: Standard deployments, minor updates
### Recreate
Stop all pods, then create new ones:
\`\`\`yaml
strategy:
type: Recreate
\`\`\`
**When to use**: Stateful apps that can't run multiple versions
### Blue-Green
Run two complete environments, switch traffic:
1. Deploy new version (green)
2. Test green environment
3. Switch traffic to green
4. Keep blue for quick rollback
**When to use**: Critical services, need instant rollback
### Canary
Gradually roll out to subset of users:
1. Deploy canary version (10% traffic)
2. Monitor metrics and errors
3. Increase traffic gradually
4. Complete rollout or rollback
**When to use**: High-risk changes, want gradual validation
## Resource Configuration
### Resource Requests and Limits
Always set for production workloads:
\`\`\`yaml
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
\`\`\`
**Requests**: Guaranteed resources
**Limits**: Maximum allowed resources
### Health Checks
Essential for reliability:
\`\`\`yaml
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
readinessProbe:
httpGet:
path: /ready
port: 8080
initialDelaySeconds: 5
periodSeconds: 5
\`\`\`
**Liveness**: Restart unhealthy pods
**Readiness**: Remove unready pods from service
## Troubleshooting
### Common Issues
1. **Pods not starting**
- Check: `kubectl describe pod <name>`
- Look for: Image pull errors, resource constraints
- Fix: Verify image name, increase resources
2. **Service not reachable**
- Check: `kubectl get svc`, `kubectl get endpoints`
- Look for: No endpoints, wrong selector
- Fix: Verify pod labels match service selector
3. **High memory usage**
- Check: `kubectl top pods`
- Look for: Pods near memory limit
- Fix: Increase limits, optimize application
4. **Frequent restarts**
- Check: `kubectl get pods`, `kubectl logs <name>`
- Look for: Liveness probe failures, OOMKilled
- Fix: Adjust health checks, increase memory
### Debugging Commands
Get pod details:
\`\`\`bash
kubectl describe pod <name>
kubectl logs <name>
kubectl logs <name> --previous # logs from crashed container
\`\`\`
Execute commands in pod:
\`\`\`bash
kubectl exec -it <name> -- /bin/sh
kubectl exec <name> -- env
\`\`\`
Check resource usage:
\`\`\`bash
kubectl top nodes
kubectl top pods
\`\`\`
## Security Best Practices
### Pod Security
- Run as non-root user
- Use read-only root filesystem
- Drop unnecessary capabilities
- Use security contexts
Example:
\`\`\`yaml
securityContext:
runAsNonRoot: true
runAsUser: 1000
readOnlyRootFilesystem: true
capabilities:
drop:
- ALL
\`\`\`
### Network Policies
Restrict pod communication:
\`\`\`yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: api-allow
spec:
podSelector:
matchLabels:
app: api
ingress:
- from:
- podSelector:
matchLabels:
app: frontend
\`\`\`
### Secrets Management
- Never commit secrets to git
- Use external secret managers
- Rotate secrets regularly
- Limit secret access with RBAC
## Performance Optimization
### Resource Tuning
1. **Start conservative**: Set low limits initially
2. **Monitor usage**: Track actual resource consumption
3. **Adjust gradually**: Increase based on metrics
4. **Set appropriate requests**: Match typical usage
5. **Set safe limits**: 2x requests for headroom
### Horizontal Pod Autoscaling
Automatically scale based on metrics:
\`\`\`yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: api-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: api
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 70
\`\`\`
## MCP Server Integration
This skill works with the kubernetes MCP server for operations:
**List pods**:
\`\`\`javascript
const pods = await tools.k8s_list_pods({ namespace: 'default' })
\`\`\`
**Get pod logs**:
\`\`\`javascript
const logs = await tools.k8s_get_logs({ pod: 'api-xyz', container: 'app' })
\`\`\`
**Apply manifests**:
\`\`\`javascript
const result = await tools.k8s_apply_manifest({ file: 'deployment.yaml' })
\`\`\`
## Detailed References
For in-depth information:
- **Deployment patterns**: `references/deployment-patterns.md`
- **Troubleshooting guide**: `references/troubleshooting.md`
- **Security hardening**: `references/security.md`
## Example Manifests
For copy-paste examples:
- **Basic deployment**: `examples/basic-deployment.yaml`
- **StatefulSet**: `examples/stateful-set.yaml`
- **Ingress config**: `examples/ingress-config.yaml`
## Validation Scripts
For manifest validation:
\`\`\`bash
bash ${CLAUDE_PLUGIN_ROOT}/skills/kubernetes-ops/scripts/validate-manifest.sh deployment.yaml
\`\`\`hooks/hooks.json
{
"PreToolUse": [
{
"matcher": "Write|Edit",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/security/scan-secrets.sh",
"timeout": 30
}
]
},
{
"matcher": "Bash",
"hooks": [
{
"type": "prompt",
"prompt": "Evaluate if this bash command is safe for production environment. Check for destructive operations, missing safeguards, and potential security issues. Commands should be idempotent and reversible.",
"timeout": 20
}
]
}
],
"PostToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/workflow/update-status.sh",
"timeout": 15
}
]
}
],
"Stop": [
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/quality/check-config.sh",
"timeout": 45
},
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/workflow/notify-team.sh",
"timeout": 30
}
]
}
],
"SessionStart": [
{
"matcher": ".*",
"hooks": [
{
"type": "command",
"command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/security/validate-permissions.sh",
"timeout": 20
}
]
}
]
}Key Features
Multi-Level Organization
Commands: Organized by function (CI, monitoring, admin) Agents: Separated by role (orchestration vs. specialized) Skills: Rich resources (references, examples, scripts)
MCP Integration
Three custom MCP servers:
Kubernetes: Cluster operations
Terraform: Infrastructure provisioning
GitHub Actions: CI/CD automation
Shared Libraries
Reusable code in lib/:
Core: Common utilities (logging, config, auth)
Integrations: External services (Slack, Datadog)
Utils: Helper functions (retry, validation)
Configuration Management
Environment-specific configs in config/:
Environments: Per-environment settings
Templates: Reusable deployment templates
Security Automation
Multiple security hooks:
Secret scanning before writes
Permission validation on session start
Configuration auditing on completion
Monitoring Integration
Built-in monitoring via lib integrations:
Datadog for metrics
PagerDuty for alerts
Slack for notifications
Use Cases
Multi-environment deployments: Orchestrated rollouts across dev/staging/prod
Infrastructure as code: Terraform automation with state management
CI/CD automation: Build, test, deploy pipelines
Monitoring and observability: Integrated metrics and alerting
Security enforcement: Automated security scanning and validation
Team collaboration: Slack notifications and status updates
When to Use This Pattern
Large-scale enterprise deployments
Multiple environment management
Complex CI/CD workflows
Integrated monitoring requirements
Security-critical infrastructure
Team collaboration needs
Scaling Considerations
Performance: Separate MCP servers for parallel operations
Organization: Multi-level directories for scalability
Maintainability: Shared libraries reduce duplication
Flexibility: Environment configs enable customization
Security: Layered security hooks and validation
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