mcpField
H
health-check

health-check

github.com/codewithmukesh测试与质量7913.0k 次安装12 周前更新
代码仓库

关于 health-check

health-check 是面向开发者的项目评估技能，按 8 个维度采集数据并评分，汇总 GPA。它为低于 A 的维度提供带优先级和工作量估算的具体改进建议。

主要功能

  1. 01按 8 个维度评估项目健康度
  2. 02依据数据和分级标准打分
  3. 03汇总已评维度的 GPA
  4. 04提供排序后的修复建议
  5. 05支持范围选择与趋势比较

适用场景

  1. 01为新接手的项目建立基线
  2. 02将发布前质量评估纳入检查
  3. 03复查维护或清理后的项目
  4. 04根据低分项安排技术债工作

MCP 相关

该技能使用 MCP 工具收集代码质量、架构、测试覆盖率、死代码和 API 数据，再据分级标准评估。

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/codewithmukesh/dotnet-claude-kit --skill health-check

安装后在 Claude Code 中输入/health-check确认已加载。

附带文件references/grading-rubric.md

详细介绍

/health-check — 8 维度项目评估

内容

针对 8 个维度进行数据驱动的健康评估，每个维度按 A-F 评级，并列出产生该评级的具体数据点，最后汇总为 GPA。直觉不是评级依据：每个维度都使用 MCP 工具或 CLI 命令，而且每个低于 A 的评级都会附上具体、按优先级排列并估算工作量的修复方案——“为 OrderService、PaymentProcessor、ShippingCalculator 添加测试类”具有可操作性；“提升测试覆盖率”则不然。

此技能拥有工具包的规范评级体系。完整的评分标准、GPA 等级和报告模板位于 references/grading-rubric.md——运行评估时请加载该文件。

语气应以诊断为主，而非惩罚：C 级是改进路径，不是失败。

适用场景

  • 加入陌生或新项目时——设定基线
  • “这个项目健康状况如何？”、“给这个项目评级”、“代码库审查”、“成绩单”
  • 发布前质量门禁，或每月／每季度维护审查
  • 清理冲刺（/de-sloppify）之后——重新评级以展示进展
  • 技术债优先级排序——最低评级的维度优先纳入下一次冲刺

操作方法

步骤 1：选择范围
场景维度
完整评估（项目入门、发布前、月度审查）全部 8 个
快速健康检查（冲刺中检查点、演示前、合并后）仅 1-4
重大重构后1（构建）、3（架构）、4（测试）
依赖项更新后1（构建）、7（安全）
清理冲刺后仅重新评估已清理的维度
步骤 2：运行各维度检查

阅读 references/grading-rubric.md 了解评级阈值，然后按维度收集数据。对于深入的代码质量维度，请委派给使用 code-review 技能的 code-reviewer Agent。

#维度数据来源
1构建健康状况dotnet build --no-restore — 错误 + 警告
2代码质量MCP detect_antipatterns — 阅读 summary，仅评估高置信度结果
3架构MCP get_project_graph + detect_circular_dependencies（项目和类型）
4测试覆盖MCP get_test_coverage_map — 先检查 applicable（结构性指标，不是行覆盖率）
5死代码MCP find_dead_code(scope: "solution") — 评估高置信度结果；忽略 conventionFiltered
6API 面MCP get_public_api + find_references — 检查暴露过度、返回类型一致性
7安全状况dotnet list package --vulnerable --include-transitive + 密钥／身份验证抽查（深入检查：/security-scan）
8文档公共 API 的 XML 文档覆盖率 + README 时效性
步骤 2.5：分诊关卡（评定任何等级之前）

检测器输出是证据，不是评级。请先让每条发现通过此关卡——这样才能避免因嘈杂的计数而得出错误等级。

  1. 阅读 summary，而不是违规列表。 即使列表被截断，summary.byId 仍然完整。切勿抽查截断列表后再推断整体情况。
  2. 剔除 suppressed。 在报告中记录数量和 summary.suppressionConfig，确保抑制项仍然可见。
  3. 搁置 medium。 这些是待审查项，不作为评级依据。按类别汇总；不要修复或计数。
  4. 仅评估 high。 无论上下文如何，这些都属于错误。
  5. 检查不变项。 如果某个信号与目标代码库的 CLAUDE.md 中记录的既定设计相矛盾，应以该不变项为准——评级前先核实。
  6. 先阅读，再断言。 切勿描述未打开查看的发现。如果无法逐一打开，请报告已查看的内容并说明情况。

进行过程中，请填写 references/grading-rubric.md 中的分诊表。如果表格无法填写，该维度就尚未准备好评级。

第 3 步：评分与汇总

严格应用评分标准阈值——绝不按比例调整评分（「对于这个规模的项目来说相当不错」正是标准逐渐降低的原因；无论项目规模如何，15 条警告都只能得 C）。将等级转换为 GPA（A = 4.0 … F = 0.0），只对实际评分的维度取平均——标记为「未评估」的维度不计入 GPA，绝不能按 F 计分。

第 4 步：报告

根据 references/grading-rubric.md 中的模板生成成绩报告：包含关键发现的评分表、总体 GPA 和优先级建议——每项建议都应列出具体类型/文件、优先级顺序和工作量估算。如果已有之前的报告，则追加趋势对比表。

示例

User: /health-check

Claude: Running full 8-dimension assessment...

| Dimension | Grade | Key Finding |
|-----------|-------|-------------|
| Build Health | A | 0 errors, 2 warnings |
| Code Quality | B | 3 high-confidence findings in 4.2K lines; 31 medium untriaged |
| Architecture | A | Clean direction, 0 cycles |
| Test Coverage | Not assessed | Integration-driven suite — structural metric invalid |
| Dead Code | B | 5 unused methods (79 convention-discovered, not counted) |
| API Surface | B | 2 overexposed service types |
| Security | A | 0 vulnerable packages |
| Documentation | D | 12/30 public APIs documented |

Overall GPA: 3.1 (B) — averaged over 7 graded dimensions.

Triage: 44 AP005 raw → all log-and-rethrow wrappers (medium); 2 AP004 real.

Priority: (1) `SystemSeeder` → `TimeProvider`, ~15 min; (2) XML docs on the 8
endpoint classes, ~1 day; (3) review the 44 catch blocks or suppress by path.

相关内容

  • references/grading-rubric.md — 权威评分标准、GPA 等级和报告模板
  • /de-sloppify — 用于清理健康检查发现问题的流水线
  • /security-scan — Dimension 7 背后的 6 层深度扫描
  • /code-review — 针对每项变更的审查（此技能会为整个项目评分）
  • /verify — 针对变更集的通过/失败流水线，而非评分评估

评论

支持 Markdown