名称：生态系统健康描述：通过跟踪6个层级中的27个可扩展性组件来分析Claude Code生态系统的健康状态，包括插件组件、核心配置、环境/CLI、身份验证、会话功能和集成。用于检查Claude Code组件是否最新、高效协调审计、跟踪文档覆盖、应用新Claude Code版本的更新，或获取生态系统组件过时情况的概述。参数提示：[–status | --check | --audit [类型] | --audit-all | --apply | --validate | --audit-required | --since <版本> | --discover] 允许工具：Read, Write, Bash, Glob, Grep, Skill, Task

生态系统健康

强制：文档管理委托

关键： 此技能遵循反重复原则。所有组件详细信息必须在运行时从文档管理查询。

此技能硬编码的内容（静态 - 很少更改）

数据	为什么静态
层级结构（1-6）	设计决策，架构选择
审计技能（`/audit-*`）	我们在claude-ecosystem插件中的技能
审计类型（自动/手动/文档）	分类策略
评分/优先级逻辑	策略决策

必须委托的内容（动态 - 随版本更改）

数据	为什么动态	如何获取
CLI标志列表	每个版本新增标志	查询：`docs-management: cli-reference.md CLI标志`
环境变量	新增环境变量频繁	查询：`docs-management: settings.md 环境变量`
身份验证方法	新增提供商	查询：`docs-management: iam.md 身份验证方法`
权限模式	模式演进	查询：`docs-management: iam.md 权限模式`
云提供商	新增提供商	查询：`docs-management: setup.md 云提供商`
IDE集成	新增集成	查询：`docs-management: third-party-integrations.md IDE`
变更关键词	术语演进	从文档管理索引关键词派生
文件模式	位置可更改	查询官方文档获取当前模式

委托规则

切勿使用硬编码列表 用于CLI标志、环境变量、身份验证方法、云提供商、IDE集成、权限模式或任何频繁更改的数据
始终查询文档管理 当需要组件详细信息时
使用claude-code-guide代理 在--discover和--check模式下进行实时验证
如果文档管理返回空，这是检查组件是否仍存在的信号

文档管理查询模式

# 层级 3：环境与 CLI
"cli-reference.md CLI标志"              → 获取当前CLI标志列表
"settings.md 环境变量"       → 获取当前环境变量列表
"iam.md 权限模式"                 → 获取当前权限模式

# 层级 4：身份验证与访问
"iam.md 身份验证方法"           → 获取当前身份验证方法
"iam.md 配置权限"          → 获取权限规则模式
"iam.md 凭证管理"            → 获取凭证功能

# 层级 5：会话与运行时
"cli-reference.md 会话功能"       → 获取会话功能（恢复、检查点）
"security.md 沙箱配置"       → 获取沙箱设置

# 层级 6：集成
"third-party-integrations.md IDE"         → 获取IDE集成列表
"setup.md 云提供商"                → 获取云提供商列表
"common-workflows.md CI/CD"               → 获取CI/CD平台

# 变更日志用于变更分类
"CHANGELOG 最近变更"                → 获取变更日志条目

概述

此技能跟踪Claude Code生态系统健康状态跨所有可扩展点 - 不仅仅是插件组件。它监控6个层级中的27种组件类型。

架构v2.2 引入了分层验证模型用于变更日志触发的审计过时性：

次要变更（功能、弃用） → 目标关键词验证（低成本）
主要变更（行为变更、安全） → 需要完整审计（无捷径）
错误修复 → 无需验证

此方法提供60-96%的令牌节省，同时保持严格的准确性要求。

组件层级

层级	类别	组件	审计类型	描述
1	核心配置	4	混合	用户、项目和企业设置
2	插件组件	12	自动	插件中打包的组件
3	环境与 CLI	3	文档	环境变量、CLI标志、权限模式
4	身份验证与访问	3	混合	身份验证方法、权限规则
5	会话与运行时	2	混合	会话功能、沙箱配置
6	集成	3	文档	IDE、云提供商、CI/CD

审计类型解释

类型	描述	有审计命令？	跟踪方法
`automated`	通过`/audit-*`技能的完整审计	是	通过率、组件计数
`manual`	需要人工审查	否	人工审查跟踪
`documentation`	仅跟踪文档覆盖	否	通过文档管理查询的文档覆盖

分层验证模型（v2.2）

架构v2.2引入了三层验证模型，当变更日志变更影响组件时自动使审计无效，同时使用最适合每种变更类型的令牌高效验证方法。

变更严重性分类

变更类型	严重性	验证要求	理由
`feature`	次要	目标验证（关键词检查）	新功能可以通过检查关键词存在来验证
`deprecation`	次要	目标验证（关键词检查）	弃用可以通过检查警告文档来验证
`bugfix`	无	无需验证	错误修复不影响插件文档/合规性
`behavior_change`	主要	需要完整审计	行为变更可能有广泛影响
`security`	主要	需要完整审计	安全变更需要全面审查

验证层级

层级 1：目标验证（次要变更）

对于feature和deprecation变更：

方法： 基于grep的关键词验证
证据： 文件路径、行号、匹配文本
成本： ~100-500 令牌每变更
通过状态： VALIDATED

算法：

1. 从granular_changelog变更条目加载验证规范
2. 对于validation.keywords中的每个关键词：
   a. 对target_skill目录运行grep
   b. 如果找到匹配，记录证据（文件、行、匹配文本）
3. 如果匹配数 >= required_matches：
   a. 设置validation_result.validated = true
   b. 基于匹配数设置置信度：
      - 1 匹配 = "medium"
      - 2+ 匹配 = "high"
4. 更新component_coverage验证跟踪

层级 2：完整审计（主要变更）

对于behavior_change和security变更：

方法： 生成审计代理
审计命令： 在validation.audit_command中指定
成本： ~3,000-8,000 令牌
通过状态： AUDITED

重要： 主要变更不能通过目标验证。系统必须强制执行此规则 - 无捷径。

层级 3：定期审查

无论验证状态如何：

阈值： >90 天自上次完整审计
操作： 触发完整审计
理由： 确保随时间无漂移

验证规范架构（v2.2）

granular_changelog中的每个变更可以有验证规范：

validation:
  method: "keyword_check"           # keyword_check | full_audit | manual | none
  target_skill: "hook-management"   # 要验证的技能（null用于内存文件）
  keywords:                         # 手动列表 - 切勿自动提取
    - "additionalContext"
    - "additional context"
    - "PreToolUse.*additionalContext"  # 支持正则表达式
  required_matches: 1               # 必须匹配的关键词数
  reason: "..."                     # 可选解释（特别是method: none时）

# 对于full_audit方法：
validation:
  method: "full_audit"
  target_skill: "permission-management"
  audit_command: "/audit-settings"
  reason: "安全修复 - 目标验证不足"

验证结果架构

验证运行后，结果记录如下：

validation_result:
  validated: true                   # 验证是否通过？
  validated_date: "2026-01-16"      # 验证日期
  evidence:                         # 对于keyword_check方法
    - file: "path/to/file.md"
      line: 142
      match: "matched text"
  audit_performed: true             # 对于full_audit方法
  audit_date: "2026-01-12"          # 审计运行日期
  confidence: "high"                # high | medium | low

状态计算（保守）

组件状态由此优先级顺序确定（首次匹配获胜）：

优先级	条件	状态
1	有`pending_major_changes`	`NEEDS AUDIT` ⚠️
2	有`pending_minor_changes`	`NEEDS VALIDATION`
3	`days_since(last_audit) > 90`	`STALE`
4	`validation_version == latest AND validation_confidence == "high"`	`VALIDATED`
5	`last_audit` 最近且无待处理变更	`OK`
6	从未审计	`UNKNOWN`

保守规则： 如果存在任何疑问，升级到更高要求。

验证准确性规则（关键）

系统绝不能报告“已验证”，除非确定。这些规则不可协商。

规则 1：关键词匹配必须在上下文中正确

❌ 查找“context”时找到“context: fork”不是匹配
✅ 必须匹配精确关键词或正则表达式模式

规则 2：优选多个证据

证据数	置信水平
0 匹配	`validation_failed: true`
1 匹配	`confidence: "medium"`
2+ 匹配	`confidence: "high"`

规则 3：边界情况需要人工确认

如果置信度为"low"：

标记为人工审查
切勿自动标记为已验证
包含在--apply输出中以供用户决策

规则 4：证据是强制的

无捕获证据则无验证
证据必须包括文件路径和行号
空证据 = 验证失败

规则 5：主要变更不能使用目标验证

❌ 安全变更 → keyword_check（禁止）
❌ 行为变更 → keyword_check（禁止）
✅ 安全变更 → full_audit（必需）
✅ 行为变更 → full_audit（必需）

系统必须拒绝为目标验证使用主要变更的尝试。

此技能提供：

解析变更日志以识别新功能和变更
跟踪审计覆盖跨所有27种组件类型
文档覆盖用于非可审计组件（从文档管理查询）
识别待处理更新以保持合规性
高效协调审计（避免令牌浪费）
帮助应用更新从新Claude Code版本

何时使用此技能

使用此技能当：

检查任何Claude Code可扩展性组件是否最新
获取所有层级的审计覆盖和过时性概述
跟踪非可审计组件的文档覆盖
计划运行哪些审计（令牌高效方法）
在Claude Code发布新版本后应用更新
准备插件发布
检测新/弃用的Claude Code功能

跟踪文件

位置： .claude/ecosystem-health.yaml

此文件在会话间持久化生态系统健康状态。它存储仅审计元数据 - 非组件详细信息（这些委托给文档管理）。

架构v2.1结构：

schema_version: "2.1"

last_check:
  date: "YYYY-MM-DD"
  claude_code_version: "X.Y.Z"
  changelog_hash: "sha256:..."

component_coverage:
  # 层级 1：核心配置
  tier1_configuration:
    user_settings:
      last_audit: null
      components_audited: 0
      pass_rate: null
      audit_type: "manual"
      # 查询文档管理：settings.md 用户配置
    project_settings:
      last_audit: "YYYY-MM-DD"
      components_audited: N
      pass_rate: 0.XX
      audit_type: "automated"
      audit_command: "/audit-settings"
    managed_settings: { ... }
    memory_system: { ... }

  # 层级 2：插件组件（12个组件）
  tier2_plugins:
    skills: { audit_type: "automated", audit_command: "/audit-skills" }
    agents: { audit_type: "automated", audit_command: "/audit-agents" }
    # ...（12个组件，每个有audit_type和audit_command）

  # 层级 3-6：文档跟踪（委托给文档管理）
  tier3_environment:
    environment_variables:
      audit_type: "documentation"
      # 委托：查询文档管理：settings.md 环境变量
    cli_flags: { ... }
    permission_modes: { ... }

  tier4_authentication: { ... }
  tier5_session: { ... }
  tier6_integration: { ... }

changelog_versions_checked:
  - version: "X.Y.Z"
    checked_date: "YYYY-MM-DD"
    changes_applied: true/false

pending_updates:
  - feature: "功能名称"
    since_version: "X.Y.Z"
    affects: ["skills", "commands"]
    status: "pending" | "applied" | "skipped"

last_discovery:
  date: "YYYY-MM-DD"
  docs_scanned: [...]
  changelog_version: "X.Y.Z"
  components_detected: 27
  tiers_scanned: 6
  gaps_found: 0

关键设计决策： 跟踪文件不包含tracked_*数组（无硬编码的环境变量、CLI标志、身份验证方法等列表）。所有此类数据必须在运行时从文档管理查询。

变更日志访问

强制： 通过docs-management技能访问变更日志。

文档ID： raw-githubusercontent-com-anthropics-claude-code-refs-heads-main-CHANGELOG

访问模式：

python plugins/claude-ecosystem/skills/docs-management/scripts/core/find_docs.py \
  content raw-githubusercontent-com-anthropics-claude-code-refs-heads-main-CHANGELOG

版本提取

解析变更日志以获取版本条目：

模式： ^##\s*\[?(\d+\.\d+\.\d+)\]?
示例：
  "## 2.1.3" → 版本 2.1.3
  "## [2.1.0]" → 版本 2.1.0

变更分类

映射变更日志关键词到所有6个层级的组件类型。

重要： 切勿使用硬编码关键词列表。通过索引查询文档管理获取当前关键词，然后将变更日志条目与这些关键词匹配。

分类算法

按文档部分查询文档管理索引以获取关键词列表
对于每个变更日志条目： a. 与相关文档部分的关键词匹配 b. 基于匹配的文档分配层级 c. 记录受影响的组件

层级到文档映射

层级	组件	查询文档管理获取
1	user_settings, project_settings, managed_settings, memory_system	settings.md, iam.md, memory.md
2	skills, agents, hooks, mcp, memory, plugins, settings, output_styles, statuslines, rules, lsp	skills.md, sub-agents.md, hooks.md, mcp.md, memory.md, plugins-reference.md, terminal-config.md
3	environment_variables, cli_flags, permission_modes	settings.md, cli-reference.md, iam.md
4	authentication_methods, permission_rules, credential_management	iam.md
5	session_features, sandbox_configuration	cli-reference.md, security.md
6	ide_integrations, cloud_providers, cicd_integrations	third-party-integrations.md, setup.md, common-workflows.md

详细分类模式见references/change-categories.md。

操作模式

状态模式（默认 / --status）

显示当前生态系统健康状态，无需运行审计。显示所有6个层级。

算法：

加载跟踪文件（如果缺失则显示“从未检查”）
读取所有6个层级中每个组件的审计数据
计算过时性（自上次审计/审查以来的天数）
按层级显示摘要表和推荐

检查模式（–check）

比较当前变更日志与上次检查。识别所有层级的变更。

算法：

加载跟踪文件
通过文档管理获取变更日志
计算变更日志哈希
如果哈希与跟踪哈希不同： a. 解析自上次检查以来的新版本 b. 查询文档管理获取当前关键词映射 c. 按层级分类变更 d. 添加待处理更新并包含层级信息
生成claude-code-guide代理用于新功能的实时验证
更新跟踪文件
按层级报告发现

审计模式（–audit [类型]）

智能运行审计。仅适用于层级2组件（自动审计）。

无类型参数： 审计所有过时/从未审计的层级2组件 有类型参数： 仅审计指定类型

优先级顺序：

从未审计（优先级1）
受近期变更日志变更影响（优先级2）
过时 >90 天（优先级3）

批处理：

每批最多3个审计
在批次间呈现结果
允许用户继续或停止

审计命令映射（仅层级2）：

组件	审计命令
skills	`/audit-skills`
agents	`/audit-agents`
hooks	`/audit-hooks`
mcp	`/audit-mcp`
memory	`/audit-memory`
plugins	`/audit-plugins`
settings	`/audit-settings`
output_styles	`/audit-output-styles`
statuslines	`/audit-statuslines`
rules	`/audit-rules`
lsp	`/audit-lsp`

合规审计（交叉）：

审计类型	审计命令	描述
docs-delegation	`/audit-docs-delegation`	审计技能和内存文件以检查正确的文档管理委托模式
agent-consolidation	`/audit-agent-consolidation`	分析代理以寻找整合机会，按配置分组，跟踪引用

文档覆盖模式（–doc-coverage）

跟踪非可审计组件（层级3-6）的文档覆盖。

算法：

加载跟踪文件
对于每个文档跟踪组件： a. 查询文档管理获取官方文档部分 b. 从文档内容提取当前功能列表 c. 报告覆盖状态
无硬编码列表 - 所有数据来自文档管理查询

注意： 覆盖始终基于当前文档管理内容。没有“跟踪列表”来比较 - 文档管理是真相来源。

应用模式（–apply）

交互式模式以应用待处理更新。

对于每个待处理更新：

显示Claude Code中的变更内容
显示受影响的层级
加载相关开发技能
在代码库中搜索受影响的模式
呈现受影响的文件
询问用户操作：
- 显示详细变更
- 自动应用变更
- 跳过此更新
- 标记为已应用

自模式（–since <版本>）

显示自特定版本以来的所有变更，按层级组织。

算法：

获取变更日志
解析自指定版本到当前的条目
查询文档管理获取关键词映射
按层级分类所有变更
按层级呈现摘要

重叠模式（–overlap）

检测插件重叠、冗余和整合机会。

算法：

枚举所有插件：
- Glob所有plugins/*/目录
- 读取每个插件的清单和README
提取组件名称：
- 对于每个插件，从skills/*/SKILL.md提取技能名称
- 从agents/*.md提取代理名称
检测重复项：
- 查找出现在多个插件中的技能名称
- 查找出现在多个插件中的代理名称
语义重叠分析：
- 比较插件描述的语义相似度 >70%
- 比较同一领域的技能描述
- 标记覆盖相同方法的插件
已发布标准检测：
- 对于每个插件，检查方法是否为已发布标准
- 查询perplexity：“Is {methodology} a published standard?”
- 已发布标准：ISO 25010, CRISP-DM, BABOK, Design Thinking, TOGAF, WCAG, etc.
- 标记仅包装已发布标准且无独特价值的插件
生成重叠报告：

## 插件重叠分析

**发现的重复组件：**

| 组件 | 类型 | 插件 |
| --------- | ---- | ------- |
| adr-management | 技能 | enterprise-architecture, documentation-standards |
| journey-mapping | 技能 | business-analysis, requirements-elicitation |

**语义重叠：**

| 插件 A | 插件 B | 重叠 % | 领域 | 状态 |
| -------- | -------- | --------- | ------ | ------ |
| ~~contract-testing~~ | test-strategy | 85% | 测试 | ✅ 整合 (v2.0) |
| ~~observability-planning~~ | ~~quality-attributes~~ | 70% | NFRs | ✅ 两者已移除 (v2.0) |

**已发布标准插件（整合候选）：**

| 插件 | 方法 | 标准类型 | 推荐 | 状态 |
| ------ | ----------- | ------------- | -------------- | ------ |
| ~~quality-attributes~~ | ISO 25010 | 国际标准 | 移除 | ✅ 已移除 (v2.0) |
| ~~ai-ml-planning~~ | CRISP-DM | 行业框架 | 移除 | ✅ 已移除 (v2.0) |
| ~~data-architecture~~ | Kimball | 已发布方法 | 移除 | ✅ 已移除 (v2.0) |

**整合完成 (v2.0)：**

1. **~~contract-testing~~ → test-strategy** - 完成：`compatibility-analyzer` 代理已移动
2. **8 个已发布标准插件** - 已移除：MCP 研究替换它们
3. **content-management-system** - 保留：独特组合模式

更新跟踪文件：
- 记录重叠分析日期
- 存储整合推荐
- 跟踪哪些重叠已解决

ecosystem-health.yaml中的重叠状态：

plugin_overlap:
  last_analysis: "2026-01-17"
  total_plugins: 35
  duplicate_components:
    - component: "adr-management"
      type: "skill"
      plugins: ["enterprise-architecture", "documentation-standards"]
      resolution: "pending" | "resolved" | "intentional"
  published_standard_plugins:
    - plugin: "quality-attributes"
      methodology: "ISO 25010"
      recommendation: "remove"
      status: "pending" | "removed" | "kept_with_justification"
  consolidation_candidates:
    - source: "contract-testing"
      target: "test-strategy"
      assets_moved: ["compatibility-analyzer agent"]
      status: "completed"  # v2.0 整合

发现模式（–discover）

扫描官方文档以检测所有6个层级的生态系统漂移。

算法：

查询文档管理获取所有相关文档部分：
- 层级 1: settings.md, iam.md, memory.md
- 层级 2: plugins-reference.md, skills.md, hooks.md, etc.
- 层级 3: settings.md#environment-variables, cli-reference.md, iam.md#permission-modes
- 层级 4: iam.md#authentication-methods, iam.md#configuring-permissions
- 层级 5: cli-reference.md, security.md
- 层级 6: third-party-integrations.md, setup.md, common-workflows.md
生成claude-code-guide代理用于实时网络验证：
- 近期变更日志条目
- 新功能公告
- 弃用功能
按层级构建检测到的组件列表：
- 从文档管理响应中提取功能
- 与跟踪的组件类型比较（27种）
- 识别差距
报告发现并附证据：
- 显示doc_id或变更日志版本作为来源
- 提供推荐（添加跟踪、更新名称、合并）
- 指示受影响层级

快速决策树

你想做什么？

获取所有Claude Code可扩展性概述 → 使用状态模式（默认）
检查Claude Code更新 → 使用检查模式（--check）
运行层级2插件组件的审计 → 使用审计模式（--audit）
检查层级3-6的文档覆盖 → 使用文档覆盖模式（--doc-coverage）
应用待处理更新 → 使用应用模式（--apply）
查看自版本X以来的变更 → 使用自模式（--since X.Y.Z）
检测插件重叠和冗余 → 使用重叠模式（--overlap）
检查任何层级的新/变更组件 → 使用发现模式（--discover）

委托模式

此技能委托给专业技能以获取领域特定指导：

ecosystem-health
    ├── docs-management (强制 - 所有层级的变更日志、官方文档)
    ├── claude-code-guide (在--discover和--check模式下进行实时验证)
    │
    ├── 层级 1 & 2 - 设置/内存
    │   ├── settings-management
    │   └── memory-management
    │
    ├── 层级 2 - 插件组件
    │   ├── skill-development (覆盖技能和遗留命令)
    │   ├── subagent-development
    │   ├── hook-management
    │   ├── mcp-integration
    │   ├── plugin-development
    │   ├── output-customization
    │   └── status-line-customization
    │
    ├── 层级 3-4 - 身份验证/环境
    │   ├── settings-management
    │   ├── permission-management
    │   └── enterprise-security
    │
    ├── 层级 5 - 会话/运行时
    │   └── sandbox-configuration
    │
    └── 层级 6 - 集成（仅文档跟踪）

令牌效率

目标： 在保持覆盖的同时最小化令牌使用。

策略：

跳过最近审计的组件（使用跟踪文件）
按变更日志影响优先处理（审计已变更的）
批处理审计（每次最多3个）
渐进披露（仅在需要时加载引用）
委托给文档管理（无需维护本地缓存）
仅在需要实时验证时使用claude-code-guide

预期节省： 60-80% 相比于盲目运行所有审计。

架构迁移

此技能处理架构版本间的迁移：

v1.0 → v2.0： 分层组织 v2.0 → v2.1： 委托模式（移除硬编码列表）

迁移算法：

检测架构版本
在.claude/ecosystem-health.yaml.backup创建备份
保留现有审计数据（last_audit, pass_rate, components_audited）
移除已弃用字段（tracked_*, file_patterns）
写入新架构版本

参考

详细实施指导见：

变更日志解析： 见references/changelog-parsing.md
变更类别： 见references/change-categories.md
审计协调： 见references/audit-orchestration.md
组件发现： 见references/component-discovery.md
委托检测： 见references/delegation-detection.md

测试场景

场景 1：首次运行

查询： /ecosystem-health 预期： 使用v2.1架构创建跟踪文件，显示所有层级的“从未检查”状态 成功： 跟踪文件已创建，27个组件跨6个层级显示，文件中无硬编码列表

场景 2：检查更新（带委托）

查询： /ecosystem-health --check 预期：

通过文档管理获取变更日志
查询文档管理获取关键词映射
生成claude-code-guide进行实时验证
按层级报告新版本 成功： 更新检测到，附文档管理证据，非硬编码假设

场景 3：智能审计（层级2）

查询： /ecosystem-health --audit 预期： 仅审计过时/从未审计的层级2组件 成功： 目标审计运行，跟踪文件更新（仅审计元数据）

场景 4：文档覆盖（委托）

查询： /ecosystem-health --doc-coverage 预期：

为每个层级3-6文档部分查询文档管理
基于当前文档内容报告覆盖
无与硬编码列表的比较 成功： 从实时文档管理查询报告覆盖

场景 5：组件发现（带claude-code-guide）

查询： /ecosystem-health --discover 预期：

为所有层级文档部分查询文档管理
生成claude-code-guide进行实时网络验证
报告差距并附双来源证据 成功： 发现报告生成，带双来源验证

版本历史

v2.3.0 (2026-01-17)：插件重叠检测
- 添加--overlap模式以检测插件冗余和整合机会
- 检测跨插件的重复技能/命令/代理名称
- 插件描述的语义重叠分析
- 已发布标准检测（ISO 25010, CRISP-DM, BABOK, etc.）
- 整合推荐，跟踪在ecosystem-health.yaml中
- 与新审计评分类别集成（插件边界、已发布标准测试、插件必要性）
v2.2.0 (2026-01-16)：分层验证模型
- 添加变更日志触发的审计过时性，带自动无效化
- 三层验证：次要（关键词）→ 主要（完整审计）→ 定期
- 变更严重性分类：功能/弃用=次要，行为变更/安全=主要
- 验证规范架构，带关键词、required_matches、证据捕获
- 严格准确性规则（除非确定，绝不报告“有效”）
- 在component_coverage中双重跟踪（审计 + 验证）
- 新模式：--validate（只读检查），--audit-required（仅显示主要变更）
- 增强状态显示，带VALIDATED, NEEDS VALIDATION, NEEDS AUDIT状态
- 令牌成本降低：典型工作流60-96%
- 架构v2.2，带验证字段和置信度跟踪
v2.1.0 (2026-01-10)：委托模式
- 移除所有硬编码列表（tracked_*, file_patterns）
- 添加强制文档管理委托部分
- 添加claude-code-guide集成以进行实时验证
- 架构v2.1，带仅审计数据跟踪文件
- 反重复合规性
v2.0.0 (2026-01-10)：扩展到所有Claude Code可扩展点
- 6个层级中的27种组件类型（从12种插件组件升级）
- 新架构版本（v2.0），带分层组织
- 添加文档覆盖模式用于非可审计组件
- 发现模式现在扫描所有6个层级
- 从v1.0自动架构迁移
v1.1.0 (2026-01-10)：添加发现模式
- 组件漂移检测的自审计能力
- 扫描官方文档以获取新/弃用组件
- 报告差距并附证据和推荐
v1.0.0 (2026-01-10)：初始发布
- 状态、检查、审计、应用和自模式
- 跟踪文件持久化
- 变更日志解析和分类
- 智能审计优先级处理

用户界面

参数

解析提供的参数（$ARGUMENTS）以确定模式：

参数	模式	描述
(无)	status	智能检查：显示状态和推荐
`--status`	status	详细状态报告，带验证状态
`--check`	check	检查变更日志以获取自上次检查以来的新变更
`--audit`	audit	运行过时/从未审计组件的审计
`--audit [type]`	audit	仅运行特定类型的审计
`--audit-all`	audit-all	强制所有组件的完整审计
`--apply`	apply	交互式模式以应用/验证待处理更新（分层）
`--validate`	validate	只读验证检查（无状态更改）
`--audit-required`	audit-required	仅显示需要完整审计的组件
`--since <version>`	since	显示自特定版本以来的变更
`--discover`	discover	扫描文档以获取新的/变更的可扩展性组件

--audit的有效组件类型： skills, agents, commands, hooks, mcp, memory, plugins, settings, output-styles, statuslines, rules, lsp, permissions

执行

步骤 1：解析参数

从$ARGUMENTS确定模式：

参数： $ARGUMENTS

解析：
- 无参数或 --status -> 状态模式
- --check -> 检查模式
- --audit -> 审计模式（可选带类型）
- --audit-all -> 审计-全部模式
- --apply -> 应用模式
- --since <version> -> 自模式
- --discover -> 发现模式

步骤 2：加载生态系统健康技能

调用claude-ecosystem:ecosystem-health技能以获取核心逻辑。

此技能提供：

跟踪文件管理
变更日志解析
变更分类
审计推荐
更新应用工作流

步骤 3：执行模式

状态模式（默认）

从.claude/ecosystem-health.yaml加载跟踪文件
如果缺失，报告“从未检查 - 建议先运行–check”
从.claude/audit/为每种组件类型读取审计日志
计算每个组件的过时性
显示状态表和推荐

输出格式：

生态系统健康状态 (v2.2)
==============================

上次检查： [日期] (Claude Code v[版本])
            或“从未检查”

组件覆盖：
| 组件   | 审计    | 验证 | 待处理 | 状态         |
|-------------|----------|------------|---------|----------------|
| hooks       | 01-11    | 01-16 +    | 0       | VALIDATED      |
| skills      | 01-11    | 01-16 +    | 0       | VALIDATED      |
| mcp         | 01-11    | -          | 2 次要 | NEEDS VALID.   |
| permissions | 01-12    | -          | 1 主要 | NEEDS AUDIT    |
| commands    | 01-12    | -          | 0       | OK (80%)       |

图例：
  VALIDATED    = 目标验证通过（高置信度）
  NEEDS VALID. = 次要变更待验证
  NEEDS AUDIT  = 主要变更需要完整审计
  OK           = 无待处理变更，在时间阈值内
  STALE        = >90 天自上次审计

待处理更新： N 总计（X 次要，Y 主要）
  主要（需要审计）：
    - 2.1.7-005: 安全修复 (permissions) -> /audit-settings
  次要（可使用验证）：
    - 2.1.9-005: additionalContext 功能 (hooks)

推荐：
  1. [操作]
  2. [操作]

检查模式

加载跟踪文件

通过文档管理技能访问变更日志：

python plugins/claude-ecosystem/skills/docs-management/scripts/core/find_docs.py \
  content raw-githubusercontent-com-anthropics-claude-code-refs-heads-main-CHANGELOG

计算变更日志内容的SHA256哈希
与存储哈希比较
如果不同：
- 解析自上次检查以来的新版本
- 按组件类型分类变更
- 添加到pending_updates
更新跟踪文件
报告发现

审计模式

如果指定类型（--audit skills）：

仅运行指定审计命令
更新该组件的跟踪文件

如果无类型（--audit）：

识别需要审计的组件：
- 优先级 1：从未审计
- 优先级 2：受近期变更日志影响
- 优先级 3：过时 (>90 天)
呈现审计计划
以每批3个运行审计
在批次间呈现结果
询问用户继续或停止
更新跟踪文件

审计命令：

组件	命令
skills	`/audit-skills --smart`
agents	`/audit-agents --smart`
hooks	`/audit-hooks --smart`
mcp	`/audit-mcp`
memory	`/audit-memory`
plugins	`/audit-plugins --smart`
settings	`/audit-settings`
output-styles	`/audit-output-styles --smart`
statuslines	`/audit-statuslines --smart`
rules	`/audit-rules`
lsp	`/audit-lsp`

审计-全部模式

强制运行所有审计，无论过时性：

运行所有12个审计命令
更新所有组件的跟踪文件
报告全面结果

警告： 这使用显著令牌 (~55,000+)。使用--audit进行智能目标处理。

应用模式（增强带分层验证）

对于每个待处理变更，基于严重性应用分层验证：

对于次要变更（功能、弃用）：

显示变更详细信息带严重性分类：

[1/3] 2.1.9-005: PreToolUse additionalContext (功能)
严重性：次要（功能）→ 目标验证
目标：hook-management 技能
关键词：[“additionalContext”, “additional context”]

对目标技能运行基于grep的验证
显示证据，带文件、行和匹配文本
计算置信度（高 = 2+ 匹配，中 = 1 匹配）
询问用户操作：
- 确认验证（标记为VALIDATED）
- 运行完整审计代替
- 跳过（保持待处理）

对于主要变更（行为变更、安全）：

显示变更带警告：

[2/3] 2.1.7-005: 安全：通配符权限绕过修复
严重性：主要（安全）→ 完整审计必需
目标：permission-management 技能
审计：/audit-settings

这是安全变更。目标验证不足。
必须运行完整审计以验证全面合规性。

询问用户操作：
- 运行完整审计（执行审计命令）
- 跳过（保持NEEDS AUDIT）
- 显示详细信息
更新跟踪文件带验证/审计结果

验证模式（–validate）

只读验证检查，无需应用变更：

加载跟踪文件
对于每个待处理变更： a. 按严重性分类（次要/主要） b. 如果次要：运行基于grep的验证，显示结果 c. 如果主要：报告需要完整审计
显示当前验证状态
不标记任何内容为已验证（只读）

审计-必需模式（–audit-required）

仅显示需要完整审计的组件（过滤掉次要变更）：

加载跟踪文件
过滤：
- 有pending_major_changes的组件（安全、行为变更）
- 有pending_minor_changes且验证失败的组件
显示可操作列表

自模式

从参数解析版本
通过文档管理获取变更日志
提取自指定版本到当前的所有条目
分类变更
按组件类型呈现摘要

发现模式

扫描官方文档以检测新的或变更的可扩展性组件。

通过文档管理技能访问官方文档：
- 查询插件组件类型（plugins-reference.md）
- 查询可扩展性功能（skills.md, hooks.md, etc.）
- 查询配置模式（settings.md, mcp.md）
解析变更日志以获取组件添加：
- 搜索“Added support for”模式
- 搜索新文件位置模式（.claude/X/）
- 查找新配置文件模式（.X.json）
构建检测到的组件列表：
- 提取文件位置和功能名称
- 标准化为可比较格式
与跟踪组件比较：
- 当前跟踪：skills, agents, commands, hooks, mcp, memory, plugins, settings, output-styles, statuslines, rules, lsp
- 识别差距（NEW）、移除（DEPRECATED）、重命名（RENAMED）
报告发现并附证据：
- 显示doc_id或变更日志版本作为来源
- 提供推荐（添加跟踪、更新名称、合并）

示例

# 快速健康检查带验证状态
/ecosystem-health

# 详细状态（显示审计 + 验证列）
/ecosystem-health --status

# 检查Claude Code更新
/ecosystem-health --check

# 运行目标审计
/ecosystem-health --audit

# 仅审计技能
/ecosystem-health --audit skills

# 强制完整审计（昂贵 - ~55,000 令牌）
/ecosystem-health --audit-all

# 应用待处理更新带分层验证 (v2.2)
/ecosystem-health --apply

# 只读验证检查（不修改状态）
/ecosystem-health --validate

# 仅显示需要完整审计的组件
/ecosystem-health --audit-required

# 查看自v2.1.0以来的变更
/ecosystem-health --since 2.1.0

# 扫描文档以获取新的可扩展性组件
/ecosystem-health --discover

令牌成本比较 (v2.2)

场景	旧（完整审计）	新（分层）	节省
3 次要变更	~15,000	~600	96%
2 次要 + 1 主要	~18,000	~4,600	74%
定期审查	~40,000	~8,000	80%

关键： 主要变更仍需要完整审计，但次要变更高效验证。

最后更新

日期： 2026-01-17 模型： claude-opus-4-5-20251101

技能	关系
`docs-management`	强制 - 所有动态数据的主要来源
`claude-code-guide`	用于–discover和–check模式的实时验证
`skill-development`	技能和命令验证与指导
`subagent-development`	代理验证与指导
`settings-management`	设置指导
所有其他`*-development`技能	领域特定验证

生态系统健康

强制：文档管理委托

此技能硬编码的内容（静态 - 很少更改）

必须委托的内容（动态 - 随版本更改）

委托规则

文档管理查询模式

概述

组件层级

审计类型解释

分层验证模型（v2.2）

变更严重性分类

验证层级

层级 1：目标验证（次要变更）

层级 2：完整审计（主要变更）

层级 3：定期审查

验证规范架构（v2.2）

验证结果架构

状态计算（保守）

验证准确性规则（关键）

规则 1：关键词匹配必须在上下文中正确

规则 2：优选多个证据

规则 3：边界情况需要人工确认

规则 4：证据是强制的

规则 5：主要变更不能使用目标验证

何时使用此技能

跟踪文件

变更日志访问

版本提取

变更分类

分类算法

层级到文档映射

操作模式

状态模式（默认 / --status）

检查模式（–check）

审计模式（–audit [类型]）

文档覆盖模式（–doc-coverage）

应用模式（–apply）

自模式（–since <版本>）

重叠模式（–overlap）

发现模式（–discover）

快速决策树

委托模式

令牌效率

架构迁移

参考

相关技能

测试场景

场景 1：首次运行

场景 2：检查更新（带委托）

场景 3：智能审计（层级2）

场景 4：文档覆盖（委托）

场景 5：组件发现（带claude-code-guide）

版本历史

用户界面

参数

执行

步骤 1：解析参数

步骤 2：加载生态系统健康技能

步骤 3：执行模式

状态模式（默认）

检查模式

审计模式

审计-全部模式

应用模式（增强带分层验证）

验证模式（–validate）

审计-必需模式（–audit-required）

自模式

发现模式

示例

令牌成本比较 (v2.2)

最后更新