Skip to content
Back to skills

Github Pr Workflow

ASecurity

Create branches, commit and push changes, open or update GitHub pull requests, handle CI, and merge safely.

  • 157 stars
  • 0 votes
  • 0 copies
  • 6 views
  • Added May 27, 2026
data-aigobashcode-reviewgit

Works with

  • cli

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add HybridAIOne/hybridclaw --skill github-pr-workflow --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Github Pr Workflow?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Github Pr Workflow
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/hybridaione-github-pr-workflow/badge)](https://www.skillsdirectory.com/skills/hybridaione-github-pr-workflow)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: github-pr-workflow
description: Create branches, commit and push changes, open or update GitHub pull requests, handle CI, and merge safely.
user-invocable: true
metadata:
  hybridclaw:
    category: development
    short_description: "GitHub PR workflow."
    tags:
      - engineering
      - github
      - pull-requests
      - ci
    related_skills:
      - code-review
      - feature-planning
---
# GitHub PR Workflow

Use this skill for the end-to-end pull request loop from branch creation through
merge readiness.

## Default Sequence

0. Verify GitHub CLI authentication if the workflow will use `gh`.
1. Sync the base branch.
2. Create a focused branch for one change.
3. Implement and validate locally.
4. Commit with a clear message.
5. Push and open or update the PR.
6. Check CI and fix failures.
7. Address review feedback.
8. Merge only when the branch is green and approved.

## Core Commands

### Verify GitHub CLI Auth

```bash
gh auth status
```

Run this before any git or PR workflow steps that depend on `gh`. If it fails,
fix authentication first so the workflow does not stop later during `gh pr create`,
`gh pr checks`, or other PR commands.

### Prepare the Branch

```bash
git fetch origin
git checkout main
git pull --ff-only origin main
git checkout -b feat/short-description
```

Use the repository's actual base branch if it is not `main`.

### Commit Clearly

```bash
git status --short
git add path/to/file.ts tests/path/to/file.test.ts
git commit -m "feat: short summary"
```

Keep commits scoped and explain user-visible intent in the subject line.

### Push and Open the PR

```bash
git push -u origin HEAD
gh pr create --fill
```

When `--fill` is not enough, make the body explicit with:

- summary
- test plan
- risks or rollout notes
- linked issue or ticket

Useful variants:

```bash
gh pr create --draft
gh pr create --base main --title "feat: short summary" --body-file /tmp/pr-body.md
gh pr view --web
```

If `gh` is unavailable, complete the local git steps and use the GitHub UI for
PR-specific actions.

## CI and Merge Readiness

Check status after every push:

```bash
gh pr checks
gh pr checks --watch
gh run list --branch "$(git branch --show-current)" --limit 5
gh run view <run-id> --log-failed
```

When a check fails:

1. inspect the failing job or logs
2. reproduce locally if possible
3. fix the smallest confirmed problem
4. rerun targeted validation
5. push again and re-check CI

Do not merge red CI unless the user explicitly accepts that risk.

## Review Feedback Loop

Use the PR conversation as the source of truth:

```bash
gh pr view 123 --comments
gh pr comment 123 --body "Addressed the failing migration path."
gh pr review 123 --comment --body "Applied the requested cleanup."
```

When feedback arrives:

- group related comments into one fix pass when practical
- mention what changed, not just that it is done
- rerun the checks most likely to regress
- keep follow-up commits small and labeled by intent

## Merge Options

Use the repository's preferred merge style:

```bash
gh pr merge 123 --squash
gh pr merge 123 --merge
gh pr merge 123 --rebase
```

Before merging, verify:

- CI is green
- required reviewers approved
- the PR description still matches the implementation
- no unresolved review threads remain if the repo treats them as blockers

## Working Rules

- Prefer small PRs over broad mixed-scope branches.
- Keep the PR body current when scope changes.
- Do not hide risky follow-up work in "later" comments; put it in the PR body or
  linked issue.
- If a change needs multiple dependent PRs, make the stack explicit.
- When CI is noisy or flaky, call that out instead of pretending the branch is
  stable.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.