关于 verify-commands
verify-commands 是面向编写和审查命令行验收检查的开发者技能，重点是明确可观察的失败信号、以仓库证据核实路径，并避免无实际测量却通过的检查。
主要功能
- 01定义明确的失败信号
- 02依据仓库证据核实命令路径
- 03识别没有实际测量的检查
- 04审查命令时不猜测替代路径
适用场景
- 01交付前编写验收检查
- 02审查可能未实际测试却通过的命令
- 03核实仓库路径和清单文件
- 04识别脆弱的 Shell 管道或筛选器
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/verify-commands确认已加载。
详细介绍
验证命令
验证命令是一种验收测试。在发布命令前，请回答：如果这个命令悄无声息地什么也没做，输出中有什么能告诉我？ 如果回答不上来，你有的是命令，不是检查。修好命令；不要为它编造说法。
指明失败信号
每个可运行的检查旁边都写一行，说明哪个可观察信号代表失败：non-zero exit、摘要行中出现 "0 passed"、缺少覆盖率行、stderr 包含 "ECONNREFUSED"。“命令失败”和“发生错误”只是重复描述，并非信号。TBD、N/A 和 none 都是在回避。简短即可；non-zero exit 已经完整。优先采用工具实际输出的信号，而不是臆想的信号：对于已经运行过的命令，说明你看到了什么；对于新命令，依据工具文档中的输出。N 条命令就要有 N 条说明。
为每条路径提供依据
在推导新命令前，先逐字沿用这个仓库中已经成功运行的命令。cd 目标或 --prefix 目标必须存在，或由前面的步骤创建，并且必须包含对应的清单（package.json、Makefile、pyproject.toml）。优先使用 npm --prefix <dir> run <script>，而不是 cd <dir> && npm run <script>；前者不依赖调用方的工作目录。不要凭空推断文件系统情况：列出目录。如果无法为路径提供依据，就如实说明，不要猜。
测量不到任何内容却能通过的模式
| 陷阱 | 为什么能通过 | 应改为 |
|---|---|---|
pnpm ls vite | grep -E '^vite@7' | 树形输出每行都以 └── 开头，因此 ^ 永远无法匹配 | 去掉锚点，或匹配 (└|├)── vite@7 |
npm test | grep '714 passed' | 这个计数是凭记忆想起来的，可能来自过时的训练数据 | grep -E '[0-9]+ passed'，或先运行并获取计数 |
X=$(cmd 2>/dev/null || echo 0)，然后用 [ "$X" = "$Y" ] 判断 | 输入缺失时两侧都默认为 0，所以什么也没检查也会通过 | 让失败状态向上传递，或用 test -f 检查并退出 |
grep -c 'LITERAL' file == 0，而指令或注释中引用了 LITERAL | 门禁被注释文本触发，而非代码 | 按概念描述禁止项，而不是使用字面文本 |
当文件其他位置的合理改动可能添加 PATTERN 时，使用 ! grep -q PATTERN file | 对整个文件进行否定检查，会导致不同区域间的条件无法满足 | 限定范围：awk '/^def f/,/^def /' file | grep，或使用 AST 检查、单元测试 |
| 匹配不到任何测试的测试名称筛选器 | 没有断言任何内容，却以状态码 0 退出 | 先列出测试（--collect-only、--list），然后运行指定测试 |
将 npm test | tail -20 的退出状态作为判定结果 | 管道的退出状态取决于最后一个命令，因此即使 npm test 失败，tail 也会报告 0 | 在同一命令行开头加上 set -o pipefail; npm test | tail -20（bash、zsh）。前一次工具调用中的 set 不会保留 |
锚点陷阱还有一类类似情况：npm ls、yarn list、docker ps 和 kubectl get 都会输出带列前缀或树形前缀的内容。只有在“缺失”是默认情况，且该值不会用于检测缺失的比较时，才可以使用 || echo default。
审查他人命令
只报告；绝不要指定未经验证的替代路径。照抄命令中指定的路径不提供任何信息。缺少目录或清单时，属于阻塞问题：引用原始目标。动态路径、glob、~ 或变量是警告，不是允许你猜测具体路径的许可。