YAML配置预检

为什么需要这一步

*.yml 和 *.yaml 文件往往在很晚的阶段才被真正执行。一次手滑的缩进调整、一个复制粘贴时留下的重复键，都可能让 CI 流水线在第一步就挂掉，或者让部署脚本在运行时拿到与预期不一致的配置。更麻烦的是，YAML 的解析器对缩进、引号和行尾空格的处理并不统一：同一份文件在不同的解析器下可能得到不同的结果。

这类问题在代码评审里很难肉眼看出来，尤其是生成的配置文件——几百行自动生成的内容，没有人会逐行看。

技能做了什么

这个技能的核心是一个确定性的检查流程，而不是让模型凭感觉判断配置是否正确。它调用 yamllint 这个成熟的 YAML linter，把静态检查能力包装成一个可以在任意工作目录执行的步骤。

关键能力包括：

• 语法层面的校验：括号、冒号、引号、换行符等结构性问题，报错会带行号，可以直接定位到出问题的那一行。
• 重复键检测：YAML 允许后出现的键覆盖前面的值，这是最容易埋雷的地方。启用该规则后，同一个映射里出现两次 key 会直接报错，而不是被静默覆盖。
• 缩进与格式漂移：缩进层级不一致、行尾空格、超长行、truthy 值（yes/no/on/off）被误读为布尔值，都是典型的风格漂移来源。技能会把这些逐项列出来，方便统一修复。
• 输出可读的诊断信息：返回的是行级别的检查结果，包含规则名、行号和列号，可以直接贴到 commit message 或 review comment 里。

使用方式很直接：把需要检查的文件或目录交给技能，它会返回一份带行号的问题清单，逐条修复即可。通常的流程是先处理语法错误，再处理重复键，最后统一调整缩进和风格，这样可以避免重复返工。

适用边界

• 技能依赖 Python 环境和 yamllint CLI，环境中必须提前装好这个工具，否则技能本身无法运行。
• yamllint 的默认规则集偏保守，某些规则在团队里可能并不在意。可以配置 .yamllint 配置文件来调整启用哪些规则，但配置文件本身也需要被检查和保持一致。
• 技能只做静态检查，不会验证配置的语义正确性。它无法判断某个 image: foo 是否指向真实存在的镜像，也不会校验 schema。语义层面的校验需要配合其他工具。
• 对于由程序动态生成、每次构建都会重写的配置文件，检查一次只是快照。更可靠的做法是把检查接入到生成流程之后的固定环节。
• YAML 的 anchor、alias 和 merge key 特性在不同解析器下行为有差异，遇到这类复杂用法时，yamllint 的规则判断可能需要单独确认。