agentleFS
Sign inStart free
HybridAIOneHybridAIOne/hybridclaw/skills/github-pr-workflow/SKILL.md

github-pr-workflow

Skill159 starsChanged 6 months agoMITView on GitHub

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

  • Commits and pushes

We split this skill into the rules it gives an agent

22 rules. 0 are common, 18 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 26 edited versions we read keep these.

  • 18

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  • could be automatic: a setting could enforce it
  1. Distinctive:

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

    line 20
  2. Very specific:

    Verify GitHub CLI authentication if the workflow will use gh.

    line 25
  3. Distinctive:

    Create a focused branch for one change.

    line 27
  4. Distinctive:

    Commit with a clear message.

    line 29
  5. Distinctive:

    Check CI and fix failures.

    line 31
  6. Very specific:

    Run this before any git or PR workflow steps that depend on gh.

    line 43
  7. Distinctive:

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

    line 56
  8. Distinctive:

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

    line 66
  9. Very specific:

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

    line 75
  10. Very specific:

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

    line 90
  11. Distinctive:

    Check status after every push:

    line 95
  12. Distinctive:

    When a check fails:

    line 104
  13. Distinctive:

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

    line 112
  14. Distinctive:

    Use the PR conversation as the source of truth:

    line 116
  15. Distinctive:

    keep follow-up commits small and labeled by intent

    line 129
  16. Distinctive:

    Use the repository's preferred merge style:

    line 133
  17. Distinctive:

    no unresolved review threads remain if the repo treats them as blockers

    line 146
  18. Distinctive:

    Prefer small PRs over broad mixed-scope branches.

    line 150
  19. Distinctive:

    Keep the PR body current when scope changes.

    line 151
  20. Distinctive:

    Do not hide risky follow-up work in "later" comments.

    line 152
  21. Distinctive:

    If a change needs multiple dependent PRs, make the stack explicit.

    line 154
  22. Distinctive:

    When CI is noisy or flaky, call that out instead of pretending the branch is stable.

    line 155

“Common” is measured: kept by at least 6 in 10 of the 26 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

GitHub PR Workflow

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

Default Sequence

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

Core Commands

Verify GitHub CLI Auth

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

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

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

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:

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:

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:

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:

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

Reviews can't be read right now.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free