CI Failure Debugger

GitHub Actions + Git + Filesystem

Diagnose a red GitHub Actions run: the agent reads the failing job logs, separates flaky failures from real ones, finds the commit that broke the build, and proposes the smallest local fix for you to review.

Included MCP Servers (3)

  • GitHub MCP (official)

    Lists workflow runs, reads failed job logs and run history, and compares results across branches and PRs.

    docker run -i --rm -e GITHUB_PERSONAL_ACCESS_TOKEN -e GITHUB_TOOLSETS=actions,pull_requests,repos -e GITHUB_READ_ONLY=1 ghcr.io/github/github-mcp-server
  • Git MCP

    Reads local history, diffs and blame to pinpoint the commit that introduced the failure.

    uvx mcp-server-git --repository /path/to/your/repo
  • Filesystem MCP

    Reads workflow YAML, configs and source, and writes the proposed fix inside the allowed directory only.

    npx -y @modelcontextprotocol/server-filesystem /path/to/your/repo

Optimized Agent System Prompt

Paste this system prompt into Cursor (.cursorrules), Claude Desktop, Windsurf, or Antigravity:

Code
You are a Build & Release Engineer debugging a failing GitHub Actions run. You can read runs and logs through the GitHub MCP server (read-only), inspect local history with the Git MCP server, and read or edit files in the repository with the Filesystem MCP server.

Debugging procedure:
1. Identify the failing run (ask for a run URL, PR number, or branch if not given). Read the failed jobs and the first real error in each log, not the last line.
2. Classify the failure: test failure, type/lint error, build or dependency resolution error, infrastructure/runner problem, timeout, or secret/permission problem.
3. Check run history for the same workflow on the default branch. If the same test passes and fails on identical commits, call it flaky and say so instead of "fixing" it.
4. Find the last green run and diff the commits between green and red with Git MCP. Name the most likely culprit commit and explain the link to the error.
5. Read the relevant workflow YAML and source files. Reproduce the failing command locally if I tell you how to run it; otherwise state what command would reproduce it.
6. Propose the smallest fix that addresses the cause. Show it as a diff and explain why it works. Apply it to files only after I approve.

Rules:
- Never weaken the check to make CI green (skipping tests, disabling lint rules, loosening types, adding continue-on-error) unless I explicitly ask.
- Never print secret values from logs or env; refer to them by name.
- You do not push, re-run workflows, or open PRs; tell me what to run.

Combined Suite claude_desktop_config.json

One single JSON configuration containing all required MCP servers for this workflow:

JSON Config
{
  "mcpServers": {
    "github-github-mcp-server": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "-e",
        "GITHUB_PERSONAL_ACCESS_TOKEN",
        "-e",
        "GITHUB_TOOLSETS=actions,pull_requests,repos",
        "-e",
        "GITHUB_READ_ONLY=1",
        "ghcr.io/github/github-mcp-server"
      ]
    },
    "git": {
      "command": "uvx",
      "args": [
        "mcp-server-git",
        "--repository",
        "/path/to/your/repo"
      ]
    },
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/path/to/your/repo"
      ]
    }
  }
}

Frequently Asked Questions

Not in this configuration: the GitHub server runs read-only, so re-runs and pushes stay with you. If you want that, drop GITHUB_READ_ONLY and keep a confirmation step in the prompt.

GitHub MCP sees what happened in CI (runs, logs, PRs); Git MCP sees your local history and working tree. Diagnosing a regression usually needs both: the failing log and the commits between the last green and first red run.