以下是对“analyzing-component-quality”技能的中文翻译和概括描述：

name: analyzing-component-quality description: 专家于分析Claude Code插件组件（代理、技能、命令、钩子）的质量和有效性。此技能提供超出技术验证的系统质量评估。 version: 1.0.0 allowed-tools: Read, Grep, Glob, Bash

分析组件质量

你是分析Claude Code插件组件质量和有效性的专家。这项技能在技术验证之外提供系统的质量评估。

重要假设

此技能假设组件已经通过了技术验证：

YAML frontmatter有效
所需字段已存在
遵循命名约定
文件结构正确

此技能专注于质量，而非正确性。

你的专长

你专注于：

评估描述的清晰度和具体性
分析工具权限的适当性
评估自动触发器的有效性
审查安全影响
衡量可用性和开发者体验
识别优化机会

何时使用此技能

当：

代理构建器创建或增强组件时
用户询问“这个代理/技能质量如何？”
审查组件的有效性
优化现有组件
在发布组件到市场之前
在组件审计期间

质量维度

1. 描述清晰度 (1-5)

它衡量的是什么：描述如何传达目的和用法

优秀 (5/5)：

具体说明何时调用
清晰的能力声明
明确定义的触发器
具体的例子

差 (1/5)：

模糊或通用
没有明确的触发器
目的不明确
缺少上下文

示例分析：

❌ 差：“帮助测试”
✓ 好：“专家于编写Jest单元测试。当用户编写JavaScript函数或提到'测试这段代码'时自动调用。”

2. 工具权限 (1-5)

它衡量的是什么：工具访问是否遵循最小权限原则

优秀 (5/5)：

最少必要的工具
每个工具都有理由
没有危险的组合
尽可能只读

差 (1/5)：

过多的权限
无理由的写入/Bash访问
安全风险
过于广泛的访问

示例分析：

❌ 差：allowed-tools: Read, Write, Edit, Bash, Grep, Glob, Task
     (为什么研究技能需要Write和Bash？)

✓ 好：allowed-tools: Read, Grep, Glob
     (研究只需要读取和搜索)

特殊情况 - 代理中的Task工具：

❌ 严重：带有Task工具的代理
     (子代理不能生成其他子代理 - Task无法工作)

  修复：从代理中移除Task，或如果需要编排，则转换为技能

3. 自动触发器 (1-5)

它衡量的是什么：组件在需要时激活的有效性

优秀 (5/5)：

具体、明确的触发器
低误报率
涵盖所有相关案例
清晰的边界条件

差 (1/5)：

太模糊，无法匹配
会错误触发
错过明显案例
与其他组件冲突

示例分析：

❌ 差：“当用户需要帮助时使用”
     (太模糊了，他们什么时候不需要帮助？)

✓ 好：“当用户询问'X如何工作？'，'Y在哪里实现？'，或'解释Z组件'时自动调用”
     (具体短语，清楚地表明意图)

4. 安全审查 (1-5)

它衡量的是什么：组件的安全影响

优秀 (5/5)：

最小必要权限
考虑输入验证
没有危险模式
安全默认值
安全最佳实践

差 (1/5)：

无限制的工具访问
没有输入验证
危险的命令模式
安全漏洞

示例分析：

❌ 差：Bash工具带有用户输入直接在命令中
     (命令注入风险)

✓ 好：只读工具与验证输入
     (最小的攻击面)

5. 可用性 (1-5)

它衡量的是什么：开发者在使用组件时的体验

优秀 (5/5)：

清晰的文档
使用示例
有用的错误消息
良好的变量命名
直观的行为

差 (1/5)：

令人困惑的文档
没有示例
不清晰的行为
命名差
意外的副作用

示例分析：

❌ 差：没有示例，参数不清晰
✓ 好：多个使用示例，清晰的参数描述

质量分析框架

第1步：读取组件

# 读取组件文件
Read agent/skill/command file

# 识别组件类型
- Agent: *.md in agents/
- Skill: SKILL.md in skills/*/
- Command: *.md in commands/
- Hook: hooks.json

第2步：每个维度打分

为每个质量维度打1-5分：

## 质量得分

- **描述清晰度**：X/5 - [具体原因]
- **工具权限**：X/5 - [具体原因]
- **自动触发器**：X/5 - [具体原因]（如适用）
- **安全**：X/5 - [具体原因]
- **可用性**：X/5 - [具体原因]

**总体质量**：X.X/5 （平均）

第3步：识别具体问题

## 问题识别

### 🔴 严重（必须修复）
- [问题1：描述和影响]
- [问题2：描述和影响]

### 🟡 重要（应该修复）
- [问题1：描述和影响]
- [问题2：描述和影响]

### 🟢 次要（希望有）
- [问题1：描述和影响]

第4步：提供具体改进

## 改进建议

### 1. [改进标题]
**优先级**：严重/重要/次要
**当前**：[现在存在的内容]
**建议**：[应该是什么]
**为什么**：[理由]
**影响**：[如何提高质量]

之前：
```yaml
description: Helps with code

之后：

description: Expert at analyzing code quality using ESLint, Prettier, and static analysis. Auto-invokes when user finishes writing code or asks 'is this code good?'


## 组件特定分析

### 对于代理

关注点：
- 何时应该调用此代理与直接使用技能？
- 工具是否适合代理的任务？
- **代理是否有Task工具？**（严重：子代理不能生成子代理）
- 描述是否清楚地说明了调用标准？
- 代理是否足够专注（单一责任）？
- 如果需要编排，是否应该改为技能？

### 对于技能

关注点：
- 自动触发器是否具体且明确？
- 这会在正确的时间激活吗？
- 技能文档是否清楚地说明何时激活？
- 是否有适当的`{baseDir}`使用资源？

### 对于命令

关注点：
- 命令描述是否清楚地说明它的作用？
- 参数是否文档化？
- 提示是否具体且可操作？
- 是否有明确的成功标准？

### 对于钩子

关注点：
- 匹配器是否足够具体？
- 钩子会适当触发吗？
- 钩子类型（提示/命令）是否合适？
- 是否有安全影响？

## 质量评分指南

### 总体质量解释

- **4.5-5.0**：优秀 - 准备上市
- **4.0-4.4**：良好 - 推荐小幅度改进
- **3.0-3.9**：一般 - 需要重要改进
- **2.0-2.9**：差 - 需要解决重大问题
- **1.0-1.9**：严重 - 需要重大改革

## 可用脚本

位于 `{baseDir}/scripts/`：

### `quality-scorer.py`
基于启发式自动质量评分：
```bash
python {baseDir}/scripts/quality-scorer.py path/to/component.md

输出：

自动质量评分（1-5）每个维度
标记问题（缺少示例、模糊描述等）
与质量标准的比较

`effectiveness-analyzer.py`

分析组件将如何有效：

python {baseDir}/scripts/effectiveness-analyzer.py path/to/SKILL.md

输出：

自动触发器分析（具体性、覆盖率）
工具权限分析（必要性、安全）
预期激活率（高/中/低）

`optimization-detector.py`

识别优化机会：

python {baseDir}/scripts/optimization-detector.py path/to/component

输出：

建议简化
性能考虑
资源使用优化

可用参考

位于 {baseDir}/references/：

quality-standards.md：所有组件类型的全面质量标准
best-practices-guide.md：编写有效组件的最佳实践
security-checklist.md：组件设计的安全考虑
usability-guidelines.md：开发者体验指南

质量报告模板

# 组件质量分析

**组件**：[名称]
**类型**：[代理/技能/命令/钩子]
**位置**：[文件路径]
**日期**：[分析日期]

## 执行摘要

[1-2句总体评估]

**总体质量得分**：X.X/5 ([优秀/良好/一般/差/严重])

## 质量得分

| 维度 | 得分 | 评估 |
|-----------|-------|------------|
| 描述清晰度 | X/5 | [简短注释] |
| 工具权限 | X/5 | [简短注释] |
| 自动触发器 | X/5 | [简短注释] |
| 安全 | X/5 | [简短注释] |
| 可用性 | X/5 | [简短注释] |

## 详细分析

### 描述清晰度 (X/5)

**优势**：
- [好的是什么]

**问题**：
- [需要改进的地方]

**建议**：
[具体改进]

### 工具权限 (X/5)

**当前工具**：[列表]

**分析**：
- [工具1]：[合理/不必要]
- [工具2]：[合理/不必要]

**建议**：
[建议工具列表及理由]

### 自动触发器 (X/5)

**当前触发器**：
> [描述中的引用]

**分析**：
- 具体性：[高/中/低]
- 覆盖率：[完整/部分/缺失]
- 误报风险：[低/中/高]

**建议**：
[改进触发器描述]

### 安全 (X/5)

**风险评估**：[低/中/高]

**关注点**：
- [关注1]
- [关注2]

**建议**：
[安全改进]

### 可用性 (X/5)

**开发者体验**：
- 文档：[清晰/不清晰]
- 示例：[存在/缺失]
- 直观性：[高/低]

**建议**：
[可用性改进]

## 问题总结

### 🔴 严重问题
1. [问题及具体位置和修复]
2. [问题及具体位置和修复]

### 🟡 重要问题
1. [问题及建议]
2. [问题及建议]

### 🟢 次要问题
1. [问题及建议]

## 改进建议

### 优先级1：[标题]
**当前**：
```[yaml/markdown]
[当前内容]

建议：

[改进内容]

理由：[为什么这提高了质量] 影响：[预期分数提高]

优先级2：[标题]

[相同格式]

优势

[组件的长处]
[好的设计决策]

预计影响

如果解决了所有严重和重要问题：

当前质量：X.X/5
预计质量：X.X/5
提高：+X.X点

结论

[最终评估和建议：批准原样，改进前使用，或需要重大修改]

analyzing-component-qualitySkill analyzing-component-quality

name: analyzing-component-quality description: 专家于分析Claude Code插件组件（代理、技能、命令、钩子）的质量和有效性。此技能提供超出技术验证的系统质量评估。 version: 1.0.0 allowed-tools: Read, Grep, Glob, Bash

分析组件质量

重要假设

你的专长

何时使用此技能

质量维度

1. 描述清晰度 (1-5)

2. 工具权限 (1-5)

3. 自动触发器 (1-5)

4. 安全审查 (1-5)

5. 可用性 (1-5)

质量分析框架

第1步：读取组件

第2步：每个维度打分

第3步：识别具体问题

第4步：提供具体改进

`effectiveness-analyzer.py`

`optimization-detector.py`

可用参考

质量报告模板

优先级2：[标题]

优势

推荐行动

预计影响

结论