$npx -y skills add PaulRBerg/agent-skills --skill cli-ghUse for GitHub CLI automation: repository reads, workflow runs, search, codespaces, releases, configuration, or gh command syntax. Use yeet for contribution writes to PRs, issues, comments, or discussions.
| 1 | # GitHub CLI |
| 2 | |
| 3 | Route GitHub CLI work through current `gh` help and load only the reference for the active task. |
| 4 | |
| 5 | ## Boundary with `yeet` |
| 6 | |
| 7 | Use `yeet` when the requested outcome is to create or update a pull request, issue, issue comment, or discussion. `yeet` |
| 8 | owns semantic analysis, repository templates, Paul's writing voice, idempotency, and direct posting. Use this skill for |
| 9 | read-only GitHub inspection, command syntax, searches, workflow operations, codespaces, releases, configuration, and |
| 10 | other GitHub automation. |
| 11 | |
| 12 | ## Authority |
| 13 | |
| 14 | - Read and inspect without confirmation. |
| 15 | - Execute reversible or ordinary GitHub writes only when the user explicitly requested that outcome. |
| 16 | - Never delete repositories, releases/assets, workflow runs/caches, secrets/variables, keys, codespaces, extensions, or |
| 17 | gists. |
| 18 | - Label deletion is the sole destructive exception: show the target repo, exact labels, commands, and issue/PR impact, |
| 19 | then require approval in a subsequent message before `gh label delete ... --yes`. |
| 20 | - Route repository renames through `repo-rename` so GitHub and local continuity change together. |
| 21 | |
| 22 | ## Workflow |
| 23 | |
| 24 | 1. Resolve the repository explicitly when cwd is ambiguous. Let the first required read-only command validate |
| 25 | authentication; run `gh auth status` only for auth diagnosis. |
| 26 | |
| 27 | 2. Inspect `gh <command> <subcommand> --help` for the installed version before relying on flags or JSON fields. Prefer |
| 28 | `--json` plus `--jq` for machine-readable results. |
| 29 | |
| 30 | 3. Load only the relevant reference: |
| 31 | |
| 32 | | Task | Reference | |
| 33 | | --------------------------------------------------------- | ------------------------------------ | |
| 34 | | Workflow runs, checks, logs | `references/workflows-actions.md` | |
| 35 | | Releases | `references/releases.md` | |
| 36 | | Search | `references/search.md` | |
| 37 | | JSON fields and jq | `references/json-output.md` | |
| 38 | | Labels | `references/labels.md` | |
| 39 | | Codespaces | `references/codespaces.md` | |
| 40 | | Discussions syntax (not authored contribution workflow) | `references/discussions.md` | |
| 41 | | Gists | `references/gists.md` | |
| 42 | | Aliases, API, extensions, org/projects, secrets, rulesets | `references/advanced-features.md` | |
| 43 | | Reusable automation patterns | `references/automation-workflows.md` | |
| 44 | | Failures and auth/rate limits | `references/troubleshooting.md` | |
| 45 | |
| 46 | 4. Preview commands that have broad write scope. After a requested write, fetch the resulting resource and report its |
| 47 | URL or stable identifier. |
| 48 | |
| 49 | Completion requires the requested GitHub state or data plus command/output evidence. On a partial or ambiguous write |
| 50 | failure, check whether the resource changed before retrying. |
| 51 | |
| 52 | ## User-Facing Output |
| 53 | |
| 54 | Use `### ⚠️ GitHub write preview` for broad writes, showing the repository, exact targets, and issue/PR impact in a |
| 55 | compact table, with each exact command in its own fenced block; an already requested ordinary write does not require a |
| 56 | second approval. For label deletion, use `### ⛔ Destructive approval required` and ask for approval in a later message. |
| 57 | After a verified write, use `### ✅ GitHub operation complete` with the action, repository, resource, and URL or stable |
| 58 | ID. On failure, state the attempted operation, verified resulting state, concrete error, and next action without |
| 59 | implying a write succeeded. Keep commands, JSON, identifiers, diagnostics, and output intended for piping undecorated. |