multiAI Summary Pending

autonomous-ci

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.

231 stars

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/autonomous-ci/SKILL.md --create-dirs "https://raw.githubusercontent.com/aiskillstore/marketplace/main/skills/ancplua/autonomous-ci/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/autonomous-ci/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How autonomous-ci Compares

Feature / Agentautonomous-ciStandard Approach
Platform SupportmultiLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

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.

Which AI agents support this skill?

This skill is compatible with multi.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

SKILL.md Source

# 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

```text
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:

```bash
# 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:

```bash
# 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

```bash
# 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

```bash
# Only after local tests pass
git add .
git commit -m "Fix: issue description"
git push
```

### Step 3: Monitor CI (Blocking)

```bash
# 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

```bash
# 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):

```bash
# 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:

```bash
# 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:

```text
✅ 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.