github-cli

Name: github-cli
Author: sordi-ai

17stars3forks

How to install github-cli?

sordi-ai/skill-everything/github-cli

$npx -y skills add sordi-ai/skill-everything --skill github-cli

Installs into the current project.

Summary

Apply when using the gh CLI to manage pull requests, issues, releases, or CI workflows on GitHub.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: GitHub CLI (`gh`) Conventions
2
3	Purpose: Consistent, auditable use of the `gh` CLI for PRs, issues, releases, and CI — preventing gate bypasses and silent failures.
4
5	---
6
7	## Rules
8
9	### Authentication & Scopes
10
11	1. Check auth scope before scripting. Before running `gh` in CI or scripts, always verify the required scopes are granted with `gh auth status`; missing scopes produce silent 404s rather than auth errors.
12	2. Use token env var in CI. Always pass `GH_TOKEN` (or `GITHUB_TOKEN`) via environment variable in CI pipelines; never hard-code tokens or use `gh auth login --with-token` interactively in automated contexts.
13
14	### Pull Requests
15
16	3. Include all required labels on PR creation. Always pass `--label` for every gate-required label when running `gh pr create`; omitting a label silently bypasses automated approval gates. Reference: ERR-2026-023
17	4. Set reviewer on creation. Always use `--reviewer <handle>` when creating PRs that require CODEOWNERS approval; adding reviewers after creation delays the review clock.
18	5. Open as draft when work is incomplete. Use `gh pr create --draft` for PRs not yet ready for review; never open a ready-for-review PR on a branch with failing CI.
19	6. Link issues explicitly. Always include `--body "Closes #<issue>"` or `--body "Fixes #<issue>"` so GitHub auto-closes the linked issue on merge; never rely on branch name alone for issue linkage.
20
21	### Issues
22
23	7. Assign and label on creation. Use `gh issue create --assignee @me --label <label>` rather than creating bare issues and editing them in a second step; unassigned, unlabelled issues fall out of triage queues.
24	8. Use JSON output for scripting. Prefer `gh issue list --json number,title,labels` over parsing human-readable output; the `--json` flag is stable across `gh` versions, plain text is not.
25
26	### CI / Workflows
27
28	9. Trigger runs explicitly when needed. Use `gh workflow run <workflow.yml> --ref <branch>` to trigger a workflow rather than pushing an empty commit; empty commits pollute history.
29	10. Watch run status in scripts. After triggering a workflow, use `gh run watch <run-id>` or poll `gh run view <run-id> --json conclusion` rather than sleeping for a fixed duration.
30
31	### Releases & API
32
33	11. Create releases from tags, not branches. Always run `gh release create <tag> --generate-notes` after pushing the tag; never target a branch directly, as branch-based releases produce non-reproducible artifacts.
34	12. Use `gh api` for endpoints not covered by subcommands. Prefer `gh api repos/{owner}/{repo}/pulls --jq '.[].number'` over raw `curl` with manual auth headers; `gh api` inherits the active auth context automatically.
35	13. Define aliases for repeated commands. Use `gh alias set` to capture long flag combinations used more than twice in a project; aliases are stored in `~/.config/gh/config.yml` and are portable across machines via dotfiles.
36
37	---
38
39	## See also
40
41	- `skills/git-conventions/SKILL.md`
42	- `skills/error-log/SKILL.md`

People who liked this also viewed

6 picks

Type

caveman-commitUltra-compressed commit message generator. Cuts noise from commit messages while preserving intent and reasoning. Conventional Commits format. Subject ≤50 chars, body only when "why" isn't obvious. UsSkillsJul 2026259k92k
git-guardrails-claude-codeSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026157k181k
setup-pre-commitSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026152k181k
resolving-merge-conflictsSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026146k181k
using-git-worktreesUse when starting feature work that needs isolation from current workspace or before executing implementation plans - ensures an isolated workspace exists via native tools or git worktree fallbackSkillsJul 2026143k259k
finishing-a-development-branchUse when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanupSkillsJul 2026140k259k

github-cli

17stars3forks

View on GitHub

How to install github-cli?

sordi-ai/skill-everything/github-cli

$npx -y skills add sordi-ai/skill-everything --skill github-cli

Installs into the current project.

Summary

Apply when using the gh CLI to manage pull requests, issues, releases, or CI workflows on GitHub.

Files · 1

View on GitHub

SKILL.md

1	# Sub-Skill: GitHub CLI (`gh`) Conventions
2
3	Purpose: Consistent, auditable use of the `gh` CLI for PRs, issues, releases, and CI — preventing gate bypasses and silent failures.
4
5	---
6
7	## Rules
8
9	### Authentication & Scopes
10
11	1. Check auth scope before scripting. Before running `gh` in CI or scripts, always verify the required scopes are granted with `gh auth status`; missing scopes produce silent 404s rather than auth errors.
12	2. Use token env var in CI. Always pass `GH_TOKEN` (or `GITHUB_TOKEN`) via environment variable in CI pipelines; never hard-code tokens or use `gh auth login --with-token` interactively in automated contexts.
13
14	### Pull Requests
15
16	3. Include all required labels on PR creation. Always pass `--label` for every gate-required label when running `gh pr create`; omitting a label silently bypasses automated approval gates. Reference: ERR-2026-023
17	4. Set reviewer on creation. Always use `--reviewer <handle>` when creating PRs that require CODEOWNERS approval; adding reviewers after creation delays the review clock.
18	5. Open as draft when work is incomplete. Use `gh pr create --draft` for PRs not yet ready for review; never open a ready-for-review PR on a branch with failing CI.
19	6. Link issues explicitly. Always include `--body "Closes #<issue>"` or `--body "Fixes #<issue>"` so GitHub auto-closes the linked issue on merge; never rely on branch name alone for issue linkage.
20
21	### Issues
22
23	7. Assign and label on creation. Use `gh issue create --assignee @me --label <label>` rather than creating bare issues and editing them in a second step; unassigned, unlabelled issues fall out of triage queues.
24	8. Use JSON output for scripting. Prefer `gh issue list --json number,title,labels` over parsing human-readable output; the `--json` flag is stable across `gh` versions, plain text is not.
25
26	### CI / Workflows
27
28	9. Trigger runs explicitly when needed. Use `gh workflow run <workflow.yml> --ref <branch>` to trigger a workflow rather than pushing an empty commit; empty commits pollute history.
29	10. Watch run status in scripts. After triggering a workflow, use `gh run watch <run-id>` or poll `gh run view <run-id> --json conclusion` rather than sleeping for a fixed duration.
30
31	### Releases & API
32
33	11. Create releases from tags, not branches. Always run `gh release create <tag> --generate-notes` after pushing the tag; never target a branch directly, as branch-based releases produce non-reproducible artifacts.
34	12. Use `gh api` for endpoints not covered by subcommands. Prefer `gh api repos/{owner}/{repo}/pulls --jq '.[].number'` over raw `curl` with manual auth headers; `gh api` inherits the active auth context automatically.
35	13. Define aliases for repeated commands. Use `gh alias set` to capture long flag combinations used more than twice in a project; aliases are stored in `~/.config/gh/config.yml` and are portable across machines via dotfiles.
36
37	---
38
39	## See also
40
41	- `skills/git-conventions/SKILL.md`
42	- `skills/error-log/SKILL.md`

People who liked this also viewed

6 picks

Type