Interact with GitHub using the `gh` CLI. Use `gh issue`, `gh pr`, `gh run`, and `gh api` for issues, PRs, CI runs, and advanced queries.
4 installs
Data & analysis
github-flow
Try itConvert plans and code changes into GitHub issues and PRs, with auth handling, dependency tracking, and pre-publish scans.
What it does
Drives the GitHub issue and pull-request workflow for repositories hosted on github.com. Sixteen sub-topics cover converting a Markdown plan into an issue body, registering an issue after duplicate checks, managing native Issue Relationships (blocked-by/blocking) via GraphQL, creating a PR with a test plan, running structured code reviews, bundling deferred findings into an Epic issue, and a HARD STOP scan for personal data before posting to PUBLIC repos. Every issue/PR body must include a verification plan, and internal working paths such as `.ralph/` or `.omc/` are blocked from publication.
When to use it
- Convert a research Markdown into a tracked GitHub issue
- Create a draft PR, watch CI, then ready it for review
- Link issues with blocked-by / blocking relationships before merge
- Bundle cross-PR deferred feedback into a single Epic issue
The skill document
GitHub Flow
Convert plans, research, and implementation results into GitHub issues and PRs.
Topics
| Topic | Description | Guide |
|---|---|---|
| auth-scope | gh CLI priority + account mapping + batch scope refresh + org-repo 404 checklist | auth-scope.md |
| commit-message-discipline | Commit message authoring, message update on amend, PUBLIC repo English enforcement, git operation type continuity, verb selection (.md as source code) | commit-message-discipline.md |
| dependencies | Manage native Issue Relationships (blocked-by/blocking) via addBlockedBy/removeBlockedBy GraphQL mutations | dependencies.md |
| epic-bundle | Bundle deferred review findings across multiple PRs into one Epic tracking issue (checklist + native sub-issues + epic label) | epic-bundle.md |
| expand | Decide expand-vs-split when new findings emerge mid-work and update title/body | expand.md |
| identity-auth | Owner-based gh account mapping for commit author identity + gh auth scope refresh + GH_TOKEN env fallback for org repo 404 | identity-auth.md |
| merge | CI success and AI review check then merge with commit cleanup, including pre-merge blockedBy verification | merge.md |
| plan-to-issue | Convert plan/research MD to GitHub issue body or comments | plan-to-issue.md |
| pr | Create PR with structured body, test plan, and optional visual attachments. Multi-PR references in an AskUserQuestion payload are enforced by resources/block-pr-url-gate.sh (PreToolUse:AskUserQuestion, registered in settings.json) — every distinct PR number needs its own clickable URL | pr.md |
| publish | Package a working-tree change into its own branch + draft PR against a staging-base branch, watch CI, ready-transition, content-review ask, merge — the full repeated sequence in one topic | publish.md |
| push-guards | Branch-change ask + push rejection ask + force-push CI status check + main/master push restriction + shared-branch direct-push restriction | push-guards.md |
| register | Evaluate duplicates and decide registration strategy (new issue vs comment vs sub-issue) | register.md |
| review | Review PR code and post structured review comments | review.md |
| review-apply | Apply deferred [REVIEW_FEEDBACK] items from fix_plan to code, update PR Summary | review-apply.md |
| sanitize | HARD STOP scan for personal data before posting to PUBLIC repos | sanitize.md |
| upstream-issue | Register feature requests/bug reports on external open-source repos with duplicate check + draft + sanitize | upstream-issue.md |
Topic Dependencies
github-flow (issue/PR workflow)
├─→ plan-to-issue (issue body content)
├─→ epic-bundle (deferred findings across PRs → one Epic issue)
│ ├─→ uses plan-to-issue (Epic body) + register (dup check) + dependencies (sub-issues)
│ └─→ receives from: consolidate next step (auto-suggest when deferred findings accumulate)
├─→ register (evaluate duplicates and decide strategy)
├─→ pr (PR body content + visual attachments)
├─→ review (post structured review comments)
├─→ expand (mid-work scope expansion)
├─→ dependencies (Issue Relationships: blocked-by/blocking)
│ └─→ used by merge step 5 (pre-merge blockedBy check)
├─→ merge (CI/Review/Test Plan/blockedBy verification → squash+merge)
├─→ review-apply (deferred [REVIEW_FEEDBACK] → code fix → Summary update)
│ └─→ receives from: consolidate Step 7 (deferred registration)
├─→ sanitize (HARD STOP scan before posting to PUBLIC repos)
└─→ upstream-issue (external repo feature request/bug report with duplicate check + draft + sanitize)
- dependencies → merge: dependencies adds blockedBy relationships. merge.md step 5 queries the same field to gate merge until predecessors are CLOSED
- plan-to-issue → dependencies: when a plan has frontmatter
chain:declaring a sequential issue order, dependencies applies it to GitHub - All topics → sanitize: any text published to PUBLIC repos (issue body, PR body, comments, review text) must pass sanitize HARD STOP first
Applicability
This skill applies automatically when git remote get-url origin contains github.com. For non-GitHub remotes (GitLab, Bitbucket, etc.), this skill does not apply.
Core Rules
1. Verification Plan Required
Every issue body and PR body must include a verification/test plan section. This is shared with code-workflow's plan step.
2. No Internal Paths in Issues/PRs
.ralph/docs/, .ralph/fix_plan.md, .omc/ and other internal working paths must never appear in GitHub issue body, comments, or PR body. These are local-only artifacts.
Instead of: "See .ralph/docs/generated/plan-180.md"
Write: The actual content inline, or "See the implementation plan comment below"
3. Body vs Comment Selection
| Content Type | Target | Reason |
|---|---|---|
| Implementation plan (confirmed) | Issue body update | Stable reference for the issue |
| Checklist (impl/verify) | Issue body update | Trackable via GitHub checkbox |
| Discussion items / open questions | Issue comment | Threaded, time-stamped, doesn't clutter body |
| Progress updates | Issue comment | Chronological record |
| Review feedback summary | Issue comment | Preserves review history |
Questions people ask
- Does this apply to GitLab or Bitbucket?
- No. The skill activates only when `git remote get-url origin` contains github.com; non-GitHub remotes are out of scope.
- What belongs in the issue body versus a comment?
- Confirmed implementation plans and checklists go in the body for stable reference and checkbox tracking; open questions, progress updates, and review summaries go in comments to preserve a chronological, threaded record.
- How is merge decided?
- The merge topic verifies CI success, an AI review pass, the verification plan, and that no `blocked-by` issues remain open, then proceeds to a squash merge.
Related skills
Run a 4-stage research → plan → review → TDD-implement workflow for code changes with optional PR capture.
24 installs
Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, dra...
7 installs
GitHub repository configuration and verification. Topics — actions (GitHub Actions workflow generation + Dependabot grouping by dependency type), setup (integrations: CodeRabbit, Copilot, issue/PR templates, CODEOWNERS, branch protection), verify (repo prerequisites checklist for github-flow: remote, default branch, PR template, branch protection, GitHub Actions, CONTRIBUTING, LICENSE). Use when: "github actions", "workflow generation", "CI workflow", "dependabot", "dependabot groups", "coderabbit", "copilot setup", "GitHub Actions", "repo setup", "CODEOWNERS", "PR template", "issue template", "branch protection", "repo verify".
Interact with GitHub via the gh CLI — issues, PRs, CI runs and repository health with auto-changelog and issue triage.
2 installs
Help address review/issue comments on the open GitHub PR for the current branch using gh CLI; verify gh auth first and prompt the user to authenticate if not...
6 installs