企业官网建设流程全解析

Claude Code 标准插件结构实战：以 standard-plugin 模式构建生产级插件

【免费下载链接】claude-codeClaude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code

导读

Claude Code 插件采用"约定优于配置"的标准目录结构与自动发现机制：只要把命令、Agent、Skill、Hook 放在约定位置，并提供一个.claude-plugin/plugin.json清单，Claude Code 就能自动加载全部组件。本文以官方技能 plugin-structure 提供的standard-plugin（标准插件）示例为骨架，逐文件拆解一个同时包含 commands、agents、skills、hooks、scripts 五大组件的生产级插件code-quality，并结合仓库中真实插件的实现（如 hookify、ralph-wiggum、commit-commands、feature-dev）验证各项规则的底层运作。读完后你将掌握：如何设计插件目录、如何编写完整清单字段、如何让命令/Aget/Skill/Hook 各组件协同工作，以及如何用${CLAUDE_PLUGIN_ROOT}保证插件跨系统可移植。

一、标准插件模式概览：什么时候需要它

Claude Code 插件的目录布局有三档示例，位于 examples 目录：

• minimal-plugin.md：最小插件，仅一个plugin.json+ 单个命令，适合原型验证与单功能小工具；
• standard-plugin.md（本文主体）：结构良好、面向发布与团队协作的生产级插件，同时包含命令、Agent、Skill、Hook 四大组件，组件之间相互集成；
• advanced-plugin.md：企业级插件，引入多级目录、MCP 服务器、共享库与配置管理。

标准插件模式适用于以下场景（原文 "When to Use This Pattern"）：

• 面向分发（marketplace）的生产插件；
• 团队协作工具；
• 需要强制一致性（代码规范、提交校验）的插件；
• 拥有多个入口点的复杂工作流。

它区别于最小插件的核心在于：组件齐全且互相联动——命令负责入口、Agent 负责专业任务、Skill 提供知识、Hook 自动执行校验。

二、目录结构全景：约定位置与四条关键规则

标准插件code-quality的完整目录结构如下（继承自原文档）：

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.py

对照 plugin-structure/SKILL.md 中规定的目录范式与"Critical rules"，可以提炼出四条必须遵守的关键规则：

1. 清单位置固定：plugin.json必须位于.claude-plugin/目录内，Claude Code 只有在该位置才能识别插件；
2. 组件目录必须在插件根级别：commands/、agents/、skills/、hooks/均须位于插件根目录下，不能嵌套进.claude-plugin/内部；
3. 按需创建目录：只创建插件实际用到的组件目录，没有 Hook 就不必建hooks/；
4. 命名统一 kebab-case：所有目录名与文件名使用小写字母加连字符，例如code-standards/、validate-commit.sh。

这种"约定位置 + 自动发现"的设计（Auto-Discovery）意味着：安装插件时各组件自动注册，启用插件时组件即可用，修改后无需重启——下次 Claude Code 会话即生效。SKILL.md 列出的发现顺序为：先读plugin.json清单，再依次扫描commands/（.md 文件）、agents/（.md 文件）、skills/（含SKILL.md的子目录）、hooks/hooks.json与.mcp.json。

三、插件清单：.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": "quality@example.com" }, "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"] }

对照 manifest-reference.md 的完整字段参考，逐项说明：

name字段的校验规则在 manifest-reference 中以正则给出：

/^[a-z][a-z0-9]*(-[a-z0-9]+)*$/

即：✅ 合法如api-tester、code-review、git-workflow-automation；❌ 非法如API Tester（含空格与大写）、code_review（下划线）、-git-workflow（连字符开头）、test-（连字符结尾）。Claude Code 在插件加载时会执行清单校验：JSON 语法、字段类型、name格式、语义化版本、路径合法性（相对路径且以./开头）、URL 合法性等。

标准插件清单只依赖默认目录自动发现，因此未写任何commands/agents/hooks/mcpServers路径字段。只有当组件不在默认目录时才需要补充路径，且自定义路径是"补充"而非"替换"——默认目录与自定义路径中的组件会同时加载。路径规则必须满足：相对路径、以./开头、禁止绝对路径、禁止../父目录跳转、一律使用正斜杠（Windows 亦然）。

四、命令组件：commands/ 下的斜杠命令

所有commands/目录下的.md文件会被自动发现并注册为 Claude Code 的斜杠命令（Slash Command），文件名即命令名（kebab-case），文件内容由 YAML frontmatter + Markdown 指令体组成。标准插件示例中的/lint命令完整内容如下：

--- 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)

`/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 changes

命令文件 frontmatter 的标准字段为name与description。仓库中的真实命令文件 commit-push-pr.md 展示了更丰富的扩展：除description外，还允许声明allowed-tools（如Bash(git checkout --branch:*)、Bash(gh pr create:*)）来限定命令可用的工具，并在正文中使用!git status`` 这类内联命令注入实时上下文（当前 git 状态、diff、分支名）——说明命令文件不仅是静态指令，还可以动态获取环境信息，并约束 Agent 的工具权限。

值得注意的命令命名约定：code-review.md→/code-review，run-tests.md→/run-tests。SKILL.md 建议命令名控制在 2–3 个词（如review-pr、run-ci），保持简洁明确。

五、Agent 组件：agents/ 下的专业子代理

agents/目录下的.md文件会被自动发现为子代理（Subagent）。标准插件中的code-reviewer与test-generator两个 Agent，展示了如何用 frontmatter 声明能力、用正文定义专业工作流。

5.1 code-reviewer：专业代码评审代理

--- 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)

5.2 test-generator：测试生成代理

--- 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 descriptions

两个 Agent 的capabilities列表是"能力声明"：Claude Code 会根据任务上下文自动匹配并选择最合适的子代理，用户也可以手动唤起。仓库中的真实 Agent 定义 feature-dev/agents/code-reviewer.md 进一步展示了 frontmatter 的扩展能力——除description外还可声明tools（如Glob, Grep, Read, WebSearch）、model（如sonnet）与color等字段，正文则以"职责边界 + 评审范围 + 置信度评分（0–100，仅报告 ≥80 分的高置信度问题）"的方式把评审标准精确化。这印证了 Agent 文件的核心价值：把专家的隐性判断标准显式化为可执行的指令。

六、Skill 组件：skills/ 下的知识库

每个 Skill 占用skills/下一个独立子目录，目录内必须有SKILL.md（注意：不是README.md），并可携带references/、examples/、scripts/等资源子目录。Skill 采用渐进式披露（Progressive Disclosure）：SKILL.md只放核心知识，详细内容放references/，随用随取，从而节省上下文窗口——这一设计在 plugin-structure/README.md 中有明确说明（SKILL.md 约 1600 词、references 约 6000 词、examples 约 8000 词，按需加载）。

6.1 skills/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

`SKILL.md` 的 frontmatter 三要素为 `name`、`description`（"何时使用本技能"）、`version`。其中 `description` 至关重要——Claude Code 正是通过任务上下文与该描述的匹配度来自主激活 Skill。SKILL.md 正文的"Example Pattern"还展示了 Skill 承载代码规范范例的能力（如错误处理的标准写法），这比纯文字规则更容易让 Agent 对齐。 ### 6.2 skills/code-standards/references/style-guide.md（引用资源示例） ```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:

// 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:

// 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:

# 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:

# 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

注意 `style-guide.md` 结尾的 `references/go-style.md` 等链接是示例插件内部结构（原文即为插件内部的占位引用），实际按需补充即可。Skill 的资源组织原则（见 [component-patterns.md](https://link.gitcode.com/i/1f1fb5d107ae29f9cf16c0d8a34383e0) 中的 "Skill with Rich Resources" 模式）是：`SKILL.md` 只做概览与触发判断，`references/` 放按需加载的深度指南，`examples/` 放可复制样例，`scripts/` 放可执行脚本，`assets/` 放模板配置。标准插件中的 `testing-patterns` Skill（含 `examples/unit-test.js`、`examples/integration-test.js`）正是这种"SKILL.md + examples"资源组合的典型。 ## 七、Hook 组件：hooks/hooks.json 与校验脚本 Hook 是插件自动化能力的关键：它们绑定到 Claude Code 生命周期事件，事件发生时自动执行，无需用户干预。标准插件在 `PreToolUse` 与 `Stop` 两个事件上配置了 Hook。 ### 7.1 hooks/hooks.json ```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 } ] } ] }

这份配置展示了 Hook 的两种类型：

• type: "prompt"：向 Claude 注入一段指令（Prompt），让它按规则行事。上例在PreToolUse事件、matcher匹配Write|Edit工具时，要求 Claude 在改代码前先对照code-standardsSkill 校验格式、命名与文档，并给出改进建议；
• type: "command"：执行外部命令。上例在Stop事件（matcher: ".*"匹配一切）时运行validate-commit.sh，在会话结束前做质量门禁，超时 45 秒。

SKILL.md 中列出的可用事件全集为：PreToolUse、PostToolUse、Stop、SubagentStop、SessionStart、SessionEnd、UserPromptSubmit、PreCompact、Notification。Hook 配置既可以在hooks/hooks.json中定义，也可以内联在plugin.json的hooks字段（适合少于 50 行的简单场景）。

仓库中的真实插件提供了绝佳佐证：hookify/hooks/hooks.json在PreToolUse、PostToolUse、Stop、UserPromptSubmit四个事件上分别挂载pretooluse.py、posttooluse.py、stop.py、userpromptsubmit.py脚本，且所有命令路径统一使用${CLAUDE_PLUGIN_ROOT}前缀；ralph-wiggum/hooks/hooks.json则通过一个StopHook 拦截 Claude 的退出尝试并回灌同一份提示，形成"自我指涉循环"（Ralph 循环）——这正说明 Hook 不只是"检查器"，还可以是流程引擎。

7.2 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 0

该脚本是一个教科书式的"提交前质量门禁"：

• 无未提交变更时直接输出{"systemMessage": "No changes to validate. Task complete."}并以 0 退出，跳过校验；
• 只对暂存的.js、.ts、.py文件运行对应 linter（ESLint / Pylint），实现"增量校验"而非全量校验；
• 发现问题时输出systemMessage并返回非零退出码（exit 1），Claude Code 会将该消息呈现给模型，阻止任务草率收尾。

systemMessage+ 退出码是 Hook 脚本与 Claude Code 通信的标准协议：退出码 0 表示放行，非 0 表示拦截并把systemMessage内容作为反馈注入。这也是 security-guidance 等插件内部 hook 采用的通用机制（该插件通过 hooks.json 组织多个 Python hook 模块）。

八、可移植路径：${CLAUDE_PLUGIN_ROOT} 的正确用法

标准插件中凡是涉及脚本路径的地方，全部使用${CLAUDE_PLUGIN_ROOT}前缀，例如bash ${CLAUDE_PLUGIN_ROOT}/scripts/run-linter.sh、bash ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/validate-commit.sh。这是 Claude Code 插件可移植性的核心约定：

• 插件可能通过 marketplace、本地目录、npm 等多种方式安装到不同位置，加上操作系统差异，硬编码绝对路径必然失效；
• ${CLAUDE_PLUGIN_ROOT}是 Claude Code 在启用插件时注入的环境变量，指向插件根目录，在任何环境下都能正确解析。

SKILL.md 明确给出"使用位置"与"禁用清单"：

需要注意：${CLAUDE_PLUGIN_ROOT}在清单 JSON 字段（hooks、MCP servers）、组件文件正文（commands、agents、skills）以及被执行的脚本内部（作为环境变量$CLAUDE_PLUGIN_ROOT）三种语境下均可使用。真实仓库验证：hookify 与 ralph-wiggum 的hooks.json中所有命令路径均以${CLAUDE_PLUGIN_ROOT}开头；而plugin.json中用于声明组件目录的路径字段则遵循另一套规则——相对路径、./开头、禁止绝对路径与../（见 manifest-reference.md 的 Path Resolution 章节）。

九、端到端使用：命令与 Agent 的实战输出

标准插件文档给出的运行示例，完整呈现了用户在claude会话中的实际体验：

9.1 运行命令

$ 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 ...

命令输出的要点是分级组织：/lint按 Critical（必须修）→ Warnings（应该修）→ Style Suggestions（可选）三级呈现，每条问题附带文件路径与行号；/test按测试摘要 → 覆盖率 → 未覆盖文件 → 失败详情四段式结构化输出。这种输出规范让结果既可读又可被后续处理。

9.2 使用 Agent

> 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: MEDIUM

注意"[code-reviewer agent selected automatically]"这一行——用户并未手动指定 Agent，而是 Claude Code 根据"review code"的任务语义自动匹配了capabilities中声明了 bug 检测、安全分析等能力的code-reviewer代理，这正是 component-patterns.md 中"Activation Phase"所描述的机制：任务到达 → Claude Code 评估各 Agent 的能力声明 → 选择最匹配者。同时，code-reviewer 在评审过程中会自动加载code-standardsSkill 作为项目级规范依据，实现 Skill 与 Agent 的联动。

十、标准插件模式的五大要点与适用场景

原文以 "Key Points" 收束，可归纳为设计五原则：

1. 完整清单（Complete manifest）：填全所有推荐元数据字段（name/version/description/author/homepage/repository/license/keywords），为分发与发现做好准备；
2. 多组件（Multiple components）：同时提供 commands、agents、skills、hooks，覆盖"入口—执行—知识—门禁"全链路；
3. 富 Skill（Rich skills）：用 references 与 examples 承载详细信息，让 SKILL.md 保持精简、按需加载；
4. 自动化（Automation）：Hook 自动强制规范，无需人工提醒；
5. 集成（Integration）：各组件协同工作——命令调用脚本、命令建议使用 Agent、Agent 自动加载 Skill、Hook 校验命令与代码质量。

适用场景（When to Use This Pattern）：

• 面向分发（市场/团队共享）的生产插件；
• 团队协作工具（规范统一、流程一致）；
• 需要强制一致性约束的插件（代码规范、提交校验）；
• 拥有多个入口点的复杂工作流（命令、Agent、Hook 多路触发）。

十一、从标准插件继续进阶

• 若你的插件只有一个命令、零依赖，参考 minimal-plugin.md（单plugin.json+ 单个commands/hello.md），保持最简；
• 若需企业级能力——MCP 服务器集成、多级目录组织、共享库、环境配置管理——参考 advanced-plugin.md 的enterprise-devops案例；
• 深挖清单字段校验、路径解析规则与"最小/推荐/完整"三档清单写法，阅读 manifest-reference.md；
• 学习组件生命周期（发现与激活）、命令/Agent/Skill/Hook/脚本的组织模式与跨组件共享资源模式，阅读 component-patterns.md；
• 技能总览与触发条件见 plugin-structure/SKILL.md 与 plugin-structure/README.md；
• 想亲手实践，可在 Claude Code 中安装插件后运行/lint、/test等命令，观察 Hook 在写代码与结束会话时的自动拦截效果——标准插件模式是通往高级插件开发的坚实起点。

【免费下载链接】claude-codeClaude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflows - all through natural language commands.项目地址: https://gitcode.com/GitHub_Trending/cl/claude-code