AI 插件开发工具插件系统【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址https://gitcode.com/GitHub_Trending/cl/claude-plugins-official点击查看免费下载本篇技术指南以 claude-plugins-official 仓库中 plugin-dev 插件内置的 command-development 技能文档为主体系统讲解如何为 Claude Code 插件编写高质量斜杠命令Slash Command。文中给出十个可直接复制使用的命令模板覆盖脚本执行、模板生成、多脚本工作流、配置驱动部署、Agent/Skill 集成、输入校验与环境感知等场景并结合仓库内真实插件的命令实现如 code-review、hookify、create-plugin 等做源码级印证。读完你将对插件命令的 frontmatter 配置、动态参数、${CLAUDE_PLUGIN_ROOT}可移植路径以及常见踩坑点形成完整认知能够独立为插件编写健壮、可复用的命令。本文对应的核心示例文档位于 plugins/plugin-dev/skills/command-development/examples/plugin-commands.md技能主文档为 SKILL.mdfrontmatter 字段细则见 frontmatter-reference.md插件专属特性参考见 plugin-features-reference.md。一、插件命令的底层机制CLAUDE_PLUGIN_ROOT 与自动发现在进入十个示例之前先厘清插件命令区别于普通项目命令的两大底层机制这是所有示例成立的前提。1.1 命令的自动发现与命名空间根据 plugin-features-reference.md 的说明Claude Code 会在插件加载时自动发现commands/目录下的所有.md文件无需任何手动注册plugin-name/ ├── commands/ # 自动发现的命令 │ ├── foo.md # /foo (plugin:plugin-name) │ └── bar.md # /bar (plugin:plugin-name) └── plugin.json # 插件清单命令在/help中会以(plugin:plugin-name)标签显示commands/下的子目录会形成命名空间例如commands/review/security.md对应/security (plugin:plugin-name:review)。命名上建议采用动作导向的动词短语如analyze-performance、docker-compose-up并考虑加插件名前缀避免与常见命令名冲突应避免/test、/run这类过于通用的名称。注意commands/目录属于旧版布局。技能主文档 SKILL.md 明确提示新插件应优先使用.claude/skills/name/SKILL.md目录格式用户主动调用的命令同样以技能形式实现两种布局加载行为完全一致仅文件组织方式不同。commands/仍是可接受的遗留方案。1.2 ${CLAUDE_PLUGIN_ROOT}插件内部路径的通用解插件命令中有一个专属环境变量${CLAUDE_PLUGIN_ROOT}它会被解析为插件目录的绝对路径是插件命令可移植性的核心。它的三种典型用法贯穿本文全部示例用法语法用途执行插件脚本!node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1运行插件自带的 Node.js 脚本加载插件配置${CLAUDE_PLUGIN_ROOT}/config/settings.json将配置文件内容注入命令上下文引用插件模板${CLAUDE_PLUGIN_ROOT}/templates/report.md使用插件模板作为生成基准例如!node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js在执行时会展开为node /path/to/plugins/plugin-name/scripts/analyze.js。之所以必须使用该变量而非相对路径或硬编码路径是因为命令可能在任何工作目录下被触发——相对路径./scripts/foo.js相对的是当前工作目录而非插件目录硬编码的/home/user/.claude/plugins/...则在不同安装环境下必然失效。仓库内插件实现也遵循这一约定例如 hookify 插件的命令、hook 脚本见 plugins/hookify/commands/hookify.md以及 create-plugin 工作流见 plugins/plugin-dev/commands/create-plugin.md均以${CLAUDE_PLUGIN_ROOT}引用自身资源。1.3 命令的两种动态语法!反引号执行!bash script.sh形式会在命令处理前先执行一段 Bash用于动态收集仓库状态、环境信息等上下文例如git rev-parse --short HEAD。前提是 frontmatter 的allowed-tools中放行了 Bash。文件引用$1或${CLAUDE_PLUGIN_ROOT}/config/xxx.json形式会把对应文件内容注入命令让 Claude 在正式处理前先读取这些文件。二、十大插件命令实战模式以下十个示例均来自 plugin-commands.md每个示例都给出了完整可复制的命令文件。模式 1简单插件命令commands/analyze.md适用场景调用单个插件脚本完成单一目的的轻量命令。--- description: Analyze code quality using plugin tools argument-hint: [file-path] allowed-tools: Bash(node:*), Read --- Analyze $1 using plugins quality checker: !node ${CLAUDE_PLUGIN_ROOT}/scripts/quality-check.js $1 Review the analysis output and provide: 1. Summary of findings 2. Priority issues to address 3. Suggested improvements 4. Code quality score interpretation要点拆解${CLAUDE_PLUGIN_ROOT}保证了脚本路径在任何安装位置都可用$1将用户传入的文件内容注入命令与脚本执行互为补充——Claude 既能看到文件内容又能拿到脚本分析结果allowed-tools: Bash(node:*)用命令过滤器把 Bash 权限收紧到 node 命令这是 frontmatter-reference.md 反复强调的最小权限原则。模式 2脚本驱动的综合分析commands/full-audit.md适用场景编排多个插件脚本产出结构化综合分析报告。--- description: Complete code audit using plugin suite argument-hint: [directory] allowed-tools: Bash(*) model: sonnet --- Running complete audit on $1: **Security scan:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/security-scan.sh $1 **Performance analysis:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/perf-analyze.sh $1 **Best practices check:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/best-practices.sh $1 Analyze all results and create comprehensive report including: - Critical issues requiring immediate attention - Performance optimization opportunities - Security vulnerabilities and fixes - Overall health score and recommendations要点拆解通过三个!反引号连续执行安全扫描、性能分析、最佳实践检查各脚本输出按 Markdown 小节组织model: sonnet显式指定执行模型。按 frontmatter-reference.md 的取值约定haiku适合简单快速任务sonnet是默认的均衡之选opus保留给复杂分析命令末尾给出明确的报告输出结构严重问题、优化机会、漏洞修复、健康评分避免 Claude 自由发挥偏离重点。模式 3模板驱动的文档生成commands/gen-api-docs.md适用场景以插件内置模板为基准结合源码文件生成标准化文档。--- description: Generate API documentation from template argument-hint: [api-file] --- Template structure: ${CLAUDE_PLUGIN_ROOT}/templates/api-documentation.md API implementation: $1 Generate complete API documentation following the template format above. Ensure documentation includes: - Endpoint descriptions with HTTP methods - Request/response schemas - Authentication requirements - Error codes and handling - Usage examples with curl commands - Rate limiting information Format output as markdown suitable for README or docs site.要点拆解两个引用叠加一个指向插件模板${CLAUDE_PLUGIN_ROOT}/templates/一个指向用户传入的 API 源文件$1Claude 在生成前同时拿到格式基准和内容素材需求清单端点、Schema、认证、错误码、curl 示例、限流信息全部以显式指令写入命令保证生成质量的一致性和可校验性。模式 4多脚本编排工作流commands/release.md适用场景把构建、测试、打包等步骤编排成顺序执行的多步流水线。--- description: Execute complete release workflow argument-hint: [version] allowed-tools: Bash(*), Read --- Executing release workflow for version $1: **Step 1 - Pre-release validation:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/pre-release-check.sh $1 **Step 2 - Build artifacts:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/build-release.sh $1 **Step 3 - Run test suite:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/run-tests.sh **Step 4 - Package release:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/package.sh $1 Review all step outputs and report: 1. Any failures or warnings 2. Build artifacts location 3. Test results summary 4. Next steps for deployment 5. Rollback plan if needed要点拆解用显式 Step 编号把脚本串成确定性顺序各步骤失败与否依赖 Claude 对输出的判断报告要求中包含了回滚计划——即使命令本身不含回滚逻辑也要求 Claude 基于版本号与构建产物给出后续操作建议这是把风险意识写进提示词的典型做法。模式 5配置驱动的部署commands/deploy.md适用场景按环境参数动态加载插件配置并执行部署。--- description: Deploy application to environment argument-hint: [environment] allowed-tools: Read, Bash(*) --- Deployment configuration for $1: ${CLAUDE_PLUGIN_ROOT}/config/$1-deploy.json Current git state: !git rev-parse --short HEAD Build info: !cat package.json | grep -E (name|version) Execute deployment to $1 environment using configuration above. Deployment checklist: 1. Validate configuration settings 2. Build application for $1 3. Run pre-deployment tests 4. Deploy to target environment 5. Run smoke tests 6. Verify deployment success 7. Update deployment log Report deployment status and any issues encountered.要点拆解配置文件名本身由参数插值生成config/$1-deploy.json同一命令对不同环境如staging、prod自动加载不同配置无需复制命令文件!反引号动态采集 git 提交号与 package.json 版本信息作为部署执行的上下文快照部署清单将验证配置 → 构建 → 预部署测试 → 部署 → 冒烟测试 → 确认 → 记录日志固化为步骤保证每次部署行为一致。模式 6Agent 集成commands/deep-review.md适用场景把复杂审查任务委托给插件自带的 Agent。--- description: Deep code review using plugin agent argument-hint: [file-or-directory] --- Initiate comprehensive code review of $1 using the code-reviewer agent. The agent will perform: 1. **Static analysis** - Check for code smells and anti-patterns 2. **Security audit** - Identify potential vulnerabilities 3. **Performance review** - Find optimization opportunities 4. **Best practices** - Ensure code follows standards 5. **Documentation check** - Verify adequate documentation The agent has access to: - Plugins linting rules: ${CLAUDE_PLUGIN_ROOT}/config/lint-rules.json - Security checklist: ${CLAUDE_PLUGIN_ROOT}/checklists/security.md - Performance guidelines: ${CLAUDE_PLUGIN_ROOT}/docs/performance.md Note: This uses the Task tool to launch the plugins code-reviewer agent for thorough analysis.要点拆解按 SKILL.md 的说明Agent 必须存在于插件的agents/目录Claude 会通过 Task 工具自动拉起该 Agent命令中明确写出 Agent 的审查维度静态分析、安全审计、性能、最佳实践、文档即文档化 Agent 能力同时列出 Agent 会使用的插件资源路径让 Claude 知道该把哪些文件交给 Agent。模式 7Skill 集成commands/document-api.md适用场景借助插件 Skill 携带的领域知识完成专项任务。--- description: Document API following plugin standards argument-hint: [api-file] --- API source code: $1 Generate API documentation following the plugins API documentation standards. Use the api-documentation-standards skill to ensure: - **OpenAPI compliance** - Follow OpenAPI 3.0 specification - **Consistent formatting** - Use plugins documentation style - **Complete coverage** - Document all endpoints and schemas - **Example quality** - Provide realistic usage examples - **Error documentation** - Cover all error scenarios The skill provides: - Standard documentation templates - API documentation best practices - Common patterns for this codebase - Quality validation criteria Generate production-ready API documentation.要点拆解Skill 必须定义在插件的skills/目录命令中按名称提及 SkillUse the api-documentation-standards skill即触发其调用命令同时说明Skill 提供什么模板、最佳实践、代码库常见模式、质量校验标准让 Claude 明确知道能从 Skill 中获得什么避免调用后空转。模式 8多组件复合工作流commands/complete-review.md适用场景同一命令内串起脚本、Agent、Skill、模板四类组件执行多阶段深度审查。--- description: Comprehensive review using all plugin components argument-hint: [file-path] allowed-tools: Bash(node:*), Read --- Target file: $1 Execute comprehensive review workflow: **Phase 1: Automated Analysis** Run plugin analyzer: !node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js $1 **Phase 2: Deep Review (Agent)** Launch the code-quality-reviewer agent for detailed analysis. Agent will examine: - Code structure and organization - Error handling patterns - Testing coverage - Documentation quality **Phase 3: Standards Check (Skill)** Use the coding-standards skill to validate: - Naming conventions - Code formatting - Best practices adherence - Framework-specific patterns **Phase 4: Report Generation** Template: ${CLAUDE_PLUGIN_ROOT}/templates/review-report.md Compile all findings into comprehensive report following template. **Phase 5: Recommendations** Generate prioritized action items: 1. Critical issues (must fix) 2. Important improvements (should fix) 3. Nice-to-have enhancements (could fix) Include specific file locations and suggested changes for each item.要点拆解五个 Phase 分工清晰脚本做自动分析、Agent 做深度审查、Skill 做标准校验、模板定报告格式、最后输出按优先级排序的行动项优先级分类must fix / should fix / could fix让输出直接可执行且要求包含具体文件位置和建议改动保证结论可落地这是 SKILL.md 中多组件工作流一节描述的推荐用法复杂多步任务、需要多能力叠加、需要结构化输出时采用。模式 9带输入校验的命令commands/build-env.md适用场景执行前校验参数格式与资源存在性失败时给出友好提示。--- description: Build for specific environment with validation argument-hint: [environment] allowed-tools: Bash(*) --- Validate environment argument: !echo $1 | grep -E ^(dev|staging|prod)$ echo VALID || echo INVALID Check build script exists: !test -x ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh echo EXISTS || echo MISSING Verify configuration available: !test -f ${CLAUDE_PLUGIN_ROOT}/config/$1.json echo FOUND || echo NOT_FOUND If all validations pass: **Configuration:** ${CLAUDE_PLUGIN_ROOT}/config/$1.json **Execute build:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/build.sh $1 21 **Validation results:** !bash ${CLAUDE_PLUGIN_ROOT}/scripts/validate-build.sh $1 21 Report build status and any issues. If validations fail: - Explain which validation failed - Provide expected values/locations - Suggest corrective actions - Document troubleshooting steps要点拆解三层校验各司其职grep -E校验参数枚举值dev/staging/prod、test -x校验脚本可执行、test -f校验配置文件存在命令明确写出校验通过与校验失败两个分支的后续行为。失败分支要求 Claude 说明哪一步失败、给出期望值与位置、建议修正动作、记录排障步骤这正是 plugin-features-reference.md 中优雅错误处理Graceful Error Handling的落地形态21把 stderr 并入 stdout确保 Claude 能拿到完整报错文本。模式 10环境感知命令commands/run-checks.md适用场景根据环境参数自适应调整检查深度与通过标准。--- description: Run environment-appropriate checks argument-hint: [environment] allowed-tools: Bash(*), Read --- Environment: $1 Load environment configuration: ${CLAUDE_PLUGIN_ROOT}/config/$1-checks.json Determine check level: !echo $1 | grep -E ^prod$ echo FULL || echo BASIC **For production environment:** - Full test suite: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/test-full.sh - Security scan: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/security-scan.sh - Performance audit: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/perf-check.sh - Compliance check: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/compliance.sh **For non-production environments:** - Basic tests: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/test-basic.sh - Quick lint: !bash ${CLAUDE_PLUGIN_ROOT}/scripts/lint.sh Analyze results based on environment requirements: **Production:** All checks must pass with zero critical issues **Staging:** No critical issues, warnings acceptable **Development:** Focus on blocking issues only Report status and recommend proceed/block decision.要点拆解用一个!grep -E ^prod$ echo FULL || echo BASIC就地判定环境级别条件分支写在命令文本里由 Claude 执行不同环境的验收标准被显式量化生产零严重问题、预发可容忍警告、开发只看阻断性问题Claude 最终要给出通过/阻塞的明确建议命令产出可决策而非单纯罗列日志。三、插件命令通用模式速查十个示例沉淀出七种可复用模式总结如下完整内容见 plugin-commands.md 的 Common Patterns Summary 章节模式语法模板适用场景插件脚本执行!node ${CLAUDE_PLUGIN_ROOT}/scripts/script-name.js $1运行插件自带的 Node.js 脚本插件配置加载${CLAUDE_PLUGIN_ROOT}/config/config-name.json加载插件配置文件注入上下文插件模板使用${CLAUDE_PLUGIN_ROOT}/templates/template-name.md用插件模板作为生成基准Agent 调用Launch the [agent-name] agent for [task description].把复杂任务委托给插件 AgentSkill 引用Use the [skill-name] skill to ensure [requirements].借助 Skill 的领域知识输入校验!echo $1 \| grep -E ^pattern$ echo OK \| echo ERROR校验命令参数格式资源校验!test -f ${CLAUDE_PLUGIN_ROOT}/path/file echo YES \| echo NO确认插件所需文件存在补充说明 frontmatter 字段与这些模式的配合关系字段细则见 frontmatter-reference.mddescription/help中展示的一行简介建议 60 字符以内、以动词开头allowed-tools工具白名单可用逗号分隔或 YAML 数组Bash 建议配命令过滤器如Bash(git:*)、Bash(node:*)尽量不用裸Bash(*)读取型命令可用Read, Grep保持只读modelhaiku快而省适合简单命令/sonnet均衡默认/opus复杂分析argument-hint形如[environment] [version]用方括号标注每个参数与正文$1、$2位置顺序一一对应disable-model-invocation置true时禁止 SlashCommand 工具程序化调用仅允许用户手动输入触发适合生产审批、破坏性操作等需要人工判断的命令。四、开发与测试技巧4.1 测试插件命令在插件已安装的情况下测试cd /path/to/plugin claude /command-name args验证${CLAUDE_PLUGIN_ROOT}展开在命令中临时加入!echo Plugin root: ${CLAUDE_PLUGIN_ROOT}调试输出跨工作目录测试分别从/tmp与/other/project触发同一命令确认路径不依赖当前目录cd /tmp claude /command-name cd /other/project claude /command-name校验插件资源可用性!ls -la ${CLAUDE_PLUGIN_ROOT}/scripts/ !ls -la ${CLAUDE_PLUGIN_ROOT}/config/4.2 常见错误避坑错误 1使用相对路径而非${CLAUDE_PLUGIN_ROOT}# Wrong !node ./scripts/analyze.js # Correct !node ${CLAUDE_PLUGIN_ROOT}/scripts/analyze.js./相对的是触发命令时的工作目录而非插件目录换目录即失效。错误 2忘记在 allowed-tools 中放行所需工具# Missing allowed-tools !bash script.sh # Will fail without Bash permission # Correct --- allowed-tools: Bash(*) --- !bash ${CLAUDE_PLUGIN_ROOT}/scripts/script.sh错误 3不对输入做校验# Risky - no validation Deploy to $1 environment # Better - with validation Validate: !echo $1 | grep -E ^(dev|staging|prod)$ || echo INVALID Deploy to $1 environment (if valid)错误 4硬编码插件路径# Wrong - breaks on different installations /home/user/.claude/plugins/my-plugin/config.json # Correct - works everywhere ${CLAUDE_PLUGIN_ROOT}/config.json4.3 常见故障排查按 SKILL.md 的 Troubleshooting 章节命令不出现检查文件是否位于正确目录、后缀是否为.md、Markdown 格式是否合法重启 Claude Code参数不生效核对$1、$2语法与argument-hint顺序是否一致确认没有多余空格Bash 执行失败确认allowed-tools包含 Bash、反引号语法正确、先在终端手测命令、检查权限文件引用失败核对语法、文件路径有效性、allowed-tools是否放行 Read优先使用项目相对路径或绝对路径。五、仓库实战印证真实插件命令对照上述模式并非纸上谈兵本仓库多个正式插件已在生产命令中实践了相同写法可对照研读plugins/code-review/commands/code-review.md真实的高复杂度命令frontmatter 中allowed-tools精确到Bash(gh issue view:*)、Bash(gh pr view:*)等细粒度 gh 子命令过滤器正文则是一个完整的多 Agent 工作流Haiku Agent 做资格预检、并行 Sonnet Agent 审查、Haiku Agent 置信度打分、过滤后回帖体现了命令是写给 Claude 的指令而非写给用户的说明这一核心原则plugins/hookify/commands/hookify.md演示了$ARGUMENTS与条件分支参数为空时改用 Task 工具拉起 conversation-analyzer Agent、AskUserQuestion 交互、以及通过!反引号执行校验命令如test、python3 -c验证正则的完整链路plugins/plugin-dev/commands/create-plugin.md以$ARGUMENTS接收初始请求通过 TodoWrite 跟踪七个阶段进度并在 Phase 4 中直接用${CLAUDE_PLUGIN_ROOT}引用插件自身资源如加载各开发技能plugins/example-plugin/commands/example-command.md一个演示 frontmatter 选项的极简命令模板description、argument-hint、allowed-tools并同样标注了commands/为遗留格式的说明。六、结语插件命令的写作准则综合本文十个模式与仓库内真实实现插件命令写作可以收敛为四条准则写给 Claude不是写给用户命令正文是给 Agent 的指令要写审查 X 并报告而非本命令会审查 X插件内部路径一律走${CLAUDE_PLUGIN_ROOT}脚本、配置、模板、资源全部以此变量定位杜绝相对路径与硬编码先校验后执行参数枚举、文件存在性、脚本可执行性都要在执行前确认失败分支写明原因、期望值与修正建议按需组合插件组件简单任务用脚本复杂分析委托 Agent专项知识调用 Skill标准化输出套模板——用最小复杂度达成目标同时保持权限收敛尽量使用Bash(node:*)这类命令过滤器而非Bash(*)。进一步深入可继续阅读同目录下的 simple-commands.md基础命令模式、advanced-workflows.md高级工作流、testing-strategies.md测试策略以及 interactive-commands.md交互式命令并结合 SKILL.md 主文档形成完整知识体系。赞分享AI 插件开发工具插件系统【免费下载链接】claude-plugins-officialOfficial, Anthropic-managed directory of high quality Claude Code Plugins.项目地址https://gitcode.com/GitHub_Trending/cl/claude-plugins-official点击查看免费下载相关推荐SuperGradients 安装指南环境要求、PyPI 快速安装与 GPU 配置SuperGradients 安装指南环境要求、PyPI 快速安装与 GPU 配置 SuperGradientsSG是 Deci 开源的一站式计算机视觉训AI 插件开发工具插件系统YOLOv10 跑通 RF100Roboflow 100多领域检测基准数据配置 训练验证实战指南YOLOv10 跑通 RF100Roboflow 100多领域检测基准数据配置 训练验证实战指南 RF100Roboflow 100是 Robof人工智能深度学习计算机视觉Claude Code 斜杠命令Slash Command开发完全指南文件格式、Frontmatter 配置与插件集成实战Claude Code 斜杠命令Slash Command开发完全指南文件格式、Frontmatter 配置与插件集成实战 本文基于 Claude CodAI 应用AI 技能/插件开发工具上一篇DSEFix完全指南如何在Windows x64系统中禁用驱动签名强制下一篇如何在EmbodiedScan上参加CVPR视觉定位挑战赛数据申请、结果提交与评分全流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考