name: quality-verify description: 在交付前验证最终交付物是否符合所有质量标准。作为最终验证步骤，确保输出在6个维度上满足用户的质量标准。

质量验证技能

目的

在交付前对格式化的交付物进行最终验证，确保其符合所有质量标准。这是最后一道关卡——如果通过，即可准备交付。

质量维度

系统根据6个质量维度进行检查。评估每个维度：

1. 完整性

交付物是否包含所有必需部分？
是否有任何缺失或明显不完整之处？
是否满足用户的所有要求？

2. 正确性

代码语法是否正确？（无错误）
事实/信息是否准确？
是否完成了所要求的功能？
是否存在逻辑错误？

3. 一致性

整个文档的格式是否一致？
命名约定是否一致？
风格是否一致？
模式是否一致应用？

4. 性能（如适用）

是否高效？（代码不应明显缓慢）
是否可扩展？（针对大量输入/数据）
是否存在明显的性能问题？

5. 安全性（如适用）

是否存在明显漏洞？
输入是否经过验证/清理？
是否存在硬编码的密钥？
是否遵循安全最佳实践？

6. 可维护性

是否易于阅读？
是否有文档说明？
其他人是否能理解？
是否易于后续修改？

评分系统

对每个维度进行评分：

✓ 优秀 (90-100)：超出标准，专业质量
✓ 良好 (75-89)：符合标准，可交付
⚠ 可接受 (60-74)：达到最低标准，有待改进
✗ 需要改进 (0-59)：低于标准，需要修订

评分算法

总体得分 = 所有适用维度的平均值

0个关键问题 = 基础分
- 每个关键问题扣10分（例如：代码无法运行、重大安全缺陷）
- 每个主要问题扣5分（例如：缺少部分、格式不一致）
- 每个次要问题扣2分（例如：拼写错误、轻微不一致）

最终得分 = 基础分 - 扣分

80+ = 可交付 ✓
60-79 = 建议进行小修复
<60 = 需要重大修订

流程

审查格式化的交付物
使用StandardsRepository加载用户标准，了解此类交付物的“良好”标准
根据每个质量维度进行评估
对每个维度进行评分
计算总体质量得分
识别发现的任何问题
提供详细反馈

加载标准

使用StandardsRepository访问质量标准：

const standards = standardsRepository.getStandards(context.projectType)
if (standards && standards.qualityCriteria) {
  // 根据其质量标准定义进行检查
  const criteria = standards.qualityCriteria
  // 验证交付物是否符合：完整性、正确性、一致性等
  verifyAgainstCriteria(deliverable, criteria)
} else {
  // 使用通用质量最佳实践
  verifyAgainstBestPractices(deliverable)
}

有关接口详细信息，请参阅.claude/lib/standards-repository.md。

输出格式

{
  "qualityScore": 92,
  "readyToDeliver": true,
  "dimensionScores": {
    "completeness": 95,
    "correctness": 90,
    "consistency": 88,
    "performance": 85,
    "security": 90,
    "maintainability": 95
  },
  "issuesFound": [
    "发现的具体问题列表（如有）"
  ],
  "issuesSeverity": {
    "critical": [],
    "major": [],
    "minor": ["缺少一个边界情况测试"]
  },
  "notes": "发现一个次要问题——其他方面质量优秀",
  "summary": "可交付。建议添加边界情况测试。",
  "recommendations": [
    "为空数组边界情况添加测试"
  ]
}

成功标准

得分85+

✓ 质量得分高于85 ✓ 无关键问题 ✓ 可立即交付

得分70-84

⚠ 质量良好，存在次要问题 ⚠ 应在交付前修复次要问题 ⚠ 询问用户：“修复这些问题，还是按原样交付？”

得分<70

✗ 发现重大问题 ✗ 不应以当前状态交付 ✗ 建议进行重大修订

质量检查示例

代码功能质量检查

交付物：React下拉组件

检查：

✓ 完整性：具有所有必需方法、属性、事件处理程序
✓ 正确性：代码运行无错误，键盘导航有效
✓ 一致性：命名一致，格式一致
✓ 性能：无明显低效，重新渲染次数合理
✓ 安全性：正确清理用户输入，无XSS漏洞
✓ 可维护性：注释良好，变量名清晰，易于修改

得分：94/100 问题：无建议：可交付

文档质量检查

交付物：API端点文档

检查：

✓ 完整性：所有端点均有文档，所有参数均有描述
✓ 正确性：信息与实际API行为匹配
✓ 一致性：格式一致，示例遵循相同模式
✓ 清晰度：新开发人员易于理解
⚠ 可维护性：缺少错误响应示例（次要）

得分：82/100 问题：[“缺少错误响应示例”] 建议：添加错误响应示例，然后交付

决策树

得分85+ → 可交付 ✓
得分70-84 → 询问次要问题
得分<70 → 建议重大修订

实施注意事项

对发现的问题要具体，不要模糊
建议修复时，解释其重要性
如果用户标准不明确，使用通用质量最佳实践
质量是主观的——但一致性是客观的（是否遵循了他们的标准？）
宁可稍微严格，也不要让不良工作通过