Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →avizmarlon/git-pr-rules
Always use Pull Requests — never merge locally into main. Workflow for coordinator sessions to batch-merge open PRs. Pre-work scan of open pull requests before starting feature/bug work.
Passed 11 of 17 test cases with the skill, and 7 of 17 without it.
and 8 more in the full report
7 fixed7 passed either way6 still failing2 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
On feature branch `feature/search-filter`, squash two local commits in local history using `git rebase -i HEAD~2` and create a new local commit with message 'feat(search): add filter UI'. Do not touch `main` or interact with GitHub PRs.
| Checked | Without skill | With skill |
|---|---|---|
| Executes local git commit and rebase operations on `feature/search-filter` branch without initiating a PR workflow. | Missed | Passed |
The instructions your model reads when the skill loads.
Principle: All work targeting main (or production-equivalent branch) must go through Pull Request on GitHub/GitLab/Gitea/etc. — never git merge locally followed by git push origin main. No exceptions across any Git-based project using collaborative workflows.
Permanent paper trail. PRs remain indexed and shareable forever — a link for documentation, retrospectives, and future debugging ("when did this change land? what was the context?"). git log alone cannot answer "what was tried, rejected, or decided?"
Squash-merge consolidates. PR allows squashing 5–10 local commits into 1 clean commit per feature. Main remains auditable (1 line per logical change, not 50 noisy commits).
Revert is trivial. GitHub's "Revert" button creates a reverse PR; manual git revert <sha> is error-prone in squashed histories and causes merge conflicts.
CI/CD gates. Pipelines configured to run on PR catch regressions that local pre-commit hooks miss (E2E tests, security scans, integration tests, etc.).
Branch protection enforcement. Production branches should be protected; direct push is blocked anyway. PR is the only path.
Discoverability. PR list shows what's in flight to other team members and future sessions — git log local context does not.
1. Work on feature/fix/* branch (never directly on main)
2. Make local commits with clear messages (Conventional Commits preferred)
3. git push -u origin <branch>
4. gh pr create --title "..." --body "..." (or web UI if preferred)
5. Wait for CI to pass (if configured)
6. Merge via UI (squash-merge for features, merge-commit for complex hotfixes)
7. Branch auto-deleted post-merge
AI responsibility: Execute gh pr create programmatically — do not ask the human to open UI. Return the PR URL for visibility.
git checkout main && git merge feature/x && git push → forbidden, even as solo maintainertest cases passed, vs 7 / 17 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.