mcpField
A
add-checkpoints

add-checkpoints

github.com/netresearch测试与质量277 次安装1 天前更新
代码仓库

关于 add-checkpoints

用于分析 Skill 并生成 automated-assessment 框架所需 checkpoints.yaml 的 Skill。适合需要将可验证规范转为自动检查点的维护者，并包含适用性评估、验证和结果说明流程。

主要功能

  1. 01定位 Skill 文件与资源
  2. 02评估检查点适用性
  3. 03提取可验证要求
  4. 04生成机械检查与 LLM 评审
  5. 05添加项目类型前置条件
  6. 06验证检查点并报告结果

适用场景

  1. 01为有明确文件结构要求的 Skill 生成检查
  2. 02将命名规范转为自动验证项
  3. 03检查配置规则或元数据标准

安装

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

$npx skills add https://github.com/netresearch/automated-assessment-skill --skill add-checkpoints

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

附带文件evals/evals.json

详细介绍

为技能添加检查点

分析某项技能，并为自动化评估框架生成适当的 checkpoints.yaml。

命令

/add-checkpoints                    # Analyze current skill directory
/add-checkpoints typo3-docs         # Analyze a specific installed skill
/add-checkpoints --dry-run          # Show what would be generated, don't write

工作流

  1. 定位技能 — 查找 SKILL.md、references/、scripts/、assets/
  2. 分析适用性 — 判断检查点是否适用（参见下方标准）
  3. 提取要求 — 解析 SKILL.md，找出可验证的规则和模式
  4. 生成检查点 — 创建 checkpoints.yaml，包含机械检查和 LLM 审查
  5. 添加前置条件 — 确定此技能适用于哪些项目类型
  6. 验证 — 运行 ${CLAUDE_PLUGIN_ROOT}/skills/automated-assessment/scripts/validate-checkpoints.sh，然后在示例项目上运行 ${CLAUDE_PLUGIN_ROOT}/skills/automated-assessment/scripts/run-checkpoints.sh。将其警告视为发现项：警告会指出下方列出的缺陷类别。blocked 结果表示运行器拒绝了命令，检查点因此没有运行；这是 YAML 中的缺陷，而非示例项目中的问题。
  7. 报告 — 说明生成的内容及原因，或解释为何检查点不适用

适用性标准

如果技能定义了以下内容，则适用于检查点：

  • 文件结构要求（目录、配置文件、清单）
  • 内容模式（必须包含 X、不得包含 Y）
  • 命名约定（前缀、后缀、大小写规则）
  • 工具配置（PHPStan 级别、代码检查规则、CI 步骤）
  • 元数据标准（许可证、作者、版本格式）

如果技能仅提供以下内容，则不适用于检查点：

  • 没有可验证输出的概念性指导
  • 没有持久化产物的交互式工作流
  • 运行时行为模式（性能、缓存策略）

请说明适用性并给出理由。

检查点生成规则

机械检查

从 SKILL.md 中提取以下模式：

  • “必须存在”/“必需” → file_exists
  • “不得”/“永远不要”/“避免” → file_not_exists 或 not_contains
  • “必须包含”/“应该有” → contains 或 regex
  • 版本/格式约束 → json_path 或 command
前置条件

根据技能适用范围推导：

  • TYPO3 扩展 → file_exists: ext_emconf.php
  • Docker 项目 → file_exists: Dockerfile
  • Go 项目 → file_exists: go.mod
  • 技能仓库 → file_exists: .claude-plugin/plugin.json
  • 通用（任何项目） → 无前置条件
ID 约定

使用 ../automated-assessment/references/migration-guide.md 中为该技能设定的前缀，或根据技能名称推导出 2 个字母的前缀。

严重级别分配
  • error：“必须”、“必需”、“永远不要” → 阻止发布
  • warning：“应该”、“建议” → 提示
  • info：“考虑”、“锦上添花” → 可选
三类缺陷——检查每个生成的检查点是否存在这些问题

报告不实内容的检查点比没有检查点更糟。这三类问题都会造成这种情况，在已发布的项目中都能找到，而且在 YAML 中都不明显。完整证据和正确写法： ../automated-assessment/references/checkpoints-schema.md → “导致检查点错误报告的三类缺陷”。

  1. 供应商代码泄漏——find、file_exists glob 或前置条件没有排除 vendor/、node_modules/、.Build/。运行器的自动排除仅适用于内容检查的 glob 目标；其他地方都需要你自行写明排除项。一个泄漏的前置条件曾对一个没有 RTE 代码的扩展运行了全部 14 项 typo3-ckeditor5 检查。
  2. 相对于技能的脚本路径——bash scripts/check-foo.sh。检查点会在受测代码库中运行，而那里不存在技能的 scripts/；此外，允许列表也会拒绝带路径前缀的命令。将逻辑内联（非简单操作可用 php -r '...'）；保留已发布的脚本作为人工入口。
  3. 管道接入 head 的退出状态陷阱——... | head -1 && echo ... && exit 1 || exit 0 会在每个项目上都报告失败，因为输入为空时 head 仍会以 0 退出。让匹配结果决定退出状态（使用 grep -q，或直接使用不带命令的 regex_not）。
校准锚点

每个检查点都以 YAML 注释记录预测的缺陷类别和退役条件。若缺失，最高评为 info。参见 automated-assessment/references/calibration.md。

LLM 评审

仅用于无法通过命令判定的内容。以命令开头的提示词属于 mechanical；只有添加 # mechanical-counterpart: <ID> 时，才同时保留两者。

  • 代码质量判断 → domain: code-quality
  • 文档完整性 → domain: documentation
  • 架构决策 → domain: architecture

输出

在技能目录中生成 checkpoints.yaml（架构：../automated-assessment/references/checkpoints-schema.md），并在资源目录中生成一份副本。

参考资料

  • 架构：../automated-assessment/references/checkpoints-schema.md
  • 迁移指南：../automated-assessment/references/migration-guide.md
  • 现有检查点：assets/*-checkpoints.yaml（用作示例）

评论

支持 Markdown