autonomous-ci
コードの完成を宣言したり、変更を保存したりする前に、ローカル環境とリモート環境の両方でテストが成功していることを確認し、その証拠を示すことで品質を保証するSkill。
📜 元の英語説明(参考)
Ensures Claude verifies both local tests AND remote CI before claiming completion. Use BEFORE any completion claims, commits, or pull requests. Mandatory verification with evidence.
🇯🇵 日本人クリエイター向け解説
コードの完成を宣言したり、変更を保存したりする前に、ローカル環境とリモート環境の両方でテストが成功していることを確認し、その証拠を示すことで品質を保証するSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o autonomous-ci.zip https://jpskill.com/download/17166.zip && unzip -o autonomous-ci.zip && rm autonomous-ci.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/17166.zip -OutFile "$d\autonomous-ci.zip"; Expand-Archive "$d\autonomous-ci.zip" -DestinationPath $d -Force; ri "$d\autonomous-ci.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
autonomous-ci.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
autonomous-ciフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
自律的な 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 "Fix: issue description"
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 passed"
else
echo "❌ CI failed - analyzing logs"
gh run view "$RUN_ID" --log-failed
fi
ステップ 4: 失敗の処理
CI が失敗した場合:
- 失敗ログをダウンロード:
gh run view <run-id> --log-failed - 根本原因を分析
- 問題を修正
- ステップ 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>
# アップロードが完了したことを確認
# 「Upload complete」メッセージのワークフローログを確認
成功基準
Claude は、以下の場合にのみ完了を主張できます。
- ✅ ローカルテストに合格した (実行して検証済み)
- ✅ コードがコミットおよびプッシュされた
- ✅ CI ワークフローが見つかり、監視されている
- ✅ すべての CI チェックがステータス「success」で合格した
- ✅ 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) がインストールされ、認証されている - GitHub Actions を使用した Git リポジトリ
- テストスイートを備えたプロジェクト
結論
近道なし。例外なし。合理化なし。
- ローカルテストを実行
- コードをプッシュ
- CI を待機 (ブロッキング)
- 失敗を修正して繰り返す
- CI が合格した場合にのみ完了を主張
これは交渉の余地がありません。
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Autonomous CI Verification
Overview
Never claim success without CI verification. This skill ensures Claude automatically verifies both local tests AND remote CI before declaring work complete.
Core Principle: Evidence before claims. Always.
When to Use This Skill
This skill is MANDATORY before:
- ANY completion claims
- ANY expressions of satisfaction ("Done!", "Fixed!", "Working now!")
- Committing code
- Creating pull requests
- Moving to next task
- Responding "should work" or similar phrases
The Verification Protocol
BEFORE claiming any completion:
1. RUN LOCAL VERIFICATION
└─> Execute project-specific test command
└─> Check exit code
└─> If fails: Fix and repeat
2. COMMIT AND PUSH
└─> Only if local tests pass
└─> Push to remote repository
3. MONITOR CI (BLOCKING)
└─> Find workflow run for commit
└─> WAIT for completion (do not proceed)
└─> Check all workflows in .github/workflows/
4. IF CI FAILS
└─> Download failure logs
└─> Analyze root cause
└─> Fix the issue
└─> REPEAT from step 1
5. ONLY WHEN ALL CI PASSES
└─> Report success with evidence
Available Tools
This skill uses scripts from the plugin directory:
Local Verification
The plugin provides a generic test runner that auto-detects your project type:
# For .NET projects
dotnet test --configuration Release
# For Node.js projects
npm test
# For Python projects
pytest
# For Go projects
go test ./...
Claude will automatically detect your project type and run the appropriate command.
CI Monitoring
After pushing, Claude will use GitHub CLI to monitor CI:
# Find and watch workflow run
gh run list --limit 1 --commit <sha>
gh run watch <run-id>
# Check final status
gh run view <run-id> --json conclusion
Red Flags - STOP Immediately
If Claude catches itself thinking or about to say:
- ❌ "Should work now"
- ❌ "Tests pass locally, we're done"
- ❌ "I'll push and assume it works"
- ❌ "Let me commit this and move on"
- ❌ "The change is small, CI will pass"
- ❌ "Pushed! ✅" (without waiting for CI)
STOP. Run the verification protocol instead.
The Workflow
Step 1: Local Verification
# ALWAYS verify locally first
# For .NET:
dotnet build --configuration Release
dotnet test --no-build --configuration Release
# For Node.js:
npm run build
npm test
# For Python:
pytest
# ONLY proceed if exit code = 0
Step 2: Commit and Push
# Only after local tests pass
git add .
git commit -m "Fix: issue description"
git push
Step 3: Monitor CI (Blocking)
# Get commit SHA
COMMIT_SHA=$(git rev-parse HEAD)
# Find workflow run
RUN_ID=$(gh run list --commit "$COMMIT_SHA" --limit 1 --json databaseId -q '.[0].databaseId')
# Watch workflow (BLOCKS until complete)
gh run watch "$RUN_ID"
# Check conclusion
CONCLUSION=$(gh run view "$RUN_ID" --json conclusion -q .conclusion)
if [ "$CONCLUSION" = "success" ]; then
echo "✅ CI passed"
else
echo "❌ CI failed - analyzing logs"
gh run view "$RUN_ID" --log-failed
fi
Step 4: Handle Failures
When CI fails:
- Download failure logs:
gh run view <run-id> --log-failed - Analyze root cause
- Fix the issue
- REPEAT from step 1 (run local tests again)
Common Rationalizations (All Wrong)
| Excuse | Reality |
|---|---|
| "Tests passed locally" | CI environment may differ |
| "It's a small change" | Small changes break CI too |
| "I'm confident" | Confidence ≠ verification |
| "CI takes too long" | Waiting is mandatory |
| "I'll check later" | No. Check now. |
| "Just this once" | No exceptions. Ever. |
Project-Specific Examples
.NET Multi-Framework Projects
# Local verification
dotnet test --configuration Release
# This runs ALL target frameworks
# Example: net8.0, net9.0, net10.0
Multi-Workflow Projects
For projects with multiple CI workflows (tests.yml, lint.yml, build.yml):
# Monitor ALL workflows
gh run list --commit <sha> --json databaseId,name,conclusion
# All must pass:
# ✅ tests.yml: success
# ✅ lint.yml: success
# ✅ build.yml: success
Projects with Test Results Upload
Some projects upload test results to services like Codecov:
# Wait for primary workflow
gh run watch <run-id>
# Verify uploads completed
# Check workflow logs for "Upload complete" messages
Success Criteria
Claude may ONLY claim completion when:
- ✅ Local tests passed (verified by running them)
- ✅ Code committed and pushed
- ✅ CI workflow(s) found and monitored
- ✅ ALL CI checks passed with status "success"
- ✅ Claude has URLs/logs as evidence
Reporting Success
When all checks pass, report with evidence:
✅ Verification Complete
Local Tests: 159/159 passed
CI Status: All checks passed
Workflows:
- tests.yml: ✅ success
https://github.com/user/repo/actions/runs/12345
- lint.yml: ✅ success
https://github.com/user/repo/actions/runs/12346
Commit: abc123def
Timestamp: 2025-11-21 15:30:45
Work is verified complete.
Why This Matters
From painful experience:
- "Should work" → CI fails → wasted time
- Skipping verification → broken main branch
- False completion → lost trust
- Claiming success without evidence → dishonesty
Requirements
- GitHub CLI (
gh) installed and authenticated - Git repository with GitHub Actions
- Project with test suite
The Bottom Line
No shortcuts. No exceptions. No rationalizations.
- Run local tests
- Push code
- Wait for CI (blocking)
- Fix failures and repeat
- Only claim completion when CI passes
This is non-negotiable.