github-utils

Generate Keep a Changelog (keepachangelog.com/en/1.0.0) formatted release notes for specific git tags/versions and publish them as GitHub release descriptions via `gh`. Use whenever the user asks to write, draft, regenerate, fix, or update a changelog, release notes, or release descriptions for one or more versions or tags — e.g. "update the release notes for v1.2.0", "generate changelogs for the last 3 releases", "the GitHub release descriptions are just raw PR lists, rewrite them properly", "draft changelog entries for 0.4.0 through 0.5.0", or "regenerate all release descriptions in keepachangelog format". Trigger even when the user doesn't say "keepachangelog" or name the format explicitly, as long as they're asking about release notes, descriptions, or changelogs tied to specific versions or git tags.

End-to-end workflow for turning an open GitHub issue into a merged fix: diagnoses the root cause, rewrites the issue into a structured template, branches, implements and verifies the minimal fix, opens a PR, and runs the review loop via pr-review/receive-pr-review. If no issue is named, surveys open issues and picks the single best well-scoped bug itself. Use whenever asked to fix, resolve, or ship a fix for a GitHub issue, or to pick the next bug and fix it — "fix issue #57", "pick up #12 and ship a fix for it", "choose the next issue and fix it" — even without naming this skill. Not for feature requests or open-ended design work that needs exploration first — route those to the project's own planning process instead. Also supports an opt-in autonomous mode for unattended runs ("fix #N autonomously") that skips confirmation checkpoints and escalates instead of asking when it hits an environment problem or a design decision.

Reference guide for the GitHub CLI (`gh`). Use this skill whenever the user asks about GitHub CLI commands, `gh` usage, interacting with GitHub from the terminal, automating GitHub workflows, using the GitHub REST or GraphQL API via `gh api`, managing PRs/issues/releases/runs from the command line, or scripting against GitHub. Trigger even if the user says something like "how do I check CI status", "list open PRs", "create a release from the terminal", "call the GitHub API", or "use gh outside of a repo" — these are all gh-cli tasks. If the user is using the `/pr-review` skill, this skill is a complementary reference for low-level `gh` commands.

Create a new GitHub issue (bug report, feature request, or task) end to end: gathers the issue details, priority, and project assignment from the user, shapes the issue body using the right structure, resolves it against the repo's real issue types/labels and the chosen project's fields, and creates it via `gh` only after the user confirms the draft. Use whenever the user asks to file, open, or create a GitHub issue, report a bug, request a feature, or track a task — e.g. "file a bug for this crash", "open an issue for dark mode support", "create a task for the migration", "create a github issue". For exact `gh` command syntax at every step, this skill defers to the gh-cli skill rather than repeating it.

Full multi-agent review of an open GitHub pull request using the gh CLI: fetches the PR and its diffs, classifies changed files by scope (source code, documentation, CI, security), measures each scope's complexity, spawns scoped reviewer agents, deduplicates their findings, writes a local markdown report, and offers to publish the findings as inline comments on the PR. If a pr-<number>-review.md report already exists for the PR, it re-reviews only the new commits and the developer's responses instead of repeating the full review — use this for "check if PR 19 addressed my feedback" or simply re-running the skill on a PR already reviewed. Use this whenever the user asks to review, assess, or critique a GitHub pull request — a PR URL, a PR number, "review PR 19", "what do you think of this pull request", "look at this PR before I merge" — even if they don't say the word "review". Do not use it for reviewing local uncommitted changes or a local branch diff that has no PR.

Guides a developer through responding to an existing PR review: reads the local pr-<number>-review.md report (written by the pr-review skill) and the PR's GitHub review comments, decides for each open item whether it's valid to fix, needs clarification from the reviewer, or should be declined, applies straightforward fixes directly, and records the decision back into the report so a later pr-review re-review can pick up where this left off. Use this whenever the user wants to act on, respond to, triage, or work through PR review feedback — "go through the PR review comments", "what should I do about this review", "address the findings in pr-19-review.md", "handle the reviewer's feedback" — even if they don't say "receive" or "triage". Requires an existing pr-<number>-review.md; if there isn't one, suggest running pr-review first instead of guessing at findings.

End-to-end workflow for cutting a tagged version release when a CI pipeline builds and publishes the release from the pushed tag: verifies preconditions, decides the version bump, pushes the tag, watches the pipeline, and confirms the Release is actually complete — not just that the run went green — filing an issue instead of leaving a half-published release if it fails. Hands off to the changelog skill for proper release notes on success. Use whenever the user asks to release, cut a release, ship a version, tag a release, bump the version and publish, or "push the release tag" — for any repo whose releases come from a tag-triggered GitHub Actions workflow. Not for hand-built releases with no CI pipeline (use gh-cli's release-mgmt reference directly), or for writing release notes on their own (that's the changelog skill). Defers to gh-cli for exact command syntax, new-issue for the failure issue, and changelog for the notes.