How do I install the Gh CLI skill?

Run npx skillmds@latest add lil-lon/gh-cli in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Gh CLI safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Gh CLI?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Gh CLI free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Gh CLI?

lil-lon (@lil-lon) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Gh CLI by lil-lon — Agent Skill

Name: Gh CLI
Author: lil-lon

Gh CLI

Use the GitHub CLI (`gh`) to fetch information from GitHub: issues, PRs, comments, reviews, workflow runs, repos, and search. A curated set of read-only `gh` subcommands and read-only `gh api` endpoints are pre-approved and run without prompts. The sandbox lets `gh *` reach the network unsandboxed. Write operations (anything that changes state on GitHub) are NOT pre-approved and MUST NOT be executed unless the user explicitly asks for that write. Even when explicitly requested, run the natural command and let the harness's approval prompt fire — NEVER reshape the command to evade pattern matching. Use this skill whenever you need information from GitHub. Proactively invoke it (do NOT answer from memory or prior conversation) when the user references a GitHub issue, PR, review, comment, action run, or repo, or asks things like "show me the comments", "what's in PR #N", "what did the reviewer say".

lil-lon 8696a6e 4.6 KB Updated Sep 17, 2026

File contents

Read-only commands (pre-approved, run freely)

gh issue list ... — list issues with filters (state, label, author, assignee, search)
gh issue view <n> (incl. --comments) — one issue's body and metadata; --comments adds the conversation
gh pr list ... — list PRs with filters (state, label, author, base, head)
gh pr view <n> (incl. --comments) — one PR's body and metadata; --comments adds issue comments + review summaries (NOT inline review comments — see gh api below)
gh pr diff <n> — show the diff of a PR
gh pr checks <n> — CI / check status of a PR
gh repo view [owner/repo] — repo metadata (description, default branch, README)
gh run list ... — list workflow runs (CI history)
gh run view <id> (incl. --log) — one run's status; --log adds the full log
gh search <type> ... — search across GitHub: issues, prs, code, commits, repos

Read-only `gh api` endpoints (pre-approved, exact form only)

gh pr view --comments shows issue comments and review summaries but NOT inline (line-level) review comments. For those, use gh api. The following three GET endpoints are pre-approved:

gh api repos/<owner>/<repo>/issues/<n>/comments — issue/PR conversation comments
gh api repos/<owner>/<repo>/pulls/<n>/comments — inline review comments on code lines
gh api repos/<owner>/<repo>/pulls/<n>/reviews — review summaries

The patterns are deliberately exact (no trailing *). Any extra flag or query string — --paginate, ?per_page=100, -q, --jq, etc. — falls through to an approval prompt. Do NOT widen, split, or otherwise reshape the call to slip past this; if the bare form is not enough, accept the prompt.

Write operations

A write operation is any gh invocation that changes state on GitHub. Writes are NOT pre-approved — every write surfaces an approval prompt.

In scope: writes you may run when the user explicitly asks

When the user explicitly requests one of these, construct the natural command and run it. The harness will prompt for approval; that prompt is the user's confirmation.

gh pr <subcommand> — typical writes: create, close, reopen, comment, edit, merge, review, ready
gh issue <subcommand> — typical writes: create, close, reopen, comment, edit

Out of scope

Any other write — gh repo writes, gh release ..., gh run cancel / delete / rerun, gh secret ..., gh workflow ..., gh api with -X POST | PATCH | DELETE | PUT or --method ..., etc. — has no current use case. Do not execute these.

Rules

Never execute a write unless the user explicitly asks for that write. Phrases like "add a comment", "comment on the PR", "merge it", "close this issue" are explicit. Inferring writes from context ("ship this", "let them know") is NOT explicit — ask first.
When the user does ask (in-scope writes), run the natural command. Example: gh pr comment 123 --body "...". The command is not in the allow-list, so the harness surfaces an approval prompt. That prompt is the user's confirmation. Do not try to skip it.
Never reshape a write to evade pattern matching. Prohibited:
- Hiding the body via --body-file -, here-docs, or stdin pipes to disguise the visible command shape.
- Splitting one API call into several to slip under allow-list rules.
- Using a different channel (web URL, git push of a PR-creating commit, etc.) to achieve the same write without going through the prompt.
If a write requires approval, let it require approval.
If unsure whether a command writes, treat it as a write.

---name: gh-clidescription: Use the GitHub CLI (`gh`) to fetch information from GitHub: issues, PRs, comments, reviews, workflow runs, repos, and search. A curated set of read-only `gh` subcommands and read-only `gh api` endpoints are pre-approved and run without prompts. The sandbox lets `gh *` reach the network unsandboxed. Write operations (anything that changes state on GitHub) are NOT pre-approved and MUST NOT be executed unless the user explicitly asks for that write. Even when explicitly requested, run the natural command and let the harness's approval prompt fire — NEVER reshape the command to evade pattern matching. Use this skill whenever you need information from GitHub. Proactively invoke it (do NOT answer from memory or prior conversation) when the user references a GitHub issue, PR, review, comment, action run, or repo, or asks things like "show me the comments", "what's in PR #N", "what did the reviewer say".---## Read-only commands (pre-approved, run freely)- `gh issue list ...` — list issues with filters (state, label, author, assignee, search)- `gh issue view <n>` (incl. `--comments`) — one issue's body and metadata; `--comments` adds the conversation- `gh pr list ...` — list PRs with filters (state, label, author, base, head)- `gh pr view <n>` (incl. `--comments`) — one PR's body and metadata; `--comments` adds issue comments + review summaries (NOT inline review comments — see `gh api` below)- `gh pr diff <n>` — show the diff of a PR- `gh pr checks <n>` — CI / check status of a PR- `gh repo view [owner/repo]` — repo metadata (description, default branch, README)- `gh run list ...` — list workflow runs (CI history)- `gh run view <id>` (incl. `--log`) — one run's status; `--log` adds the full log- `gh search <type> ...` — search across GitHub: `issues`, `prs`, `code`, `commits`, `repos`## Read-only `gh api` endpoints (pre-approved, exact form only)`gh pr view --comments` shows issue comments and review summaries butNOT inline (line-level) review comments. For those, use `gh api`. Thefollowing three GET endpoints are pre-approved:- `gh api repos/<owner>/<repo>/issues/<n>/comments` — issue/PR conversation comments- `gh api repos/<owner>/<repo>/pulls/<n>/comments` — inline review comments on code lines- `gh api repos/<owner>/<repo>/pulls/<n>/reviews` — review summariesThe patterns are deliberately exact (no trailing `*`). Any extra flagor query string — `--paginate`, `?per_page=100`, `-q`, `--jq`, etc. —falls through to an approval prompt. Do NOT widen, split, or otherwisereshape the call to slip past this; if the bare form is not enough,accept the prompt.## Write operationsA write operation is any `gh` invocation that changes state on GitHub.Writes are NOT pre-approved — every write surfaces an approval prompt.### In scope: writes you may run when the user explicitly asksWhen the user explicitly requests one of these, construct the naturalcommand and run it. The harness will prompt for approval; that promptis the user's confirmation.- `gh pr <subcommand>` — typical writes: `create`, `close`, `reopen`, `comment`, `edit`, `merge`, `review`, `ready`- `gh issue <subcommand>` — typical writes: `create`, `close`, `reopen`, `comment`, `edit`### Out of scopeAny other write — `gh repo` writes, `gh release ...`, `gh run cancel /delete / rerun`, `gh secret ...`, `gh workflow ...`, `gh api` with`-X POST | PATCH | DELETE | PUT` or `--method ...`, etc. — has nocurrent use case. Do not execute these.### Rules1. **Never execute a write unless the user explicitly asks for that write.** Phrases like "add a comment", "comment on the PR", "merge it", "close this issue" are explicit. Inferring writes from context ("ship this", "let them know") is NOT explicit — ask first.2. **When the user does ask (in-scope writes), run the natural command.** Example: `gh pr comment 123 --body "..."`. The command is not in the allow-list, so the harness surfaces an approval prompt. **That prompt is the user's confirmation. Do not try to skip it.**3. **Never reshape a write to evade pattern matching.** Prohibited: - Hiding the body via `--body-file -`, here-docs, or stdin pipes to disguise the visible command shape. - Splitting one API call into several to slip under allow-list rules. - Using a different channel (web URL, `git push` of a PR-creating commit, etc.) to achieve the same write without going through the prompt. If a write requires approval, let it require approval.4. If unsure whether a command writes, treat it as a write.

Frequently asked questions