claude-opus-4-5-migrat…
Migrate prompts and code from Claude Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5. Use when the user wants to update their…
This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDE_PLUGIN_ROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs
Claude Code
$ npx -y skills add LING71671/Open-ClaudeCode --skill plugin-structure --agent claude-code
Codex
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a codex -y
Cursor
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a cursor -y
Gemini CLI
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a gemini-cli -y
GitHub Copilot
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a github-copilot -y
OpenCode
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a opencode -y
Windsurf
$ npx skills add LING71671/Open-ClaudeCode --skill plugin-structure -a windsurf -y
name: Plugin Structure
description: This skill should be used when the user asks to "create a plugin", "scaffold a plugin", "understand plugin structure", "organize plugin components", "set up plugin.json", "use ${CLAUDE_PLUGIN_ROOT}", "add commands/agents/skills/hooks", "configure auto-discovery", or needs guidance on plugin directory layout, manifest configuration, component organization, file naming conventions, or Claude Code plugin architecture best practices.
version: 0.1.0Claude 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:**
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 utilities
**Critical rules:**
1. **Manifest location**: The `plugin.json` manifest MUST be in `.claude-plugin/` directory 2. **Component locations**: All component directories (commands, agents, skills, hooks) MUST be at plugin root level, NOT nested inside `.claude-plugin/` 3. **Optional components**: Only create directories for components the plugin actually uses 4. **Naming convention**: Use kebab-case for all directory and file names
The manifest defines plugin metadata and configuration. Located at `.claude-plugin/plugin.json`:
{
"name": "plugin-name"
}**Name requirements:**
{
"name": "plugin-name",
"version": "1.0.0",
"description": "Brief explanation of plugin purpose",
"author": {
"name": "Author Name",
"email": "author@example.com",
"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
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:**
**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 command
**File format**:
--- name: command-name description: Command description --- Command implementation instructions...
**Usage**: Commands integrate as native slash commands in Claude Code
**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.md
**File 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
**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.sql**SKILL.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
**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 scriptMigrate prompts and code from Claude Sonnet 4.0, Sonnet 4.5, or Opus 4.1 to Opus 4.5. Use when the user wants to update their…
Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web…
Security audit workflow for OPC code, providers, plugins, Electron surfaces, local HTTP bridges, filesystem access, and command…
Update or audit OPC documentation after code changes. Use when behavior, setup, CLI flags, desktop workflow, provider support, or…
Systematic root-cause debugging for OPC work. Use when there is a bug, crash, regression, failing command, flaky behavior,…
Read-only QA report for an OPC desktop flow, CLI command, local URL, staging URL, or documented user journey. Does not modify…
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
Ask which skill or flow fits your situation. A router over the skills in this repo.