better-github-skill
A skill with four gh scripts that gives an agent pull request state, review threads and CI failures in one call and short output.
- 52 ★ on the repository
- Last commit
- MIT
Extended access
Why this level
- The scripts call GitHub through an authenticated `gh` on behalf of the user, but only to read.
Install
- Works in
In your terminal, with SkillFoxx CLI
npx skillfoxx add skills/better-github-skillDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The scripts call GitHub through an authenticated `gh` on behalf of the user, but only to read.
This is third-party code. Review the repository files before installing.
What it does
The skill is built from an analysis of 1,843 `gh` calls in real agent sessions and cuts both their number and the context they use. `pr-snapshot` shows a whole pull request: metadata, mergeability, checks, files, reviews and thread counts in a few dozen dense lines. `pr-threads` returns the full review conversation including unresolved inline threads, with resolved and outdated ones hidden by default. `ci-failures` returns failing jobs, steps and a 45-line snippet around the error, while the full log stays on disk at a printed path. The `pr-watch` script waits until something worth an agent turn happens in a pull request: a check failed, required checks passed, a comment arrived, a conflict appeared or the request merged. It uses GitHub conditional requests, so waiting barely spends the rate limit. `SKILL.md` lists 13 common gotchas, including output truncation from SIGPIPE and a GET silently turning into a POST because of flags.
Who it is for. Developers who hand pull request review and fixes to an agent and want fewer repeated GitHub calls and less bloated context.
Good fit when
- You need the whole picture of a pull request: what changed, whether checks pass, who wrote what.
- Reviewers left many comments and the agent needs only unresolved threads.
- CI failed on several jobs and instead of tens of thousands of log lines you need a snippet around the error.
- The agent waits for checks to finish and must not burn its request limit by polling every three seconds.
Not a fit when
- The work does not involve GitHub: the scripts are built around `gh` and its API.
- You need write operations such as opening a pull request: the scripts only read.
- The machine has no authenticated `gh` and no suitable Node.js version.
Example request
Show the state of pull request 5017 in this repository: checks, unresolved review threads and the cause of the CI failure, without full logs.Limitations
It needs an authenticated `gh` and Node.js 23.6 or newer, because the TypeScript scripts run directly. The scripts only read data and neither create nor change pull requests. For everything else the agent uses plain `gh`, and `SKILL.md` warns about typical failures. Output is deliberately trimmed: message bodies are shortened, files are capped in number and full CI logs go to disk. The savings in the README come from the author sessions and specific test pull requests and may differ on your project.
How to disable. Delete the skill folder from the agent directory, for example `~/.agents/skills/better-github-skill`, and the `~/.claude/skills/better-github-skill` symlink if you created it by hand. A skill installed through `npx skills` is removed with that same manager.
FAQ
How do I install better-github-skill?
Run `npx skills add AVGVSTVS96/better-github-skill` and the manager places the skill in your agent directories. By hand: `git clone https://github.com/AVGVSTVS96/better-github-skill ~/.agents/skills/better-github-skill`, then symlink into `~/.claude/skills/`.
What is needed to run the scripts?
An authenticated `gh` and Node.js 23.6 or newer. `pr-snapshot.ts`, `pr-threads.ts`, `ci-failures.ts` and `pr-watch.ts` run as plain executables, also without the skill harness.
How does pr-watch save the request limit?
It polls once a minute with conditional requests, and GitHub does not charge a 304 answer. A quiet pull request costs about 12 requests an hour against roughly 3,800 for `gh run watch`.
Does the agent see full CI logs?
No, a snippet of about 45 lines around the error per failing job enters the context. The full log is written to disk and its path is printed in the answer.
Which gh gotchas does SKILL.md describe?
Thirteen cases from real sessions: false errors from SIGPIPE, exit-code semantics, GET silently turning into POST with the `-f` and `-F` flags and more. Each comes with a working alternative.
Discussion
No questions or reviews yet.
Related
SkillsGitHub CLI skills
GitHub CLI skills (gh, gh-skill)
Official GitHub CLI skills: how an agent should call gh correctly and how to manage skills with gh skill
Brooklyn skills: 25 portable agent skills for pull requests, triage, cleanup, UI checks and research
The GitHub CLI extension gh stack and an agent skill: a chain of dependent branches and PRs with rebase, submit and merge of the whole stack
Git commands and agent skills: a JIRA branch, an AI commit, a pull request, a description, review and comment fixes.
A skill that searches GitHub for an already proven path to an engineering problem and adapts it to your code with a minimal change
A Go tool for GitHub issues: Markdown files on disk that an agent edits in bulk and the push command sends back.
README in short
The README explains the skill through the analysis of 1,843 `gh` calls and compares it with ordinary command loops. A separate section shows what waiting on a pull request costs in rate limit with various methods, followed by the scripts, tests, a three-agent verification pass and installation.
README badge
Original SKILL.md
---
name: better-github-skill
description: "GitHub work via gh CLI: PRs, review conversations, CI failures, repo state, rate limits. Use when inspecting a PR, reading a review (bodies, comments, inline threads), debugging CI (finding which run failed, why a check or Actions run is red, reading job logs), waiting on or babysitting a PR (CI, reviews, conflicts), or composing non-trivial gh commands. Scripts cover what raw gh can't do (thread resolution state) or reliably fumbles (PR snapshots, CI log drilldown); use raw gh directly for everything else."
---
# better-github-skill
Raw `gh` first when you know the command; the scripts replace only the flows
agents repeatedly get wrong. Scripts run TS directly (node ≥ 23.6), no deps.
## Scripts
| script | use for |
|---|---|
| `scripts/pr-snapshot.ts [pr] [-R o/r]` | full PR state in one call: meta, mergeability, checks, files, reviews, comments, thread counts. Use instead of hand-assembling `pr view --json` field sets or chaining view/checks/comments calls. |
| `scripts/pr-threads.ts [pr] [-R o/r] [--all] [--author X] [--since ISO]` | the full review conversation: review bodies, issue comments, and unresolved inline threads (resolution state porcelain gh cannot get). Resolved/outdated threads are hidden by default, counted in the header; `--all` includes them. Read-only: never reply to or resolve threads unless explicitly told to. |
| `scripts/pr-watch.ts [pr] [-R o/r] [--timeout 9m]` | wait on a PR: blocks until a check fails, the required or all checks pass, someone else comments or reviews, the branch conflicts, or the PR merges or closes; prints what happened. Rerun after acting; it never repeats news. Quiet PRs cost nothing (conditional requests). Run it in the background, or give the tool a timeout above `--timeout`. |
| `scripts/ci-failures.ts [run-id] [--pr N] [--list] [-R o/r]` | failing checks → failing jobs/steps → log snippet each; full logs saved to files (paths printed); rg those instead of re-fetching. `--list [--workflow W] [-L n]` shows recent runs with conclusions; use it to find the failing run id instead of `gh run list --json` field sets. |
Rule of thumb: pr-snapshot answers "what's the state of this PR", pr-threads
answers "what did reviewers write". Neither replaces the other.
All scripts: `--json` for structured output, `--help` for usage (includes the
`--json` shape). Omit the PR number to use the current branch's PR. Default
output is sized for context; pass `--full` only when a truncation marker
(`[…+N chars]`) hides something you need. They exit 0 when the report
succeeds even if CI is red or threads are unresolved.
## Gotchas (each one burned real sessions repeatedly)
- Never pipe gh into `head`: SIGPIPE can kill gh mid-write (spurious nonzero
exit, shell-dependent) or silently truncate large output.
Redirect to a file and read that, or trim with `--jq '.[0:20]'`.
- `gh pr diff` has no `--stat` and no positive pathspec (`--name-only` and
`-e/--exclude` globs exist in gh ≥ 2.95). Per-file stats:
`gh api 'repos/{owner}/{repo}/pulls/N/files' --jq '.[]|[.filename,.additions,.deletions]|@tsv'`
Full diff: `gh pr diff N > "$TMPDIR/pr.diff"` once, then rg/sed the file.
- `gh pr checks` exits 1 = failing, 8 = pending by design; append `|| true`, read the table.
- File at any ref, no base64 dance:
`gh api 'repos/{owner}/{repo}/contents/PATH?ref=SHA' -H 'Accept: application/vnd.github.raw'`
- `gh api` fills `{owner}/{repo}` from the cwd repo (`GH_REPO=o/r` overrides).
Quote any api path containing `?` (zsh globs it), or use `-X GET -F per_page=100`
(any `-f`/`-F` silently flips the request to POST without `-X GET`).
- `--paginate` on any list endpoint (`/comments`, `/files`, `/reviews`); `--jq`
already runs per page; don't add `--slurp`.