技能介绍

问题：构建脚本先坏，CI 才报错

仓库里的 Makefile 往往是被「能用就行」的态度对待的文件。make 成功过一次之后，很少有人回头审视：某个 target 依赖了未导出的 shell 变量，某个 rm -rf 没校验路径，或者某段逻辑把 $(shell ...) 的结果硬编码进了条件分支。这些写法不会让本地构建立刻失败，因为开发者机器上有缓存、有环境变量、有历史产物。等到 CI 从干净 checkout 开始跑，流水线才第一次暴露问题——通常发生在凌晨，而报错信息往往是 make: *** No rule to make target 这种和根因毫无关系的东西。

这个技能做什么

它把 checkmake 接进审查流程，在构建自动化真正跑挂之前，对仓库里已有的 Makefile 做一次静态检查。重点不是「命令拼写对不对」，而是三类更容易在 CI 里被放大的问题：

写法问题：规则里用了隐式变量、缺少前置声明、赋值与引用顺序混乱等导致行为依赖 shell 解析顺序的写法。
脆弱 target：路径拼接不校验、清理逻辑无保护、依赖隐式假设存在的 target。
可维护性问题：重复片段、条件分支里嵌套过深的构建逻辑。

调用方式很直接：把目标文件传给 checkmake，可以是单个 Makefile，也可以是 checkmake Makefile foo.mk bar.mk baz.mk 这样的多文件列表。输出是逐条的规则提示，可以直接挂在流水线上当门禁。

适用边界

只服务已经依赖 make 的仓库。项目用 just、task、bazel 或纯 shell 脚本的话，这个技能没有对应检查器。
需要本地或 CI 镜像里存在 checkmake 可执行文件，否则技能跑不起来。
容器化部署时注意命令选择：构建和运行镜像的 docker 或 podman 会被自动探测，优先使用 podman，可通过 make 变量 CONTAINER_CMD 覆盖。
镜像发布需要对应的 make image-push 命令，或者直接用 docker push / podman push。
它是审查工具，不是修复工具：告诉你哪些文件有问题，但不会替你重写构建逻辑。