From 041d6fbf7b8fae8a185d3aa5352f417e625bd708 Mon Sep 17 00:00:00 2001 From: Bence Nagy Date: Mon, 9 Feb 2026 21:18:04 -0800 Subject: [PATCH] Sync plugin updates --- .../.claude-plugin/plugin.json | 2 +- .../skills/create-cowork-plugin/SKILL.md | 258 ++++++++++++ .../references/component-schemas.md | 386 ++++++++++++++++++ .../references/example-plugins.md | 335 +++++++++++++++ 4 files changed, 980 insertions(+), 1 deletion(-) create mode 100644 cowork-plugin-management/skills/create-cowork-plugin/SKILL.md create mode 100644 cowork-plugin-management/skills/create-cowork-plugin/references/component-schemas.md create mode 100644 cowork-plugin-management/skills/create-cowork-plugin/references/example-plugins.md diff --git a/cowork-plugin-management/.claude-plugin/plugin.json b/cowork-plugin-management/.claude-plugin/plugin.json index 0cba809..5193c9a 100644 --- a/cowork-plugin-management/.claude-plugin/plugin.json +++ b/cowork-plugin-management/.claude-plugin/plugin.json @@ -1,6 +1,6 @@ { "name": "cowork-plugin-management", - "version": "0.1.0", + "version": "0.2.0", "description": "Create, customize, and manage plugins tailored to your organization's tools and workflows. Configure MCP servers, adjust plugin behavior, and adapt templates to match how your team works.", "author": { "name": "Anthropic" diff --git a/cowork-plugin-management/skills/create-cowork-plugin/SKILL.md b/cowork-plugin-management/skills/create-cowork-plugin/SKILL.md new file mode 100644 index 0000000..538fa7c --- /dev/null +++ b/cowork-plugin-management/skills/create-cowork-plugin/SKILL.md @@ -0,0 +1,258 @@ +--- +name: create-cowork-plugin +description: > + Guide users through creating a new plugin from scratch in a cowork session. + Use when users want to create a plugin, build a plugin, make a new plugin, develop a plugin, scaffold a plugin, start a plugin from scratch, or design a plugin. + This skill requires Cowork mode with access to the outputs directory for delivering the final .plugin file. +compatibility: Requires Cowork desktop app environment with access to the outputs directory for delivering .plugin files. +--- + +# Create Cowork Plugin + +Build a new plugin from scratch through guided conversation. Walk the user through discovery, planning, design, implementation, and packaging — delivering a ready-to-install `.plugin` file at the end. + +## Overview + +A plugin is a self-contained directory that extends Claude's capabilities with commands, skills, agents, hooks, and MCP server integrations. This skill encodes the full plugin architecture and a five-phase workflow for creating one conversationally. + +The process: +1. **Discovery** — understand what the user wants to build +2. **Component Planning** — determine which component types are needed +3. **Design & Clarifying Questions** — specify each component in detail +4. **Implementation** — create all plugin files +5. **Review & Package** — deliver the `.plugin` file + +> **Nontechnical output**: Keep all user-facing conversation in plain language. Do not expose implementation details like file paths, directory structures, or schema fields unless the user asks. Frame everything in terms of what the plugin will do. + +## Plugin Architecture + +### Directory Structure + +Every plugin follows this layout: + +``` +plugin-name/ +├── .claude-plugin/ +│ └── plugin.json # Required: plugin manifest +├── commands/ # Slash commands (.md files) +├── agents/ # Subagent definitions (.md files) +├── skills/ # Skills (subdirectories with SKILL.md) +│ └── skill-name/ +│ ├── SKILL.md +│ └── references/ +├── .mcp.json # MCP server definitions +└── README.md # Plugin documentation +``` + + +**Rules:** +- `.claude-plugin/plugin.json` is always required +- Component directories (`commands/`, `agents/`, `skills/`) go at the plugin root, not inside `.claude-plugin/` +- Only create directories for components the plugin actually uses +- Use kebab-case for all directory and file names + +### plugin.json Manifest + +Located at `.claude-plugin/plugin.json`. Minimal required field is `name`. + +```json +{ + "name": "plugin-name", + "version": "0.1.0", + "description": "Brief explanation of plugin purpose", + "author": { + "name": "Author Name" + } +} +``` + +**Name rules:** kebab-case, lowercase with hyphens, no spaces or special characters. +**Version:** semver format (MAJOR.MINOR.PATCH). Start at `0.1.0`. + +Optional fields: `homepage`, `repository`, `license`, `keywords`. + +Custom component paths can be specified (supplements, does not replace, auto-discovery): +```json +{ + "commands": "./custom-commands", + "agents": ["./agents", "./specialized-agents"], + "hooks": "./config/hooks.json", + "mcpServers": "./.mcp.json" +} +``` + +### Component Schemas + +Detailed schemas for each component type are in `references/component-schemas.md`. Summary: + +| Component | Location | Format | +|-----------|----------|--------| +| Commands | `commands/*.md` | Markdown + YAML frontmatter | +| Skills | `skills/*/SKILL.md` | Markdown + YAML frontmatter | +| MCP Servers | `.mcp.json` | JSON | +| Agents (uncommonly used in Cowork) | `agents/*.md` | Markdown + YAML frontmatter | +| Hooks (rarely used in Cowork) | `hooks/hooks.json` | JSON | + +This schema is shared with Claude Code's plugin system, but you're creating a plugin for Claude Cowork, a desktop app for doing knowledge work. +Cowork users will usually find commands and skills the most useful. + +### Customizable plugins + +When a plugin is intended to be shared with others, it might have parts that need to be adapted to individual users. You might need to reference external tools by category rather than specific product (e.g., "project tracker" instead of "Jira"), and you might need to list multiple options for company policies (e.g. using story points vs. using T-shirt sizes for estimation.) When sharing is needed, use generic language and mark these as requiring customization with two tilde characters such as `~~project tracker` and `~~determine issue size`. + +> **Do not use this pattern by default.** Only introduce `~~` placeholders if the user explicitly says they want others to use the plugin. In that case, ask which parts of the plugin should be customizable by other users (e.g., which tools or services could vary), and only add placeholders for those parts. + +If you need to use tool categories, write a `CONNECTORS.md` file at the plugin root to explain: + +```markdown +# Connectors + +## How tool references work + +Plugin files use `~~category` as a placeholder for whatever tool the user +connects in that category. Plugins are tool-agnostic — they describe +workflows in terms of categories rather than specific products. + +## Connectors for this plugin + +| Category | Placeholder | Options | +|----------|-------------|-----------------|---------------| +| Chat | `~~chat` | Slack, Microsoft Teams, Discord | +| Project tracker | `~~project tracker` | Linear, Asana, Jira | +``` + +### ${CLAUDE_PLUGIN_ROOT} Variable + +Use `${CLAUDE_PLUGIN_ROOT}` for all intra-plugin path references in hooks and MCP configs. Never hardcode absolute paths. + +## Guided Workflow + +### Phase 1: Discovery + +**Goal**: Understand what the user wants to build and why. + +Ask (only what is unclear — skip questions if the user's initial request already answers them): + +- What should this plugin do? What problem does it solve? +- Who will use it and in what context? +- Does it integrate with any external tools or services? +- Is there a similar plugin or workflow to reference? + +Summarize understanding and confirm before proceeding. + +**Output**: Clear statement of plugin purpose and scope. + +### Phase 2: Component Planning + +**Goal**: Determine which component types the plugin needs. + +Based on the discovery answers, determine: + +- **Skills** — Does it need specialized knowledge that Claude should load on-demand? (domain expertise, reference schemas, workflow guides) +- **Commands** — Are there user-initiated actions? (deploy, configure, analyze, review) +- **MCP Servers** — Does it need external service integration? (databases, APIs, SaaS tools) +- **Agents (uncommon)** — Are there autonomous multi-step tasks? (validation, generation, analysis) +- **Hooks (rare)** — Should something happen automatically on certain events? (enforce policies, load context, validate operations) + +Present a component plan table, including component types you decided not to create: + +``` +| Component | Count | Purpose | +|-----------|-------|---------| +| Skills | 1 | Domain knowledge for X | +| Commands | 2 | /do-thing, /check-thing | +| Agents | 0 | Not needed | +| Hooks | 1 | Validate writes | +| MCP | 1 | Connect to service Y | +``` + +Get user confirmation or adjustments before proceeding. + +**Output**: Confirmed list of components to create. + +### Phase 3: Design & Clarifying Questions + +**Goal**: Specify each component in detail. Resolve all ambiguities before implementation. + +For each component type in the plan, ask targeted design questions. Present questions grouped by component type. Wait for answers before proceeding. + +**Skills:** +- What user queries should trigger this skill? +- What knowledge domains does it cover? +- Should it include reference files for detailed content? + +**Commands:** +- What arguments does each command accept? +- What tools does each command need? (Read, Write, Bash, Grep, etc.) +- Is each command interactive or automated? + +**Agents:** +- Should each agent trigger proactively or only when requested? +- What tools does it need? +- What should the output format be? + +**Hooks:** +- Which events? (PreToolUse, PostToolUse, Stop, SessionStart, etc.) +- What behavior — validate, block, modify, add context? +- Prompt-based (LLM-driven) or command-based (deterministic script)? + +**MCP Servers:** +- What server type? (stdio for local, SSE for hosted with OAuth, HTTP for REST APIs) +- What authentication method? +- What tools should be exposed? + +If the user says "whatever you think is best," provide specific recommendations and get explicit confirmation. + +**Output**: Detailed specification for every component. + +### Phase 4: Implementation + +**Goal**: Create all plugin files following best practices. + +**Order of operations:** +1. Create the plugin directory structure +2. Create `plugin.json` manifest +3. Create each component (see `references/component-schemas.md` for exact formats) +4. Create `README.md` documenting the plugin + +**Implementation guidelines:** + +- **Commands** are instructions FOR Claude, not messages to the user. Write them as directives about what to do. +- **Skills** use progressive disclosure: lean SKILL.md body (under 3,000 words), detailed content in `references/`. Frontmatter description must be third-person with specific trigger phrases. +- **Agents** need a description with `` blocks showing triggering conditions, plus a system prompt in the markdown body. +- **Hooks** config goes in `hooks/hooks.json`. Use `${CLAUDE_PLUGIN_ROOT}` for script paths. Prefer prompt-based hooks for complex logic. +- **MCP configs** go in `.mcp.json` at plugin root. Use `${CLAUDE_PLUGIN_ROOT}` for local server paths. Document required env vars in README. + +### Phase 5: Review & Package + +**Goal**: Deliver the finished plugin. + +1. Summarize what was created — list each component and its purpose +2. Ask if the user wants any adjustments +3. Run `claude plugin validate `; fix any errors and warnings +4. Package as a `.plugin` file: + +```bash +cd /path/to/plugin-dir && zip -r /tmp/plugin-name.plugin . -x "*.DS_Store" && cp /tmp/plugin-name.plugin /path/to/outputs/plugin-name.plugin +``` + +> **Important**: Always create the zip in `/tmp/` first, then copy to the outputs folder. Writing directly to the outputs folder may fail due to permissions. + +> **Naming**: Use the plugin name from `plugin.json` for the `.plugin` file (e.g., if name is `code-reviewer`, output `code-reviewer.plugin`). + +The `.plugin` file will appear in the chat as a rich preview where the user can browse the files and accept the plugin by pressing a button. + +## Best Practices + +- **Start small**: Begin with the minimum viable set of components. A plugin with one well-crafted skill is more useful than one with five half-baked components. +- **Progressive disclosure for skills**: Core knowledge in SKILL.md, detailed reference material in `references/`, working examples in `examples/`. +- **Clear trigger phrases**: Skill descriptions should include specific phrases users would say. Agent descriptions should include `` blocks. +- **Commands are for Claude**: Write command content as instructions for Claude to follow, not documentation for the user to read. +- **Imperative writing style**: Use verb-first instructions in skills ("Parse the config file," not "You should parse the config file"). +- **Portability**: Always use `${CLAUDE_PLUGIN_ROOT}` for intra-plugin paths, never hardcoded paths. +- **Security**: Use environment variables for credentials, HTTPS for remote servers, least-privilege tool access. + +## Additional Resources + +- **`references/component-schemas.md`** — Detailed format specifications for every component type (commands, skills, agents, hooks, MCP, CONNECTORS.md) +- **`references/example-plugins.md`** — Three complete example plugin structures at different complexity levels diff --git a/cowork-plugin-management/skills/create-cowork-plugin/references/component-schemas.md b/cowork-plugin-management/skills/create-cowork-plugin/references/component-schemas.md new file mode 100644 index 0000000..c39b7e7 --- /dev/null +++ b/cowork-plugin-management/skills/create-cowork-plugin/references/component-schemas.md @@ -0,0 +1,386 @@ +# Component Schemas + +Detailed format specifications for every plugin component type. Reference this when implementing components in Phase 4. + +## Commands + +**Location**: `commands/command-name.md` +**Format**: Markdown with optional YAML frontmatter + +### Frontmatter Fields + +| Field | Required | Type | Description | +|-------|----------|------|-------------| +| `description` | No | String | Brief description shown in `/help` (under 60 chars) | +| `allowed-tools` | No | String or Array | Tools the command can use | +| `model` | No | String | Model override: `sonnet`, `opus`, `haiku` | +| `argument-hint` | No | String | Documents expected arguments for autocomplete | + +### Example Command + +```markdown +--- +description: Review code for security issues +allowed-tools: Read, Grep, Bash(git:*) +argument-hint: [file-path] +--- + +Review @$1 for security vulnerabilities including: +- SQL injection +- XSS attacks +- Authentication bypass +- Insecure data handling + +Provide specific line numbers, severity ratings, and remediation suggestions. +``` + +### Key Rules + +- **Commands are instructions FOR Claude**, not messages for the user. Write them as directives. +- `$ARGUMENTS` captures all arguments as a single string; `$1`, `$2`, `$3` capture positional arguments. +- `@path` syntax includes file contents in the command context. +- `!` backtick syntax executes bash inline for dynamic context (e.g., `` !`git diff --name-only` ``). +- Use `${CLAUDE_PLUGIN_ROOT}` to reference plugin files portably. + +### allowed-tools Patterns + +```yaml +# Specific tools +allowed-tools: Read, Write, Edit, Bash(git:*) + +# Bash with specific commands only +allowed-tools: Bash(npm:*), Read + +# MCP tools (specific) +allowed-tools: ["mcp__plugin_name_server__tool_name"] +``` + +## Skills + +**Location**: `skills/skill-name/SKILL.md` +**Format**: Markdown with YAML frontmatter + +### Frontmatter Fields + +| Field | Required | Type | Description | +|-------|----------|------|-------------| +| `name` | Yes | String | Skill identifier | +| `description` | Yes | String | Third-person description with trigger phrases | +| `version` | No | String | Semver version | + +### Example Skill + +```yaml +--- +name: api-design +description: > + This skill should be used when the user asks to "design an API", + "create API endpoints", "review API structure", or needs guidance + on REST API best practices, endpoint naming, or request/response design. +version: 0.1.0 +--- +``` + +### Writing Style Rules + +- **Frontmatter description**: Third-person ("This skill should be used when..."), with specific trigger phrases in quotes. +- **Body**: Imperative/infinitive form ("Parse the config file," not "You should parse the config file"). +- **Length**: Keep SKILL.md body under 3,000 words (ideally 1,500-2,000). Move detailed content to `references/`. + +### Skill Directory Structure + +``` +skill-name/ +├── SKILL.md # Core knowledge (required) +├── references/ # Detailed docs loaded on demand +│ ├── patterns.md +│ └── advanced.md +├── examples/ # Working code examples +│ └── sample-config.json +└── scripts/ # Utility scripts + └── validate.sh +``` + +### Progressive Disclosure Levels + +1. **Metadata** (always in context): name + description (~100 words) +2. **SKILL.md body** (when skill triggers): core knowledge (<5k words) +3. **Bundled resources** (as needed): references, examples, scripts (unlimited) + +## Agents + +**Location**: `agents/agent-name.md` +**Format**: Markdown with YAML frontmatter + +### Frontmatter Fields + +| Field | Required | Type | Description | +|-------|----------|------|-------------| +| `name` | Yes | String | Lowercase, hyphens, 3-50 chars | +| `description` | Yes | String | Triggering conditions with `` blocks | +| `model` | Yes | String | `inherit`, `sonnet`, `opus`, or `haiku` | +| `color` | Yes | String | `blue`, `cyan`, `green`, `yellow`, `magenta`, `red` | +| `tools` | No | Array | Restrict to specific tools | + +### Example Agent + +```markdown +--- +name: code-reviewer +description: Use this agent when the user asks for a thorough code review or wants detailed analysis of code quality, security, and best practices. + + +Context: User has just written a new module +user: "Can you do a deep review of this code?" +assistant: "I'll use the code-reviewer agent to provide a thorough analysis." + +User explicitly requested a detailed review, which matches this agent's specialty. + + + + +Context: User is about to merge a PR +user: "Review this before I merge" +assistant: "Let me run a comprehensive review using the code-reviewer agent." + +Pre-merge review benefits from the agent's structured analysis process. + + + +model: inherit +color: blue +tools: ["Read", "Grep", "Glob"] +--- + +You are a code review specialist focused on identifying issues across security, performance, maintainability, and correctness. + +**Your Core Responsibilities:** +1. Analyze code structure and organization +2. Identify security vulnerabilities +3. Flag performance concerns +4. Check adherence to best practices + +**Analysis Process:** +1. Read all files in scope +2. Identify patterns and anti-patterns +3. Categorize findings by severity +4. Provide specific remediation suggestions + +**Output Format:** +Present findings grouped by severity (Critical, Warning, Info) with: +- File path and line number +- Description of the issue +- Suggested fix +``` + +### Agent Naming Rules + +- 3-50 characters +- Lowercase letters, numbers, hyphens only +- Must start and end with alphanumeric +- No underscores, spaces, or special characters + +### Color Guidelines + +- Blue/Cyan: Analysis, review +- Green: Success-oriented tasks +- Yellow: Caution, validation +- Red: Critical, security +- Magenta: Creative, generation + +## Hooks + +**Location**: `hooks/hooks.json` +**Format**: JSON + +### Available Events + +| Event | When it fires | +|-------|--------------| +| `PreToolUse` | Before a tool call executes | +| `PostToolUse` | After a tool call completes | +| `Stop` | When Claude finishes a response | +| `SubagentStop` | When a subagent finishes | +| `SessionStart` | When a session begins | +| `SessionEnd` | When a session ends | +| `UserPromptSubmit` | When the user sends a message | +| `PreCompact` | Before context compaction | +| `Notification` | When a notification fires | + +### Hook Types + +**Prompt-based** (recommended for complex logic): +```json +{ + "type": "prompt", + "prompt": "Evaluate whether this file write follows project conventions: $TOOL_INPUT", + "timeout": 30 +} +``` +Supported events: Stop, SubagentStop, UserPromptSubmit, PreToolUse. + +**Command-based** (deterministic checks): +```json +{ + "type": "command", + "command": "bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/validate.sh", + "timeout": 60 +} +``` + +### Example hooks.json + +```json +{ + "PreToolUse": [ + { + "matcher": "Write|Edit", + "hooks": [ + { + "type": "prompt", + "prompt": "Check that this file write follows project coding standards. If it violates standards, explain why and block.", + "timeout": 30 + } + ] + } + ], + "SessionStart": [ + { + "matcher": "", + "hooks": [ + { + "type": "command", + "command": "cat ${CLAUDE_PLUGIN_ROOT}/context/project-context.md", + "timeout": 10 + } + ] + } + ] +} +``` + +### Hook Output Format (Command Hooks) + +Command hooks return JSON to stdout: + +```json +{ + "decision": "block", + "reason": "File write violates naming convention" +} +``` + +Decisions: `approve`, `block`, `ask_user` (ask for confirmation). + +## MCP Servers + +**Location**: `.mcp.json` at plugin root +**Format**: JSON + +### Server Types + +**stdio** (local process): +```json +{ + "mcpServers": { + "my-server": { + "command": "node", + "args": ["${CLAUDE_PLUGIN_ROOT}/servers/server.js"], + "env": { + "API_KEY": "${API_KEY}" + } + } + } +} +``` + +**SSE** (hosted with OAuth): +```json +{ + "mcpServers": { + "asana": { + "type": "sse", + "url": "https://mcp.asana.com/sse" + } + } +} +``` + +**HTTP** (REST API): +```json +{ + "mcpServers": { + "api-service": { + "type": "http", + "url": "https://api.example.com/mcp", + "headers": { + "Authorization": "Bearer ${API_TOKEN}" + } + } + } +} +``` + +### Server Type Selection Guide + +| Type | Best for | Auth method | +|------|----------|-------------| +| stdio | Local tools, custom servers | Environment variables | +| SSE | Hosted cloud services | OAuth (automatic) | +| HTTP | REST API backends | Token headers | + +### Environment Variable Expansion + +All MCP configs support `${VAR_NAME}` substitution: +- `${CLAUDE_PLUGIN_ROOT}` — plugin directory (always use for portability) +- `${ANY_ENV_VAR}` — user environment variables + +Document all required environment variables in the plugin README. + +## CONNECTORS.md + +**Location**: Plugin root +**When to create**: When the plugin references external tools by category rather than specific product + +### Format + +```markdown +# Connectors + +## How tool references work + +Plugin files use `~~category` as a placeholder for whatever tool the user +connects in that category. For example, `~~project tracker` might mean +Asana, Linear, Jira, or any other project tracker with an MCP server. + +Plugins are tool-agnostic — they describe workflows in terms of categories +rather than specific products. + +## Connectors for this plugin + +| Category | Placeholder | Included servers | Other options | +|----------|-------------|-----------------|---------------| +| Chat | `~~chat` | Slack | Microsoft Teams, Discord | +| Project tracker | `~~project tracker` | Linear | Asana, Jira, Monday | +``` + +### Using ~~ Placeholders + +In plugin files (commands, skills, agents), reference tools generically: + +```markdown +Check ~~project tracker for open tickets assigned to the user. +Post a summary to ~~chat in the team channel. +``` + +During customization (via the cowork-plugin-customizer skill), these get replaced with specific tool names. + +## README.md + +Every plugin should include a README with: + +1. **Overview** — what the plugin does +2. **Components** — list of commands, skills, agents, hooks, MCP servers +3. **Setup** — any required environment variables or configuration +4. **Usage** — how to use each command or trigger each skill +5. **Customization** — if CONNECTORS.md exists, mention it diff --git a/cowork-plugin-management/skills/create-cowork-plugin/references/example-plugins.md b/cowork-plugin-management/skills/create-cowork-plugin/references/example-plugins.md new file mode 100644 index 0000000..c4d6c46 --- /dev/null +++ b/cowork-plugin-management/skills/create-cowork-plugin/references/example-plugins.md @@ -0,0 +1,335 @@ +# Example Plugins + +Three complete plugin structures at different complexity levels. Use these as templates when implementing in Phase 4. + +## Minimal Plugin: Single Command + +A simple plugin with one slash command and no other components. + +### Structure + +``` +meeting-notes/ +├── .claude-plugin/ +│ └── plugin.json +├── commands/ +│ └── meeting-notes.md +└── README.md +``` + +### plugin.json + +```json +{ + "name": "meeting-notes", + "version": "0.1.0", + "description": "Generate structured meeting notes from transcripts", + "author": { + "name": "User" + } +} +``` + +### commands/meeting-notes.md + +```markdown +--- +description: Generate structured meeting notes from a transcript +argument-hint: [transcript-file] +allowed-tools: Read, Write +--- + +Read the transcript at @$1 and generate structured meeting notes. + +Include these sections: +1. **Attendees** — list all participants mentioned +2. **Summary** — 2-3 sentence overview of the meeting +3. **Key Decisions** — numbered list of decisions made +4. **Action Items** — table with columns: Owner, Task, Due Date +5. **Open Questions** — anything unresolved + +Write the notes to a new file named after the transcript with `-notes` appended. +``` + +--- + +## Standard Plugin: Skill + Commands + MCP + +A plugin that combines domain knowledge, user commands, and external service integration. + +### Structure + +``` +code-quality/ +├── .claude-plugin/ +│ └── plugin.json +├── commands/ +│ ├── review.md +│ └── fix-lint.md +├── skills/ +│ └── coding-standards/ +│ ├── SKILL.md +│ └── references/ +│ └── style-rules.md +├── .mcp.json +└── README.md +``` + +### plugin.json + +```json +{ + "name": "code-quality", + "version": "0.1.0", + "description": "Enforce coding standards with reviews, linting, and style guidance", + "author": { + "name": "User" + } +} +``` + +### commands/review.md + +```markdown +--- +description: Review code changes for style and quality issues +allowed-tools: Read, Grep, Bash(git:*) +--- + +Get the list of changed files: !`git diff --name-only` + +For each changed file: +1. Read the file +2. Check against the coding-standards skill for style violations +3. Identify potential bugs or anti-patterns +4. Flag any security concerns + +Present a summary with: +- File path +- Issue severity (Error, Warning, Info) +- Description and suggested fix +``` + +### commands/fix-lint.md + +```markdown +--- +description: Auto-fix linting issues in changed files +allowed-tools: Read, Write, Edit, Bash(npm:*) +--- + +Run the linter: !`npm run lint -- --format json 2>&1` + +Parse the linter output and fix each issue: +- For auto-fixable issues, apply the fix directly +- For manual-fix issues, make the correction following project conventions +- Skip issues that require architectural changes + +After all fixes, run the linter again to confirm clean output. +``` + +### skills/coding-standards/SKILL.md + +```yaml +--- +name: coding-standards +description: > + This skill should be used when the user asks about "coding standards", + "style guide", "naming conventions", "code formatting rules", or needs + guidance on project-specific code quality expectations. +version: 0.1.0 +--- +``` + +```markdown +# Coding Standards + +Project coding standards and conventions for consistent, high-quality code. + +## Core Rules + +- Use camelCase for variables and functions +- Use PascalCase for classes and types +- Prefer const over let; avoid var +- Maximum line length: 100 characters +- Use explicit return types on all exported functions + +## Import Order + +1. External packages +2. Internal packages (aliased with @/) +3. Relative imports +4. Type-only imports last + +## Additional Resources + +- **`references/style-rules.md`** — complete style rules by language +``` + +### .mcp.json + +```json +{ + "mcpServers": { + "github": { + "type": "http", + "url": "https://api.githubcopilot.com/mcp/" + } + } +} +``` + +--- + +## Full-Featured Plugin: All Component Types + +A plugin using skills, commands, agents, hooks, and MCP integration with tool-agnostic connectors. + +### Structure + +``` +engineering-workflow/ +├── .claude-plugin/ +│ └── plugin.json +├── commands/ +│ ├── standup-prep.md +│ └── create-ticket.md +├── skills/ +│ └── team-processes/ +│ ├── SKILL.md +│ └── references/ +│ └── workflow-guide.md +├── agents/ +│ └── ticket-analyzer.md +├── hooks/ +│ └── hooks.json +├── .mcp.json +├── CONNECTORS.md +└── README.md +``` + +### plugin.json + +```json +{ + "name": "engineering-workflow", + "version": "0.1.0", + "description": "Streamline engineering workflows: standup prep, ticket management, and code quality", + "author": { + "name": "User" + }, + "keywords": ["engineering", "workflow", "tickets", "standup"] +} +``` + +### agents/ticket-analyzer.md + +```markdown +--- +name: ticket-analyzer +description: Use this agent when the user needs to analyze tickets, triage incoming issues, or prioritize a backlog. + + +Context: User is preparing for sprint planning +user: "Help me triage these new tickets" +assistant: "I'll use the ticket-analyzer agent to review and categorize the tickets." + +Ticket triage requires systematic analysis across multiple dimensions, making the agent appropriate. + + + + +Context: User has a large backlog +user: "Prioritize my backlog for next sprint" +assistant: "Let me analyze the backlog using the ticket-analyzer agent to recommend priorities." + +Backlog prioritization is a multi-step autonomous task well-suited for the agent. + + + +model: inherit +color: cyan +tools: ["Read", "Grep"] +--- + +You are a ticket analysis specialist. Analyze tickets for priority, effort, and dependencies. + +**Your Core Responsibilities:** +1. Categorize tickets by type (bug, feature, tech debt, improvement) +2. Estimate relative effort (S, M, L, XL) +3. Identify dependencies between tickets +4. Recommend priority ordering + +**Analysis Process:** +1. Read all ticket descriptions +2. Categorize each by type +3. Estimate effort based on scope +4. Map dependencies +5. Rank by impact-to-effort ratio + +**Output Format:** +| Ticket | Type | Effort | Dependencies | Priority | +|--------|------|--------|-------------|----------| +| ... | ... | ... | ... | ... | + +Followed by a brief rationale for the top 5 priorities. +``` + +### hooks/hooks.json + +```json +{ + "SessionStart": [ + { + "matcher": "", + "hooks": [ + { + "type": "command", + "command": "echo '## Team Context\n\nSprint cycle: 2 weeks. Standup: daily at 9:30 AM. Use ~~project tracker for ticket management.'", + "timeout": 5 + } + ] + } + ] +} +``` + +### CONNECTORS.md + +```markdown +# Connectors + +## How tool references work + +Plugin files use `~~category` as a placeholder for whatever tool the user +connects in that category. Plugins are tool-agnostic. + +## Connectors for this plugin + +| Category | Placeholder | Included servers | Other options | +|----------|-------------|-----------------|---------------| +| Project tracker | `~~project tracker` | Linear | Asana, Jira, Monday | +| Chat | `~~chat` | Slack | Microsoft Teams | +| Source control | `~~source control` | GitHub | GitLab, Bitbucket | +``` + +### .mcp.json + +```json +{ + "mcpServers": { + "linear": { + "type": "sse", + "url": "https://mcp.linear.app/sse" + }, + "github": { + "type": "http", + "url": "https://api.githubcopilot.com/mcp/" + }, + "slack": { + "type": "http", + "url": "https://slack.mcp.claude.com/mcp" + } + } +} +```