Agent skill
component-patterns
Decide which plugin component type to use and how to organize components at scale. Covers the component lifecycle (discovery and activation phases), decision framework for choosing between commands, skills, agents, hooks, and MCP servers, and organization patterns for each component type. Use when asking "which component type should I use", "command vs skill vs agent", "when to use a hook vs MCP server", "component lifecycle", "how to organize plugin components", "plugin structure patterns", or "scale a plugin with many components".
Install this agent skill to your Project
npx add-skill https://github.com/Jamie-BitFlight/claude_skills/tree/main/plugins/plugin-creator/skills/component-patterns
SKILL.md
Component Lifecycle
Every plugin component goes through two phases — discovery at startup and activation at runtime.
Discovery Phase
When Claude Code starts, it processes each enabled plugin:
- Scan enabled plugins — read
.claude-plugin/plugin.json - Discover components — search default and custom paths
- Parse definitions — read YAML frontmatter and configuration files
- Register components — make available to Claude Code
- Initialize — start MCP servers, register hooks
Discovery happens once during Claude Code initialization, not continuously. Components added after startup require a session restart to become available.
Activation Phase
Each component type activates through a different mechanism:
flowchart LR
User["User action"] --> Cmd["Command — user types /command"]
Context["Task context"] --> Skill["Skill — description matches task"]
Context --> Agent["Agent — capabilities match task"]
Event["System event"] --> Hook["Hook — event matches registration"]
ToolCall["Tool call"] --> MCP["MCP Server — capability matches call"]
SOURCE: Adapted from ../claude-plugins-official/plugins/plugin-dev/skills/plugin-structure/references/component-patterns.md lines 1-27
Component Selection Framework
Use this decision tree to select the right component type for a given need.
flowchart TD
Start(["What do you need<br>to add to your plugin?"]) --> Q1{"Does it need to<br>intercept or validate<br>tool calls or events?"}
Q1 -->|"Yes — gate writes,<br>enforce policies,<br>inject context on events"| Hook["Use a Hook<br>Create with /plugin-creator:hook-creator"]
Q1 -->|No| Q2{"Does it provide<br>external tool access<br>via API or process?"}
Q2 -->|"Yes — database queries,<br>API calls, file processing<br>via external process"| MCP["Use an MCP Server<br>Create with /fastmcp-creator"]
Q2 -->|No| Q3{"Does it need its own<br>identity, tools, model,<br>or permission scope?"}
Q3 -->|"Yes — specialized worker<br>with restricted tools<br>or different model"| Agent["Use an Agent<br>Create with /plugin-creator:agent-creator"]
Q3 -->|No| Q4{"Is it domain knowledge,<br>a workflow, or a<br>procedural guide?"}
Q4 -->|"Yes — reference material,<br>multi-step process,<br>best practices"| Skill["Use a Skill<br>Create with /plugin-creator:skill-creator"]
Q4 -->|"No — simple user-triggered<br>action with bash execution"| Command["Use a Command (legacy)<br>See /plugin-creator:command-development"]
Hook --> HookNote["Events — PreToolUse, PostToolUse,<br>Stop, Notification, SubagentStop"]
MCP --> MCPNote["Transports — stdio, SSE,<br>HTTP, WebSocket"]
Agent --> AgentNote["Frontmatter — name, description,<br>tools, model, skills, hooks"]
Skill --> SkillNote["Progressive disclosure —<br>SKILL.md + references/"]
Command --> CmdNote["Legacy format —<br>prefer skills for new work"]
Quick Reference
flowchart TD
subgraph Components["Component Capabilities"]
direction LR
H["Hook"]
M["MCP Server"]
A["Agent"]
S["Skill"]
C["Command"]
end
subgraph Traits["Key Differentiators"]
direction LR
H --- HT["Intercepts events and tool calls<br>Can block or modify operations<br>Runs on system events"]
M --- MT["Provides tools via external process<br>Persistent server with its own state<br>Accessed through tool calls"]
A --- AT["Has its own identity and tool scope<br>Can use a different model<br>Selected by capability matching"]
S --- ST["Provides knowledge and workflows<br>Activated by context matching<br>Progressive disclosure via references/"]
C --- CT["User-triggered via /name<br>Can execute bash commands<br>Legacy — skills preferred for new work"]
end
SOURCE: Decision framework derived from component capabilities documented in ../claude-plugins-official/plugins/plugin-dev/skills/plugin-structure/references/component-patterns.md and /plugin-creator:claude-plugins-reference-2026
Organization Patterns by Component Type
For detailed organization patterns (directory structures, scaling strategies, when-to-use guidance) for each component type, see component organization reference.
Summary of available patterns:
flowchart TD
subgraph Commands["Command Patterns"]
CF["Flat — up to 15 commands"]
CC["Categorized — 15+ with functional groups"]
CH["Hierarchical — 20+ with nested structure"]
end
subgraph Agents["Agent Patterns"]
AR["Role-based — distinct non-overlapping roles"]
AC["Capability-based — technology or domain expertise"]
AW["Workflow-based — pipeline stage specialists"]
end
subgraph Skills["Skill Patterns"]
ST["Topic-based — knowledge and reference content"]
SL["Tool-based — specific tool or technology expertise"]
SW["Workflow-based — multi-step process automation"]
SR["Rich resources — SKILL.md + references/ + scripts/ + assets/"]
end
subgraph Hooks["Hook Patterns"]
HM["Monolithic — single hooks.json, up to 10 hooks"]
HE["Event-based — separate config per event type"]
HP["Purpose-based — grouped by security, quality, workflow"]
end
Cross-Component Patterns
When plugins grow beyond simple single-component designs, these patterns help manage complexity.
Shared Resources
Components can share common utilities via a lib/ directory at the plugin root:
plugin/
├── commands/
│ └── test.md # references lib/test-utils.sh
├── agents/
│ └── tester.md # references lib/test-utils.sh
├── hooks/
│ └── scripts/
│ └── pre-test.sh # sources lib/test-utils.sh
└── lib/
├── test-utils.sh
└── deploy-utils.sh
Access shared resources via ${CLAUDE_PLUGIN_ROOT}/lib/ in scripts.
Layered Architecture
Separate concerns into layers for large plugins (100+ files):
plugin/
├── commands/ # User interface layer
├── agents/ # Orchestration layer
├── skills/ # Knowledge layer
└── lib/
├── core/ # Core business logic
├── integrations/ # External service adapters
└── utils/ # Shared helper functions
Modular Extensions
Optional features as self-contained modules within the plugin:
plugin/
├── .claude-plugin/
│ └── plugin.json
├── core/
│ ├── commands/
│ └── agents/
└── extensions/
├── extension-a/
│ ├── commands/
│ └── agents/
└── extension-b/
├── commands/
└── agents/
Register extension paths in plugin.json under commands and agents arrays. Note that listing paths explicitly overrides auto-discovery — all paths must be listed or unlisted components become invisible.
SOURCE: Cross-component patterns adapted from ../claude-plugins-official/plugins/plugin-dev/skills/plugin-structure/references/component-patterns.md lines 448-535
Best Practices
- Start simple — use flat structures, reorganize when growth demands it
- Consistent naming — match file names to component purpose using full descriptive words
- Minimize nesting — deep directory structures slow discovery and increase configuration burden
- Use defaults — rely on auto-discovery paths (
commands/,agents/,skills/) before adding custom paths toplugin.json - Separate concerns — do not mix unrelated functionality in the same component
- Plan for growth — choose structures that scale without requiring full reorganization
Related Skills
- For creating hooks —
/plugin-creator:hook-creator - For creating agents —
/plugin-creator:agent-creator - For creating skills —
/plugin-creator:skill-creator - For MCP server creation —
/fastmcp-creator - For command development (legacy) —
/plugin-creator:command-development - For full plugin lifecycle —
/plugin-creator:plugin-lifecycle - For plugin structure and plugin.json schema —
/plugin-creator:claude-plugins-reference-2026 - For plugin settings and .local.md patterns —
/plugin-creator:plugin-settings
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
ccc
This skill should be used when code search is needed (whether explicitly requested or as part of completing a task), when indexing the codebase after changes, or when the user asks about ccc, cocoindex-code, or the codebase index. Trigger phrases include 'search the codebase', 'find code related to', 'update the index', 'ccc', 'cocoindex-code'.
agent-browser
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
delegate
Quick delegation template for sub-agent prompts. Use when assigning work to a sub-agent, before invoking the Agent tool, or when preparing prompts for specialized agents. Provides the WHERE-WHAT-WHY framework. For comprehensive delegation guidance, activate the agent-orchestration how-to-delegate skill.
swarm-spawning
Spawn agents and teammates in Claude Code swarms. Use when choosing between subagents vs teammates, selecting agent types (Explore, Plan, general-purpose, plugin agents), configuring spawn backends (in-process, tmux, iterm2), or setting environment variables for spawned agents.
knowledge-explorer
Manage the research/ knowledge base (KB) of tool and library research entries. Use when browsing KB topics, adding new research entries, updating existing entries with dated revisions, fetching GitHub repo metadata into a draft KB entry, or migrating old-format entries to skill-spec frontmatter. Triggers on tasks like "what do we have on X", "add this to the KB", "update the KB entry for Y", "fetch github info for owner/repo", or "migrate old entries".
design-anti-patterns
Enforce anti-AI UI design rules based on the Uncodixfy methodology. Use when generating HTML, CSS, React, Vue, Svelte, or any frontend UI code. Prevents "Codex UI" — the generic AI aesthetic of soft gradients, floating panels, oversized rounded corners, glassmorphism, hero sections in dashboards, and decorative copy. Applies constraints from Linear/Raycast/Stripe/GitHub design philosophy: functional, honest, human-designed interfaces. Triggers on: UI generation, dashboard building, frontend component creation, CSS styling, landing page design, or any task producing visual interface code.
Didn't find tool you were looking for?