实测Anthropic官方插件claude-code-setup：零配置仓库也能生成量身定制的Hooks与Skills

当一个Chrome扩展项目几乎没有Claude Code配置时，AI能否给出真正有用的自动化建议？作者在自建的netflix-intro-skipper扩展上实测了Anthropic官方插件claude-code-setup，结果值得关注。

claude-code-setup插件是什么

claude-code-setup是Anthropic在Claude插件市场上架的官方已验证插件，定位是分析代码库并推荐贴合项目的Claude Code自动化配置。

它的推荐范围覆盖五类：Hooks、Subagents、Skills、MCP Servers和Plugins。关键设计是只读——它从不创建或修改任何文件，因此可以放心在已有仓库上试用。默认每个类别只给1-2条建议，当你明确要求某一类别时，会扩展到3-5条。

判断技术栈的方式并不神秘：读取package.json和目录结构等文件，推断项目类型和工具链。

Claude Code 配置的五类载体：Hooks 是生命周期事件（如 PreToolUse、PostToolUse）触发的 shell 命令，用于强制执行检查或拦截危险操作；Subagents 是拥有独立上下文窗口与工具权限的子代理，适合隔离特定审查任务；Skills 是封装可复用流程或领域知识的指令包，可设为用户触发或由 Claude 自主调用；MCP Servers 通过 Model Context Protocol 为 Claude 接入外部工具与数据源（如浏览器自动化、文档检索）；Plugins 则是打包分发上述能力的市场单元。理解这五者的分工，才能判断插件给出的建议应落地为哪种形态。

测试对象：一个近乎零配置的仓库

netflix-intro-skipper是作者自建的Chrome扩展，支持Manifest V3，用于自动跳过Netflix片头。技术特征如下：

• 纯JavaScript，无构建步骤
• 测试使用Jest与fast-check（属性测试），共13个测试文件，约6000行测试代码
• 没有CLAUDE.md，.claude/目录下只有一个settings.local.json
• 规格文档存放在.kiro/specs/
• src/content.js高达2720行，是项目中最大的文件

正因为几乎没有Claude Code配置，这个项目恰好适合检验插件推荐的质量。

安装与使用流程

在目标仓库中启动Claude Code，从市场安装插件：

/plugin install claude-code-setup@claude-plugins-official

安装后可在/plugins的Installed标签页确认。随后用一句英文提示词请求分析：

Analyze this project and recommend Claude Code automations (hooks, skills, MCP servers, subagents, plugins) that fit it.

插件返回了完整的推荐报告，包括代码库画像、各分类建议和实施位置。

推荐结果里的几个亮点

Hooks：围绕真实痛点设计

第一条建议是PostToolUse钩子：每次编辑src/下的文件后，自动运行npx jest --findRelatedTests只跑相关测试。理由直白——content.js有2720行，小改动也可能引发回归，全量测试又太慢。

第二条是PreToolUse钩子：阻止直接编辑版本管理相关文件（manifest.json、src/version.js、package-lock.json、coverage/）。因为项目通过npm run version:*同步三个文件的版本号，手工修改会造成不同步。

Skills：把流程和领域知识固化下来

插件建议创建两个Skill：release（仅用户触发，因为发布有副作用，需要dry-run再升版本再打标签）和netflix-dom-check（Claude-only背景知识，汇总Netflix DOM选择器列表、.kiro/specs中的需求以及更新后应检查的测试）。后者切中这类扩展最常见的失效原因——Netflix DOM变更。

Subagents：连历史PR都被纳入了分析

插件推荐了extension-security-reviewer（针对MV3扩展的大量host_permissions、content.js的DOM操作XSS风险、消息传递校验缺失）和service-worker-reviewer。后者的依据是仓库中PR #1曾修复PC休眠后的Service Worker问题，针对状态持久化、alarms和重启恢复做专项审查。

MCP与插件：补齐真实浏览器验证

推荐Playwright MCP的理由是Jest运行在jsdom上，无法验证真实popup UI和内容脚本行为；context7则提供Chrome Extension API、Jest、fast-check的最新文档。插件方面提到commit-commands和frontend-design，后者优先级较低。

npx jest --findRelatedTests 的作用机制：该参数让 Jest 依据 Git 变更文件反向解析依赖图，只运行与改动文件存在导入关系的测试文件，而非整个测试套件。对于包含 2720 行 content.js 且测试代码约 6000 行的项目，这能把每次编辑后的验证从分钟级压缩到秒级，同时仍覆盖直接受影响的用例。它依赖 Jest 的模块依赖分析，因此对通过动态 require 或全局脚本注入建立的隐式依赖覆盖有限，属于快速反馈而非全量回归保障。

关键结论

这份推荐最有价值的地方在于：几乎每条建议都能追溯到仓库中的具体事实——文件大小、脚本逻辑、PR历史。它没有给出泛泛而谈的通用清单。

同时要注意，插件只输出建议，不做任何改动。落地需要你手动放置配置，或另外请Claude Code创建。插件自己给出的第一条建议是先创建CLAUDE.md，记录npm test的运行方式、版本同步规则和.kiro/specs的作用，/init可以生成草稿。

对于不知道该从什么配置入手的项目，这个只读、无副作用的插件是一个低成本的起点。