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.
What this skill does
# 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.
Related in Cloud & DevOps
appbuilder-action-scaffolder
IncludedCreate, implement, deploy, and debug Adobe Runtime actions with consistent layout, validation, and error handling. Use this skill whenever the user needs to add actions to an App Builder project, understand action structure (params, response format, web/raw actions), configure actions in the manifest, use App Builder SDKs (State, Files, Events, database), deploy and invoke actions via CLI, debug action issues, or implement patterns such as webhook receivers, custom event providers, journaling consumers, large payload redirects, action sequence pipelines, and Asset Compute workers. Also trigger when users mention serverless functions in Adobe context, action logging, IMS authentication for actions, or cron-style scheduled actions.
orchestrating-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. Use this skill when the user needs a multi-step Data Cloud pipeline, cross-phase troubleshooting, or data space and data kit management. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase sf data360 workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching phase-specific skill), the task is STDM/session tracing/parquet telemetry (use observing-agentforce), standard CRM SOQL (use querying-soql), or Apex implementation (use generating-apex).
github-project-automation
IncludedAutomate GitHub repository setup with CI/CD workflows, issue templates, Dependabot, and CodeQL security scanning. Includes 12 production-tested workflows and prevents 18 errors: YAML syntax, action pinning, and configuration. Use when: setting up GitHub Actions CI/CD, creating issue/PR templates, enabling Dependabot or CodeQL scanning, deploying to Cloudflare Workers, implementing matrix testing, or troubleshooting YAML indentation, action version pinning, secrets syntax, runner versions, or CodeQL configuration. Keywords: github actions, github workflow, ci/cd, issue templates, pull request templates, dependabot, codeql, security scanning, yaml syntax, github automation, repository setup, workflow templates, github actions matrix, secrets management, branch protection, codeowners, github projects, continuous integration, continuous deployment, workflow syntax error, action version pinning, runner version, github context, yaml indentation error
sf-datacloud
IncludedSalesforce Data Cloud product orchestrator for connect→prepare→harmonize→segment→act workflows. TRIGGER when: user needs a multi-step Data Cloud pipeline, asks to set up or troubleshoot Data Cloud across phases, manages data spaces or data kits, or wants a cross-phase `sf data360` workflow. DO NOT TRIGGER when: work is isolated to a single phase (use the matching sf-datacloud-* skill), the task is STDM/session tracing/parquet telemetry (use sf-ai-agentforce-observability), standard CRM SOQL (use sf-soql), or Apex implementation (use sf-apex).
fabric-cli
IncludedUse this skill for Fabric.so CLI workflows with the `fabric` terminal command: diagnose/install/login, search or browse a Fabric library, save notes/links/files, create folders, ask the Fabric AI assistant, manage tasks/workspaces, generate shell completion, check subscription usage, produce JSON output, and use Fabric as persistent agent memory. Do not use for Microsoft Fabric/Azure/Power BI `fab`, Daniel Miessler's Fabric framework, Python Fabric SSH, Fabric.js, or textile/fashion fabric.
lark
IncludedLark/Feishu CLI skills: lark-cli operations for docs, markdown, sheets, base, calendar, im, mail, task, okr, drive, wiki, slides, whiteboard, apps, approval, attendance, contact, vc, minutes, event. Use when the user needs to operate Lark/Feishu resources via lark-cli, send messages, manage documents, spreadsheets, calendars, tasks, OKRs, deploy web pages, or any Feishu/Lark workspace operations.