Node Modules Inspector 依赖体检技能
审计项目已安装的 node_modules：找出重复安装的包、磁盘占用大户，以及可升级或存在 publint 问题的依赖。
SKILL.md 描述只读分析本地 node_modules，无网络注册表写入、无凭证访问、无删除操作；npm 元数据抓取被 config 门控并明确披露，缓存写入 ~/.node-modules-inspector 也已说明。扣分：依赖经 npx 从 npm 分发且发布者身份未经注册表验证，技能本身未声明确认/回滚机制。
文档内部自洽（CLI/MCP 接口一致、JSON 输出形状明确、stderr 分流保证管道安全），失败模式章节给出三种异常的可解释反馈；仓库含 vitest 测试（bun 依赖列举 fixtures、模块类型快照）与跨平台 CI。扣分：静态审查未执行，report 子命令输出未经复现，测试未直接覆盖 report/mcp 表面。
触发词、非适用边界（明确排除 registry-only、bundle 分析、安全审计）写得非常清晰，支持 pnpm/npm/bun。扣分：文档仅英文，无中文支持声明；未验证中国网络环境下 npx/npm 依赖获取的可达性，maintainers 报告依赖 npm 元数据抓取可能受网络影响。
分层良好：frontmatter 摘要→表格→逐报告细节→MCP→失败模式→Web UI 递进披露；MIT 许可明确、版本 2.4.4、活跃 CI、skill 经 prepack 打包并有清晰更新路径。扣分：无 changelog 证据，部分配置（publint 实验性、config 细节）需读者自行查 jsdoc。
三个报告目标明确、输出 JSON 形状与选项文档完整，相较手工检查 node_modules 有明显边际价值，并给出 dedupe 等后续动作指引。扣分：静态审查无法验证输出可直接使用，效果声明未被执行证据佐证，受静态上限约束。
仓库提供可审计一手材料：MIT 许可、CI 工作流、针对核心管道（依赖列举、模块类型）的提交测试与 fixtures。扣分：测试未覆盖技能关键路径（report CLI/MCP 工具输出），静态审查未能独立复现，多源交叉验证有限，故不超过静态上限。
- 未执行验证：所有报告输出形状仅为文档声明，使用前应先在测试项目中实际运行 report -- 核对。
- 技能依赖通过 npx 运行第三方 npm 包，供应链完整性取决于 npm 分发；发布者身份未经 FollowSkills 验证。
- maintainers 报告会抓取 npm 元数据并缓存到用户目录，中国网络环境下可能不可达或变慢；publint 需在配置中显式开启。
- 文档为英文且未声明中文环境适配；在线版本 node-modules.dev 依赖 WebContainer，可能在部分网络不可用。
这个 Skill 能做什么，适合哪些场景？
node-modules-inspector 是 Anthony Fu 开源的 MIT 工具，用于检查当前项目实际落盘的 node_modules。它提供三份结构化报告：duplicates（多版本重复安装的包）、sizes（按安装体积排序）、maintainers（按消费方/作者归类的升级机会与 publint 发现）。既可通过 `npx node-modules-inspector report ... --` 在命令行调用，也可作为 MCP stdio 服务器暴露三个同名工具，支持 pnpm、npm 和 bun 项目。基础分析只需读取本地磁盘，无需访问注册表；maintainers 报告的 npm 元数据增强需在配置中显式开启。
读取当前项目的 node_modules 目录（配合 pnpm/npm/bun lockfile 解析依赖树），然后产出三份报告：1) duplicates：列出安装了多个版本的包及其版本列表，默认仅含 2 个以上版本的包；2) sizes：按字节数降序排列各包的安装体积，并按 js/dts/wasm 等固定类别细分，默认排除 workspace 包；3) maintainers：按包和 GitHub 作者分组，报告 dep-upgrade 机会（声明的范围与已安装的最高版本不匹配，含迁移比例）和 publint 发现（需在配置中设 publint: true）。输出默认是 ANSI 表格，加 -- 则输出纯 JSON 到 stdout，进度日志走 stderr。也可通过 npx node-modules-inspector mcp 启动 MCP 服务器，暴露 nmi:report-duplicates、nmi:report-sizes、nmi:report-maintainers 三个工具。
- 前端开发者发现 node_modules 异常庞大，想找出哪些包占空间最多，再决定是否清理或瘦身
- pnpm 项目想确认是否可以安全运行 `pnpm dedupe`，先用 duplicates 报告查看哪些包确实存在多版本
- 维护者在升级依赖前想知道哪些消费方还在用旧版本，以及同一批次的迁移比例有多高，判断升级优先级
- 开源包作者想批量检查自己维护的包是否存在 publint 警告
- AI 编码代理在会话中需要多次查询依赖信息，通过 MCP 模式复用一次读取的依赖树缓存
- CI 中需要生成依赖审计的 JSON 产物，用 -- 管道输出给 jq 等工具处理
这个 Skill 有哪些优点和局限？
- 三份报告共用同一条分析管线，CLI 与 MCP 工具输入输出完全一致
- 基于真实落盘的 node_modules 分析，基础报告无需注册表请求，结果即所见即所装
- 输出对管道友好：-- 走 stdout，日志走 stderr，可直接接 jq
- 首次运行后缓存 npm 元数据，后续运行明显更快
- 同时支持 pnpm、npm、bun 三大包管理器，作者 antfu 是知名开源维护者，MIT 许可
- 不支持 yarn 等其他包管理器，社区贡献前仅限 pnpm/npm/bun
- publint 发现和 maintainers 报告的完整数据需要在配置文件中显式开启 publint: true，默认为关
- maintainers 报告的作者信息依赖 package. 的 author/maintainers 字段与 GitHub handle 识别，可能缺失
- 超大型 monorepo 全仓库分析较慢，需手动指定 --root 到单个 workspace 包来提速
- 不适用于注册表查询、单包 bundle 体积分析或安全审计等相邻场景，需另选工具
如何安装这个 Skill？
无需单独安装技能文件夹：将 skills/node-modules-inspector/ 目录复制到你的 Agent Skills 目录即可；若项目使用 skills-npm，安装 node-modules-inspector 包后技能会自动符号链接到 agent 的技能目录。底层 CLI 通过 npx/pnpx/bunx 按需运行，无需全局安装。验证方式：在任意已有 node_modules 的项目里运行 npx node-modules-inspector report duplicates --。
如何使用这个 Skill？
在已安装依赖的项目根目录下直接触发，例如对代理说："找出我 node_modules 里重复安装的包" 或 "哪些依赖占磁盘最多？"。手动调用示例：npx node-modules-inspector report duplicates -- | jq '.[].name'；npx report sizes -- --limit 20；npx node-modules-inspector report maintainers -- --sort migration。MCP 模式：npx node-modules-inspector mcp 作为 stdio 服务器接入 MCP 客户端。常用选项：--root <dir>、--config <file>、--depth <n>（默认 8）、--limit <n>。不带子命令运行 npx node-modules-inspector 会打开面向人类的 Vue Web UI（端口 9999），代理任务应避免使用。
这个 Skill 与同类方案有什么区别？
README 明确说明本项目的灵感来源是 npmgraph（在线的 npm 依赖图可视化）；SKILL.md 还指出：注册表查询类问题应改用 fast-npm-meta，安全审计应使用 npm audit 或 osv-scanner，单包 bundle 体积分析应使用特定打包工具。