Run Git operations — commits, branches, merges, rebases, conflict resolution, and recovery — with safety rules enforced.
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
Find why your productivity system keeps failing, then apply the smallest fix — capacity math, bottleneck routing, durable local notes.
Stores durable facts in a categorized, plain-markdown vault on disk, alongside your agent's built-in memory.
Generate and edit Draw.io, Mermaid, and Excalidraw diagrams from natural language using a structured JSON spec.
Join a video meeting as an AI bot with voice, avatar, and screenshare across four operating modes.
Write, debug, and tune Playwright specs with locator strategy, trace diagnosis, and CI-aware timeouts.
More from drumrobot
Browse all skillsRun a 4-stage research → plan → review → TDD-implement workflow for code changes with optional PR capture.
Manage Claude Code sessions: lookup, search, repair, migration, compression, and cleanup in one command surface.
Manage Git worktrees, ghq clones, SourceGit registration, and multi-account credentials with safety checks.
Diagnose agent mistakes, harden the prompt that caused them, and finish the original task.
Convert functionality into Claude Code automations (Agent, Skill, Rule, Hook, Command)
Manage the full lifecycle of Claude Code skills: create, lint, merge, convert, upgrade, and discover them.