agentleFS
ailessonioailessonio/open-source-skills/skills/openai/gh-fix-ci/SKILL.md

gh-fix-ci

Skill0 starsChanged 2 months agoMITView on GitHub

Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.

36 other projects use a version of this, 24 of them edited; 1 new project in the last 4 weeks, against 1 the 4 before.

Adopted by

Steady: 1 new project took it in the last 4 weeks, 1× the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 1 new projectWeek of Oct 11: 1 new projectWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 2 in all, so this is a hint, not a trend.

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 23 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 11
  2. Very specific:

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

    line 12
  3. Very specific:

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

    line 25
  4. Very specific:

    Run gh auth status in the repo.

    line 30
  5. Very specific:

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

    line 31
  6. Very specific:

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

    line 33
  7. Common:

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

    line 34
  8. Very specific:

    Add --json for machine-friendly output.

    line 38
  9. Very specific:

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

    line 41
  10. Common:

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

    line 45
  11. Very specific:

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

    line 48
  12. Common:

    Do not attempt Buildkite or other providers.

    line 49
  13. Common:

    Call out missing logs explicitly.

    line 52
  14. Very specific:

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

    line 54
  15. Very specific:

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

    line 58

“Common” is measured: kept by at least 6 in 10 of the 23 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.