Now liveThe Skillselion MCP - thousands of ranked skills, loaded into your agent mid-task. No install.Get it →
dicklesworthstone avatar

Fetch Ci Build

  • 1 installs
  • 1.5k repo stars
  • Updated August 5, 2026
  • dicklesworthstone/pi_agent_rust

Fetches CI build results, auto-detects the provider, diagnoses failures, and proposes fixes for GitHub Actions, Buildkite, and CircleCI.

About

Detects the CI provider from project files or a URL, fetches build results, reads failing source files, and presents proposed fixes. A developer uses it to diagnose and fix failing CI builds.

  • Auto-detects GitHub Actions, Buildkite, or CircleCI from files or URLs
  • Reads failing files, proposes fixes, and defers to systematic-debugging

Fetch Ci Build by the numbers

  • 1 all-time installs (skills.sh)
  • Ranked #1,172 of 1,435 DevOps & CI/CD skills by installs in the Skillselion catalog
  • Data as of Aug 5, 2026 (Skillselion catalog sync)
npx skills add https://github.com/dicklesworthstone/pi_agent_rust --skill fetch-ci-build

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

Listed on Skillselion
Installs1
repo stars1.5k
Last updatedAugust 5, 2026
Repositorydicklesworthstone/pi_agent_rust

What it does

Fetches CI build results, auto-detects the provider, diagnoses failures, and proposes fixes for GitHub Actions, Buildkite, and CircleCI.

Files

SKILL.mdMarkdownGitHub ↗

Fetch CI Build

Overview

Fetch CI build results, diagnose failures, extract actionable error information, and suggest fixes. Supports multiple CI providers with automatic detection.

Supported Providers

ProviderDetectionTool
GitHub Actions.github/workflows/ or github.com URLgh CLI
Buildkite.buildkite/ or buildkite.com URLPython script
CircleCI.circleci/ or circleci.com URLPython script

Auto-Detection

From URL

If the user provides a CI URL, detect provider:

  • github.com/.../actions/runs/... → GitHub Actions
  • buildkite.com/... → Buildkite
  • app.circleci.com/... or circleci.com/... → CircleCI

From Project Files

Check for CI configuration directories:

# GitHub Actions
test -d .github/workflows && echo "github"

# Buildkite
test -d .buildkite && echo "buildkite"

# CircleCI
test -d .circleci && echo "circleci"

Workflow

digraph workflow {
    rankdir=TB;
    node [shape=box];
    
    detect [label="1. Detect CI provider"];
    load [label="2. Load provider reference"];
    fetch [label="3. Fetch build results"];
    check [label="4. Check for failures" shape=diamond];
    passed [label="Report: Build passed!"];
    read [label="5. Read failing source files"];
    present [label="6. Present failures + proposed fixes"];
    ask [label="7. Ask: Apply fix?" shape=diamond];
    apply [label="Apply the fix"];
    complex [label="Complex failure?" shape=diamond];
    debug [label="Use systematic-debugging skill"];
    next [label="Next failure?" shape=diamond];
    done [label="Done"];
    
    detect -> load;
    load -> fetch;
    fetch -> check;
    check -> passed [label="passed"];
    check -> read [label="failed"];
    read -> present;
    present -> ask;
    ask -> apply [label="yes"];
    ask -> complex [label="no"];
    apply -> next;
    complex -> debug [label="yes"];
    complex -> next [label="no"];
    debug -> next;
    next -> read [label="yes"];
    next -> done [label="no"];
}

Step-by-Step Process

1. Detect CI Provider

First, check if the user provided a URL. If not, detect from project files.

2. Load Provider Reference

Read the appropriate reference file for provider-specific commands:

  • GitHub: references/github.md
  • Buildkite: references/buildkite.md
  • CircleCI: references/circleci.md

3. Fetch Build Results

Use the provider-specific commands to fetch build information and failures.

4. For Each Failure

Read the relevant source file to understand context:

  • For test failures: read the test file at the indicated line
  • For lint errors: read the source file at the indicated line
  • For TypeScript errors: read the file and understand the type issue

5. Present Findings and Propose Fix

Show the user:

  • What failed (test name, file, line)
  • Error message
  • Proposed fix based on the error

6. Ask User What To Do

Ask how to proceed:

  • "Apply the suggested fix"
  • "Investigate further before fixing"
  • "Skip this failure"
  • "Use systematic-debugging for deeper investigation"

7. Complex Failures

If the failure requires deeper investigation (e.g., unclear root cause, flaky test, environmental issue), recommend the systematic-debugging skill.

Error Types Detected

TypeDetectionCommon Fixes
Test failureMinitest/RSpec/Jest/pytest outputFix assertion, update expected value, fix test setup
Lint errorRubocop/ESLint/Biome violationsAuto-fix with linter's fix command
TypeScriptTSC compilation errorsAdd types, fix type mismatches
Build errorCompilation failuresFix syntax, missing dependencies

Common Mistakes

MistakeSolution
Can't detect providerSpecify provider explicitly or provide CI URL
Missing credentialsCheck provider reference for required env vars/auth
Build still runningWait for completion or check partial results
Rate limitingWait and retry

Integration with Other Skills

  • systematic-debugging: Use for complex failures requiring root cause analysis
  • test-driven-development: After fixing, ensure tests follow TDD principles
  • verification-before-completion: Run tests locally before pushing fix

Related skills

This week in AI coding

Five minutes, every Monday - the tools, releases and tactics for developers.

unsubscribe anytime.