GitHub Actions 工作流语法检查器

要解决的问题

GitHub Actions 的 workflow 本质上是 YAML，而 YAML 的坑在于：一个缩进错误、一个拼错的 step id、一处 secrets 上下文引用，甚至一个已被上游废弃的 Action 版本，都可能要等到 CI 真正跑起来（甚至部署阶段）才暴露。排查成本并不低——先等一次红灯，再打开文档逐行比对 needs、uses 和 secrets: 的写法，这个过程重复且枯燥。

它如何工作

这个技能把校验动作前置到 CI 运行之前，核心能力包括：

• 语法与结构检查：借助 actionlint 解析 workflow 的 YAML，识别缩进错误、非法字段、runner 标签拼写等问题。
• 步骤引用校验：检查 steps 中 uses、with、needs 的引用是否指向真实存在的 step id 或上游 job，避免拼写错误导致的静默失败。
• secrets 声明检查：验证 workflow 里 secrets: 上下文的引用，是否与仓库 settings 中实际声明的 secret 对得上。
• Action 版本审计：对照 GitHub Actions 市场的信息，标记已废弃或存在已知问题的 Action 版本。

关键流程大致是：读取 workflow 文件 → 调用 actionlint 做静态检查 → 通过 GitHub Actions REST API 获取仓库当前的 Actions 配置 → 汇总输出可直接照做的修复建议。

适用边界与注意点

• 前提是 GitHub 仓库已开启 Actions，且校验结果依赖仓库当前的 secret 与 workflow 配置，刚改动的配置可能有延迟。
• 对第三方自托管 runner 上的自定义行为覆盖有限，actionlint 只能按通用规则推断。
• REST API 调用受 rate limit 约束，大型 monorepo 中频繁运行要留意配额消耗。
• 它检查的是语法与声明层面的一致性，不会替代真实的构建与测试环节。