agentleFS
Sign inStart free
Anmolop97Anmolop97/Agent-Skills/skills/gh-fix-ci/SKILL.md

gh-fix-ci

Skill1 starsChanged 27 days agoMITView on GitHub

Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions. Uses `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treats external providers (for example Buildkite) as out of scope and reports only the details URL. Do NOT use for addressing PR review comments (use gh-address-comments) or general CI outside GitHub Actions.

35 other projects use a version of this, 33 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use codebase-migrate, email-draft-polish and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • ComposioHQSkill

    codebase-migrate

    Run large codebase migrations and multi-file refactors. Uses the Composio CLI to coordinate issue tracking, batched PRs, and CI verification while the agent executes the transforms locally across hundreds of files.

    Also in 5 projects that use this

  • ComposioHQSkill

    email-draft-polish

    Draft, rewrite, or condense emails with target tone, length, and audience; use for cold outreach, replies, status updates, or escalations where clarity and brevity matter.

    Also in 4 projects that use this

  • petestewartSkill

    datadog-logs

    Query Datadog logs via the Logs Search API v2. Use when the user asks to "check the logs", "search logs", "find errors in Datadog", "look up logs for", "show me production logs", "check for errors", "search Datadog", or any request involving log search, error investigation, or production debugging that requires Datadog log data.

    Also in 3 projects that use this

  • MicrosoftSkill

    deploy-pipeline

    Triggers a Power Platform Pipeline deployment run for a Power Pages solution. Selects a target stage, validates the package, optionally configures deployment settings (environment variables, connection references), then deploys and polls for completion. Use when asked to: "deploy pipeline", "run pipeline", "trigger deployment", "deploy to staging", "deploy to production", "run power platform pipeline", "deploy solution via pipeline", "promote solution", "push to staging", "push to production".

    Also in 3 projects that use this

  • +8 more from ComposioHQ

The file

Show its rules and text

We split this skill into the rules it gives an agent

15 rules. 5 are common, 0 are distinctive, and 10 are very specific to this project.

  • 5

    Common

    Most of the 32 edited versions we read keep these.

  • 0

    Distinctive

    This author's own choices. Worth a look.

  • 10

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix …

    line 13
  2. Very specific:

    If a plan-oriented skill (for example create-plan) is available, use it.

    line 15
  3. Very specific:

    Add --json if you want machine-friendly output for summarization.

    line 28
  4. Very specific:

    Run gh auth status in the repo.

    line 33
  5. Very specific:

    If unauthenticated, ask the user to run gh auth login (ensuring repo + workflow scopes) before proceeding.

    line 34
  6. Very specific:

    Prefer the current branch PR: gh pr view --json number,url.

    line 36
  7. Common:

    If the user provides a PR number or URL, use that directly.

    line 37
  8. Very specific:

    Add --json for machine-friendly output.

    line 41
  9. Very specific:

    If a field is rejected, rerun with the available fields reported by gh.

    line 44
  10. Common:

    If the run log says it is still in progress, fetch job logs directly:

    line 48
  11. Very specific:

    If detailsUrl is not a GitHub Actions run, label it as external and only report the URL.

    line 51
  12. Common:

    Do not attempt Buildkite or other providers.

    line 52
  13. Common:

    Call out missing logs explicitly.

    line 55
  14. Very specific:

    Use the create-plan skill to draft a concise plan and request approval.

    line 57
  15. Very specific:

    After changes, suggest re-running the relevant tests and gh pr checks to confirm.

    line 61

“Common” is measured: kept by at least 6 in 10 of the 32 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Gh Pr Checks Plan Fix

Overview

Use gh to locate failing PR checks, fetch GitHub Actions logs for actionable failures, summarize the failure snippet, then propose a fix plan and implement after explicit approval.

  • If a plan-oriented skill (for example create-plan) is available, use it; otherwise draft a concise plan inline and request approval before implementing.

Prereq: authenticate with the standard GitHub CLI once (for example, run gh auth login), then confirm with gh auth status (repo + workflow scopes are typically required).

Inputs

  • repo: path inside the repo (default .)
  • pr: PR number or URL (optional; defaults to current branch PR)
  • gh authentication for the repo host

Quick start

  • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"
  • Add --json if you want machine-friendly output for summarization.

Workflow

  1. Verify gh authentication.
    • Run gh auth status in the repo.
    • If unauthenticated, ask the user to run gh auth login (ensuring repo + workflow scopes) before proceeding.
  2. Resolve the PR.
    • Prefer the current branch PR: gh pr view --json number,url.
    • If the user provides a PR number or URL, use that directly.
  3. Inspect failing checks (GitHub Actions only).
    • Preferred: run the bundled script (handles gh field drift and job-log fallbacks):
      • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "<number-or-url>"
      • Add --json for machine-friendly output.
    • Manual fallback:
      • gh pr checks <pr> --json name,state,bucket,link,startedAt,completedAt,workflow
        • If a field is rejected, rerun with the available fields reported by gh.
      • For each failing check, extract the run id from detailsUrl and run:
        • gh run view <run_id> --json name,workflowName,conclusion,status,url,event,headBranch,headSha
        • gh run view <run_id> --log
      • If the run log says it is still in progress, fetch job logs directly:
        • gh api "/repos/<owner>/<repo>/actions/jobs/<job_id>/logs" > "<path>"
  4. Scope non-GitHub Actions checks.
    • If detailsUrl is not a GitHub Actions run, label it as external and only report the URL.
    • Do not attempt Buildkite or other providers; keep the workflow lean.
  5. Summarize failures for the user.
    • Provide the failing check name, run URL (if any), and a concise log snippet.
    • Call out missing logs explicitly.
  6. Create a plan.
    • Use the create-plan skill to draft a concise plan and request approval.
  7. Implement after approval.
    • Apply the approved plan, summarize diffs/tests, and ask about opening a PR.
  8. Recheck status.
    • After changes, suggest re-running the relevant tests and gh pr checks to confirm.

Bundled Resources

scripts/inspect_pr_checks.py

Fetch failing PR checks, pull GitHub Actions logs, and extract a failure snippet. Exits non-zero when failures remain so it can be used in automation.

Usage examples:

  • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "123"
  • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --pr "https://github.com/org/repo/pull/123" --json
  • python "<path-to-skill>/scripts/inspect_pr_checks.py" --repo "." --max-lines 200 --context 40

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free