home / skills / duc01226 / easyplatform / fix-ci

fix-ci skill

/.claude/skills/fix-ci

This skill analyzes GitHub Actions logs for C# projects, identifies root causes, and guides automated fixes and test validation.

npx playbooks add skill duc01226/easyplatform --skill fix-ci

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
1.3 KB
---
name: fix-ci
description: "[Fix & Debug] ⚡ Analyze Github Actions logs and fix issues"
argument-hint: [github-actions-url]
infer: true
---

## ⚠️ Anti-Hallucination Reminder

**Before modifying ANY code:** Verify assumptions with actual code evidence. Search for usages, read implementations, trace dependencies. If confidence < 90% on any change, investigate first or ask user. See `.claude/skills/shared/anti-hallucination-protocol.md` for full protocol.

## Github Actions URL
<url>$ARGUMENTS</url>

## Workflow
1. Use `debugger` subagent to read the github actions logs with `gh` command, analyze and find the root cause of the issues and report back to main agent.
2. Start implementing the fix based the reports and solutions.
3. Use `tester` agent to test the fix and make sure it works, then report back to main agent.
4. If there are issues or failed tests, repeat from step 2.
5. After finishing, respond back to user with a summary of the changes and explain everything briefly, guide user to get started and suggest the next steps.

## Notes
- If `gh` command is not available, instruct the user to install and authorize GitHub CLI first.

## IMPORTANT Task Planning Notes

- Always plan and break many small todo tasks
- Always add a final review todo task to review the works done at the end to find any fix or enhancement needed

Overview

This skill analyzes failing GitHub Actions runs, finds root causes in logs, implements fixes, and verifies results. It orchestrates a read-analyze-fix-test loop and delivers a concise summary of changes and next steps. The goal is fast, evidence-driven CI recovery with minimal risk to the codebase.

How this skill works

The skill reads GitHub Actions logs and related repository files to identify the failure point and its root cause. It proposes targeted code, workflow, or configuration changes, applies them in small, testable commits, and runs verification tests. If the GitHub CLI is unavailable, it instructs you to install and authorize it before proceeding. It always checks usages and implementations to avoid assumptions before modifying code.

When to use it

  • A GitHub Actions workflow is failing and logs are unclear or voluminous.
  • You need a step-by-step, tested fix for flaky or broken CI pipelines.
  • You want automated log analysis plus concrete patch suggestions or commits.
  • You prefer changes applied incrementally with verification after each fix.
  • You need guidance to reproduce, debug, and harden CI to prevent regressions.

Best practices

  • Verify assumptions with direct code and log evidence before changing anything.
  • Break fixes into small, reviewable tasks and include a final review task.
  • Run local or isolated tests that mimic CI before pushing changes to main branches.
  • Prefer configuration or dependency fixes over invasive code changes when possible.
  • Document the root cause, the applied fix, and any follow-up actions for maintainers.

Example use cases

  • Fixing a workflow that fails due to missing secrets or improper GitHub permissions.
  • Resolving test failures caused by environment mismatch or flaky tests in CI.
  • Updating outdated actions or dependency versions that break the pipeline.
  • Adjusting job timeouts, matrix setups, or platform-specific commands to pass CI.
  • Diagnosing and correcting intermittent network or rate-limit failures in GitHub Actions.

FAQ

Do you need access to my repository or GH CLI?

To read logs and apply fixes, the skill needs the workflow run URL and either local access or a GitHub CLI setup. If gh is not installed, you will be guided to install and authorize it.

How do you avoid making incorrect code changes?

I follow an evidence-first protocol: search usages, read implementations, and trace dependencies. If confidence is under ~90%, I investigate more or ask for clarification before changing code.