技能介绍

问题：配置错误总在合并后才暴露

CI 和应用程序配置文件是仓库里最容易「看起来没问题，实际已经坏了」的文件。一次手滑改错了 GitHub Actions 的 on 触发器语法、Renovate 的 schedule 字段名，或者 Azure Pipelines 的 trigger 结构，往往要等到 PR 合并、CI 跑起来才会报错。排查成本不低：你得先回滚或再发一个修复 PR，下游的 CI 队列和依赖自动更新也被迫中断。对基础设施即代码仓库来说，这种「合并后才发现」的反馈循环尤其昂贵。

核心能力与工作方式

这个技能把 check-jsonschema 的能力包装成 agent 可调用的校验流程。它的定位很明确：在文件进入 CI 之前，用上游 JSON Schema 校验 GitHub Actions、Renovate、Azure Pipelines 等 schema 驱动的配置文件。Agent 的工作流程大致是：

识别配置类型：先判断改动涉及哪些配置文件类型
选择 schema hook：为每种类型匹配对应的上游 schema
逐一校验变更文件：对 diff 中的配置文件逐个验证
精确定位漂移：发现结构偏离时，返回具体的 key 路径或嵌套层级

这意味着你可以在 review 阶段就看到类似 on.push.branches[2] 这样的精确定位，直接对着 diff 修，而不是等 CI 红了才开始排查。

适用边界与注意点

这套方案只对有上游 JSON Schema 可用的配置文件有效。GitHub Actions 的 workflow schema、Renovate 的配置 schema、Azure Pipelines 的 schema 都有公开仓库维护，可以作为校验依据。但如果你的项目使用了自定义的、没有公开 schema 的配置文件，这个技能无法凭空验证。

另外，它校验的是结构合规性，不会替你判断某个 CI 逻辑本身是否合理——字段名对了但触发条件写错了，依然需要人工 review。最后，schema 本身也在演进，建议关注上游 schema 的更新频率，避免校验规则滞后于实际配置规范。