⚡

自主CI验证Skill autonomous-ci

自主CI验证是一种用于软件开发流程的自动化验证技能，确保在声明任务完成前必须通过本地测试和远程持续集成（CI）系统的双重验证。该技能强制要求提供证据，防止虚假完成声明，适用于CI/CD流程、自动化测试、DevOps实践和代码质量保障。关键词包括：CI/CD验证、自动化测试、持续集成、DevOps流程、代码质量、GitHub Actions、测试验证、软件开发流程。

DevOps 0 次安装 0 次浏览 更新于 3/1/2026

name: autonomous-ci description: 确保Claude在声明完成前验证本地测试和远程CI。在任何完成声明、提交或拉取请求前使用。必须提供证据进行验证。

自主CI验证

概述

未经CI验证绝不声明成功。 此技能确保Claude在声明工作完成前自动验证本地测试和远程CI。

核心原则： 证据优先于声明。始终如此。

何时使用此技能

此技能在以下情况前必须使用：

  • 任何完成声明
  • 任何满意表达（“完成！”、“已修复！”、“现在正常了！”）
  • 提交代码
  • 创建拉取请求
  • 转向下一个任务
  • 回应"应该可以了"或类似短语

验证协议

在声明任何完成前：

1. 运行本地验证
   └─> 执行项目特定的测试命令
   └─> 检查退出代码
   └─> 如果失败：修复并重复

2. 提交并推送
   └─> 仅当本地测试通过时
   └─> 推送到远程仓库

3. 监控CI（阻塞式）
   └─> 查找提交对应的工作流运行
   └─> 等待完成（不要继续）
   └─> 检查.github/workflows/中的所有工作流

4. 如果CI失败
   └─> 下载失败日志
   └─> 分析根本原因
   └─> 修复问题
   └─> 从步骤1重复

5. 仅当所有CI通过时
   └─> 提供证据报告成功

可用工具

此技能使用插件目录中的脚本：

本地验证

插件提供通用测试运行器，可自动检测项目类型：

# 对于.NET项目
dotnet test --configuration Release

# 对于Node.js项目
npm test

# 对于Python项目
pytest

# 对于Go项目
go test ./...

Claude将自动检测您的项目类型并运行适当的命令。

CI监控

推送后，Claude将使用GitHub CLI监控CI：

# 查找并监视工作流运行
gh run list --limit 1 --commit <sha>
gh run watch <run-id>

# 检查最终状态
gh run view <run-id> --json conclusion

危险信号 - 立即停止

如果Claude发现自己正在思考或即将说：

  • ❌ “现在应该可以了”
  • ❌ “本地测试通过，我们完成了”
  • ❌ “我会推送并假设它正常工作”
  • ❌ “让我提交这个并继续”
  • ❌ “改动很小，CI会通过的”
  • ❌ “已推送！✅”（未等待CI）

停止。 改为运行验证协议。

工作流程

步骤1：本地验证

# 始终首先本地验证
# 对于.NET：
dotnet build --configuration Release
dotnet test --no-build --configuration Release

# 对于Node.js：
npm run build
npm test

# 对于Python：
pytest

# 仅当退出代码=0时继续

步骤2：提交并推送

# 仅在本地测试通过后
git add .
git commit -m "修复：问题描述"
git push

步骤3：监控CI（阻塞式）

# 获取提交SHA
COMMIT_SHA=$(git rev-parse HEAD)

# 查找工作流运行
RUN_ID=$(gh run list --commit "$COMMIT_SHA" --limit 1 --json databaseId -q '.[0].databaseId')

# 监视工作流（阻塞直到完成）
gh run watch "$RUN_ID"

# 检查结论
CONCLUSION=$(gh run view "$RUN_ID" --json conclusion -q .conclusion)

if [ "$CONCLUSION" = "success" ]; then
  echo "✅ CI通过"
else
  echo "❌ CI失败 - 分析日志中"
  gh run view "$RUN_ID" --log-failed
fi

步骤4：处理失败

当CI失败时：

  1. 下载失败日志：gh run view <run-id> --log-failed
  2. 分析根本原因
  3. 修复问题
  4. 从步骤1重复（再次运行本地测试）

常见合理化借口（都是错误的）

借口 现实
“本地测试通过了” CI环境可能不同
“这只是个小改动” 小改动也会破坏CI
“我很有信心” 信心≠验证
“CI耗时太长” 等待是必须的
“我稍后检查” 不。现在检查。
“就这一次例外” 没有例外。永远没有。

项目特定示例

.NET多框架项目

# 本地验证
dotnet test --configuration Release

# 这会运行所有目标框架
# 示例：net8.0、net9.0、net10.0

多工作流项目

对于具有多个CI工作流的项目（tests.yml、lint.yml、build.yml）：

# 监控所有工作流
gh run list --commit <sha> --json databaseId,name,conclusion

# 所有都必须通过：
# ✅ tests.yml: success
# ✅ lint.yml: success
# ✅ build.yml: success

具有测试结果上传的项目

某些项目将测试结果上传到Codecov等服务：

# 等待主要工作流
gh run watch <run-id>

# 验证上传完成
# 检查工作流日志中的"上传完成"消息

成功标准

Claude仅当以下情况时才能声明完成：

  1. ✅ 本地测试通过（通过运行验证）
  2. ✅ 代码已提交并推送
  3. ✅ CI工作流已找到并监控
  4. ✅ 所有CI检查以"success"状态通过
  5. ✅ Claude拥有URL/日志作为证据

报告成功

当所有检查通过时，提供证据报告：

✅ 验证完成

本地测试：159/159通过
CI状态：所有检查通过

工作流：
  - tests.yml: ✅ success
    https://github.com/user/repo/actions/runs/12345
  - lint.yml: ✅ success
    https://github.com/user/repo/actions/runs/12346

提交：abc123def
时间戳：2025-11-21 15:30:45

工作已验证完成。

为什么这很重要

从痛苦的经验中得知：

  • “应该可以了” → CI失败 → 浪费时间
  • 跳过验证 → 主分支损坏
  • 虚假完成 → 失去信任
  • 没有证据声明成功 → 不诚实

要求

  • GitHub CLI（gh）已安装并认证
  • Git仓库具有GitHub Actions
  • 具有测试套件的项目

底线

没有捷径。没有例外。没有合理化借口。

  1. 运行本地测试
  2. 推送代码
  3. 等待CI（阻塞式）
  4. 修复失败并重复
  5. 仅当CI通过时声明完成

这是不可协商的。