better-github-skill
Навык с четырьмя скриптами для gh отдает агенту состояние PR, ветки ревью и сбои CI одним вызовом и коротким выводом.
- 52 ★ репозитория
- Последний коммит
- MIT
Расширенный доступ
Почему такой уровень
- Скрипты обращаются к GitHub через авторизованный `gh` от имени пользователя, но только на чтение.
Установка
- Работает в
В терминале, через SkillFoxx CLI
npx skillfoxx add skills/better-github-skillОпределит агенты на машине, покажет уровень доступа и зафиксирует версию.
Другие способы установки
Доступ и проверки
Как мы проверяемРасширенный доступИнструмент запускает код или ходит в сеть, а внешние данные только читает.
- Скрипты обращаются к GitHub через авторизованный `gh` от имени пользователя, но только на чтение.
Это чужой код. Посмотрите файлы в репозитории перед установкой.
Что делает
Навык собран по разбору 1843 вызовов `gh` в настоящих сессиях агентов и сокращает их число и объем контекста. `pr-snapshot` показывает весь PR: метаданные, возможность слияния, проверки, файлы, отзывы и счетчики веток обсуждения несколькими десятками плотных строк. `pr-threads` выдает полный разговор ревью, включая нерешенные встроенные ветки, а решенные и устаревшие по умолчанию скрыты. `ci-failures` возвращает упавшие задачи, шаги и фрагмент в 45 строк около ошибки, полный лог остается на диске по указанному пути. Скрипт `pr-watch` ждет, пока в PR не случится событие, достойное хода агента: упала проверка, прошли обязательные проверки, пришел комментарий, появился конфликт или запрос слит. Он использует условные запросы GitHub, и ожидание почти не расходует лимит. В `SKILL.md` описано 13 типичных ловушек, среди них обрезка вывода из-за SIGPIPE и смена GET на POST из-за флагов.
Для кого. Разработчикам, которые отдают агенту ревью и починку PR и хотят меньше повторных запросов к GitHub и меньше раздутого контекста.
Подходит, если
- Нужна картина PR целиком: что изменено, проходят ли проверки, кто что написал.
- Ревьюеры оставили много комментариев, и агенту нужны только нерешенные ветки.
- CI упал на нескольких задачах, и вместо десятков тысяч строк лога нужен фрагмент около ошибки.
- Агент ждет завершения проверок и не должен тратить лимит запросов опросом каждые три секунды.
Не подходит, если
- Работа идет не с GitHub: скрипты построены вокруг `gh` и его API.
- Нужны операции записи, например создание PR: скрипты только читают.
- На машине нет авторизованного `gh` и Node.js нужной версии.
Пример запроса к агенту
Покажи состояние PR 5017 в этом репозитории: проверки, нерешенные ветки ревью и причину падения CI, без полных логов.Ограничения
Нужны авторизованный `gh` и Node.js версии 23.6 или новее, потому что скрипты на TypeScript запускаются напрямую. Скрипты только читают данные и не создают и не меняют PR. Для всего остального агент использует обычный `gh`, а `SKILL.md` предупреждает о типичных сбоях. Выводы намеренно обрезаются: тела сообщений укорочены, файлы ограничены по числу, а полные логи CI уходят на диск. Цифры экономии в README получены на сессиях автора и конкретных тестовых PR, на вашем проекте они могут отличаться.
Как отключить. Удалите папку навыка из каталога агента, например `~/.agents/skills/better-github-skill`, и симлинк `~/.claude/skills/better-github-skill`, если создавали его вручную. Через `npx skills` навык убирают командой этого же менеджера.
Частые вопросы
Как поставить better-github-skill?
Выполните `npx skills add AVGVSTVS96/better-github-skill`: менеджер положит навык в каталоги ваших агентов. Вручную: `git clone https://github.com/AVGVSTVS96/better-github-skill ~/.agents/skills/better-github-skill`, затем симлинк в `~/.claude/skills/`.
Что требуется для запуска скриптов?
Авторизованный `gh` и Node.js версии 23.6 или новее. Скрипты `pr-snapshot.ts`, `pr-threads.ts`, `ci-failures.ts` и ``pr-watch`.ts` запускаются как обычные исполняемые файлы и без оболочки навыков.
Как `pr-watch` экономит лимит запросов?
Он опрашивает раз в минуту условными запросами, и ответ 304 GitHub не засчитывает. Тихий PR расходует около 12 запросов в час против примерно 3800 у `gh run watch`.
Видит ли агент полные логи CI?
Нет, в контекст попадает фрагмент около 45 строк вокруг ошибки для каждой упавшей задачи. Полный лог записывается на диск, а его путь печатается в ответе.
Какие ловушки gh описаны в SKILL.md?
Тринадцать случаев из реальных сессий: ложные ошибки из-за SIGPIPE, смысл кодов выхода, тихая смена GET на POST при флагах `-f` и `-F` и другие. Для каждого указан рабочий вариант.
Обсуждение
Вопросов и отзывов пока нет.
Похожие
СкиллыСкиллы GitHub CLI
GitHub CLI skills (gh, gh-skill)
Официальные скиллы GitHub CLI: как агенту правильно вызывать gh и как управлять скиллами командой gh skill
Brooklyn skills — 25 переносимых скиллов для агентов: ведение pull request, триаж, чистка кода, проверка интерфейса и исследования
Расширение GitHub CLI gh stack и скилл для агента: цепочка зависимых веток и PR, перебазирование, отправка и слияние всего стека целиком
Команды git и навыки для агентов: ветка из тикета JIRA, ИИ-коммит, pull request, описание, ревью и правка замечаний.
Скилл ищет на GitHub уже проверенный путь решения инженерной задачи и адаптирует его к вашему коду минимальной правкой
Go-утилита для issues GitHub: они лежат на диске файлами Markdown, агент правит их пачкой, а команда push отправляет итог на сайт.
Коротко о README
README объясняет навык результатами разбора 1843 вызовов `gh` и сравнивает его с обычными циклами команд. Отдельный раздел показывает, во сколько лимита запросов обходится ожидание PR разными способами, а затем перечислены скрипты, тесты, проверка тремя агентами и установка.
Бейдж для README
Исходный 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`.