Install in seconds
Install this skill
Copy the command and run it in your terminal. You can review the source before installing.
terminal
git clone https://github.com/a5c-ai/babysitter

Works with Git. The repository opens in your current directory.

🔧
DevOpsJavaScript

Fix Failing Pipelines

by a5c-ai

Detects failing GitHub Actions workflows on a staging branch, diagnoses the cause, and dispatches an automated fix agent to repair them directly on the branch.

1.6K stars94 forksAdded 2026/07/20
agent-orchestrationagent-skillsagentic-aiagentic-workflowai-agentsai-automationbabysitterclaude-codeclaude-code-skillsclaude-code-workflowsclaude-skillsclaude-workflowscodex-plugincodex-skillscodex-workflowhermes-pluginpi-extensiontrustworthy-aivibe-coding

Documentation

README

Fix Failing Pipelines

Check GitHub Actions workflows on the staging branch of https://github.com/a5c-ai/babysitter/actions, identify workflows whose most recent run is failing, and dispatch /babysitter:yolo to fix each one.

Workflow

Step 1: Fetch Most Recent Run Per Workflow

Use the gh CLI to list recent workflow runs on the staging branch:

gh run list --repo a5c-ai/babysitter --branch staging --limit 50 --json databaseId,workflowName,status,conclusion,createdAt,headBranch

Group the results by workflowName. For each workflow, keep only the most recent run (by createdAt). Discard workflows where the most recent run is still in_progress -- we only care about completed runs.

Step 2: Identify Failures

From the grouped results, select only workflows where the most recent completed run has conclusion: "failure". Skip workflows whose latest run succeeded, was cancelled, or is still running.

If no workflows have a failing most-recent run, report that all staging pipelines are green and stop.

Step 3: Get Failure Details

For each failing workflow run, fetch the failed job and step details:

gh run view <run_id> --repo a5c-ai/babysitter --json jobs --jq '.jobs[] | select(.conclusion == "failure") | {name, conclusion, steps: [.steps[] | select(.conclusion == "failure") | .name]}'

Then fetch the logs to understand the actual error:

gh run view <run_id> --repo a5c-ai/babysitter --log-failed 2>&1 | tail -100

Step 4: Present Failures

Display the list of failing workflows to the user with:

  • Workflow name
  • Run ID and link
  • Failed job name(s) and failed step name(s)
  • Brief summary of the error from the logs

Step 5: Fix via Babysitter

For each failing workflow, invoke the babysitter:yolo skill with a prompt that includes the failure context:

/babysitter:yolo fix the failing "<workflow_name>" pipeline on staging. The most recent run (<run_id>) failed in job "<job_name>" at step "<step_name>". Error details: <brief_error_summary>. Investigate the failure, fix the root cause, and push a fix to the staging branch. Do not create a new branch -- commit directly to staging.

If multiple workflows are failing, process them sequentially -- complete one before starting the next. Present a summary after each fix attempt.

Step 6: Verify Fixes

After pushing a fix for each workflow, wait briefly then check if a new run was triggered:

gh run list --repo a5c-ai/babysitter --branch staging --workflow "<workflow_file>" --limit 1 --json databaseId,status,conclusion

Report whether a new run was triggered and its current status. Do not wait for it to complete -- just confirm it was triggered.

Step 7: Summary

After all failing workflows have been addressed, provide a summary:

  • Which workflows were failing
  • What was fixed for each
  • Whether new runs were triggered
  • Any workflows that could not be fixed (with reason)

Notes

  • Only the most recent run per workflow type matters. Older failures that have since been superseded by a success are not actionable.
  • Runs that are in_progress are skipped entirely -- they haven't concluded yet.
  • Cancelled runs are not treated as failures.
  • The gh CLI must be authenticated. If authentication fails, prompt the user to run gh auth login.
  • Each fix is handed off to /babysitter:yolo which handles the actual implementation work non-interactively.
  • Fixes are committed directly to staging -- no feature branches or PRs for pipeline fixes.
  • The entire workflow should be without any user interaction or breakpoints in the run, allowing for seamless pipeline repair.
  • if you fixed it, wait for the new run to be completed and check if it succeeded. if it failed again, iterate on the fix until it succeeds.