jpskill.com
🛠️ 開発・MCP コミュニティ

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本体の挙動とは独立した参考情報です。

⚡ おすすめ: コマンド1行でインストール(60秒)

下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。

🍎 Mac / 🐧 Linux
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
🪟 Windows (PowerShell)
$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. 1. 下の青いボタンを押して autonomous-ci.zip をダウンロード
  2. 2. ZIPファイルをダブルクリックで解凍 → autonomous-ci フォルダができる
  3. 3. そのフォルダを C:\Users\あなたの名前\.claude\skills\(Win)または ~/.claude/skills/(Mac)へ移動
  4. 4. Claude Code を再起動

⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。

🎯 このSkillでできること

下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。

📦 インストール方法 (3ステップ)

  1. 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
  2. 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
  3. 3. 展開してできたフォルダを、ホームフォルダの .claude/skills/ に置く
    • · macOS / Linux: ~/.claude/skills/
    • · Windows: %USERPROFILE%\.claude\skills\

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 が失敗した場合:

  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>

# アップロードが完了したことを確認
# 「Upload complete」メッセージのワークフローログを確認

成功基準

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) がインストールされ、認証されている
  • GitHub Actions を使用した Git リポジトリ
  • テストスイートを備えたプロジェクト

結論

近道なし。例外なし。合理化なし。

  1. ローカルテストを実行
  2. コードをプッシュ
  3. CI を待機 (ブロッキング)
  4. 失敗を修正して繰り返す
  5. 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:

  1. Download failure logs: gh run view <run-id> --log-failed
  2. Analyze root cause
  3. Fix the issue
  4. 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:

  1. ✅ Local tests passed (verified by running them)
  2. ✅ Code committed and pushed
  3. ✅ CI workflow(s) found and monitored
  4. ✅ ALL CI checks passed with status "success"
  5. ✅ 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.

  1. Run local tests
  2. Push code
  3. Wait for CI (blocking)
  4. Fix failures and repeat
  5. Only claim completion when CI passes

This is non-negotiable.