github-cli

GitHub CLI Skill

In one sentence: when the core of the task is "dealing with GitHub", prioritize using gh, rather than limiting the scope to Issues/PRs.

Common scenarios

For resources such as repositories, issues, PRs, comments, releases, workflows, etc., first use gh <group> --help to confirm whether there is an existing subcommand, then execute.
When machine-readable output is needed, prioritize using --json, and if necessary, combine with jq to organize fields.
When the user explicitly requests adjusting the repository merge / squash strategy, refer to squash-merge-policy.md。

PR Review

First look at the PR overview, then pull the review / comment / thread details, to ensure you are not looking at only a single source.
When necessary, you can view the code of the corresponding local branch; before viewing, first git fetch, to ensure the branch is at the latest remote state.
When the user asks to organize PR review comments, arrange them by severity from high to low, numbered, so it is convenient for the user to reply.
Display at most 10 items each time; if there are more, indicate at the end "N items remaining undisplayed".
When the user asks to reply to an inline review comment, prioritize replying directly in the thread, and do not scatter the specific replies into general comments.
For small changes that are already complete, keep the reply short, and prioritize using sentence patterns such as "Added in b771da1ea.” / “Moved in b771da1ea.” / “Adjusted in b771da1ea."; for commit links, prioritize using the [short_sha](full_commit_url) form, rather than the vague [commit]。
Unless it is necessary to explain design trade-offs or explain the reason for not modifying for now, do not repeat the reviewer's original text or write overly long explanations in the inline reply.

Quick view

Repository overview:gh repo view [owner/repo]
Issue overview:gh issue view <id|url>
PR overview:gh pr view <id|url>
Release list:gh release list
Workflow list:gh workflow list

Pre-creation check

Before creating an Issue or PR, first check the corresponding GitHub templates, forms, and current resource status.

Prioritize checking the issue / PR form templates, as well as .github/ISSUE_TEMPLATE/、.github/ISSUE_TEMPLATE.md、.github/PULL_REQUEST_TEMPLATE.md、.github/pull_request_template.md、.github/PULL_REQUEST_TEMPLATE/、.github/config.yml GitHub-specific configurations such as
Issue/PR titles and bodies should be written in accordance with SKILL.md。
Before formally creating, check whether the current code, branch, and commit status are consistent with the content to be submitted to the platform, to avoid creating an Issue or PR that does not match the current state.

Create Issue (non-interactive)

The following specifications are based on the premise that "Pre-creation check" has been completed.

Prepare the title and body first according to SKILL.md .
By default, first write the Issue body to a local Markdown file; prioritize placing the draft in /tmp/*.md; the title is usually short and can be passed directly with --title .
When creating and modifying, prioritize using --body-file, for example:gh issue create --title "..." --body-file /tmp/issue-body.md, or gh issue edit <id> --title "..." --body-file /tmp/issue-body.md。
After successful creation, output the complete Issue URL.

Create PR

The following specifications are based on the premise that "Pre-creation check" has been completed.

First complete the "Pre-creation check".
Only create the PR after confirming that both the repository requirements and the local code/commit status are satisfied; if they are found not to be satisfied, first correct them, then create.
git status must be clean, and the current branch has been pushed to the remote.
Prepare the title and body first according to SKILL.md .
By default, write the PR body to a local Markdown file first; put the draft preferentially in /tmp/*.md, do not assemble multiline strings in the shell, and do not rely on interactive editing. Titles are usually short and can be passed directly with --title .
When creating a PR, preferentially use --body-file, for example:

gh pr create \
  --title "feat(scope): short summary" \
  --body-file /tmp/pr-body.md \
  --base main \
  --draft

When modifying a PR, also reuse the local file to avoid manual editing, for example:gh pr edit <id> --title "..." --body-file /tmp/pr-body.md。
After creation succeeds, output the full PR URL.

Update the Issue/PR title or description (prerequisite)

Before updating the title/description of an Issue or PR, you must first read the current title/body (the content about to be modified), and then make the modification. When updating the title or body, the text is still regenerated according to SKILL.md .

How to look up obscure parameters

gh --help
gh <group> --help
gh <group> <subcommand> --help