htnabehtnabe/skills/git-commit-push-pr/SKILL.md

git-commit-push-pr

Skill0 starsChanged 2 months agoMITView on GitHub

Create commits with conventional commits and gitemoji, push when permission is granted, and create pull requests with gh using a PR template. Use when finishing changes and preparing review-ready delivery.

Commits and pushes

1 other project uses a version of this.

Adopted by

Most recently taken up by

devoxx/DevoxxGenieIDEAPlugintheir own version, first seen Oct 8, 2026

Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 1
devoxx/DevoxxGenieIDEAPlugin★ 689same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository3 other files it gives its agents.
- adversarial-reviewSkill
- doc-maintenanceSkill
- feature-implementationSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

30 rules. About 0 are common, 29 are distinctive, and 1 is very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈29
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Distinctive:
Create high-quality commits at meaningful granularity.
line 13
Distinctive:
Create a pull request with gh and return only the review URL.
line 15
Distinctive:
Keep status summaries concise.
line 16
Distinctive:
Use conventional commits with gitemoji.
line 26
Distinctive:
Keep one commit per logical change when possible.
line 29
Distinctive:
If a commit contains multiple logical changes, list each change clearly in the commit message body.
line 30
Distinctive:
If uncertain about a decision, ask for guidance and stop before acting.
line 31
Distinctive:
Keep progress and final summaries minimal.
line 32
Distinctive:
If explicit permission is absent, do not push and ask for guidance.
line 38
Distinctive:
Ask for the base branch every time when it is not provided.
line 40
Distinctive:
Use a bulleted list with short phrases.
line 42
Distinctive:
If scope boundaries are unclear, ask for guidance before staging.
line 49
Distinctive:
Prefer one logical change per commit.
line 53
Distinctive:
If multiple changes must be included together, prepare a message body with a short list of included changes.
line 54
Distinctive:
Verify no unrelated files are included.
line 58
Distinctive:
If uncertainty exists about including a file, ask for guidance.
line 59
Distinctive:
Create the commit message.
line 61
Distinctive:
Keep summary concise and specific.
line 64
Distinctive:
Commit only the intended staged changes.
line 69
Distinctive:
If explicit permission to push is present, push.
line 74
Distinctive:
If permission is missing or ambiguous, ask for guidance and do not push.
line 75
Distinctive:
Create or verify PR template.
line 77
Very specific:
Use repository template at .github/pull_request_template.md.
line 79
Distinctive:
If missing, create it before opening a PR.
line 80
Distinctive:
Create PR with gh.
line 82
Distinctive:
Use gh pr create with target branch, title, and body from the template.
line 84
Distinctive:
If base branch, reviewers, or labels are unclear, ask for guidance first.
line 85
Distinctive:
After PR creation, output only the PR review URL unless the user asks for more detail.
line 89
Distinctive:
Commit title follows conventional commit plus gitemoji pattern.
line 100
Distinctive:
Commit granularity is meaningful.
line 101

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

Git Commit, Push, and PR Workflow

Outcome

Create high-quality commits at meaningful granularity.
Push only when permission exists.
Create a pull request with gh and return only the review URL.
Keep status summaries concise.

When to Use

Finalizing implementation work.
Preparing changes for review.
Standardizing commit and PR quality across contributors.

Rules

Use conventional commits with gitemoji.
Preferred commit format:
- fix(api): :wrench: short description
Keep one commit per logical change when possible.
If a commit contains multiple logical changes, list each change clearly in the commit message body.
If uncertain about a decision, ask for guidance and stop before acting.
Keep progress and final summaries minimal.

Defaults

Push permission default:
- Push only when explicit permission appears in the current chat request.
- If explicit permission is absent, do not push and ask for guidance.
PR base branch default:
- Ask for the base branch every time when it is not provided.
Multi-change commit body default:
- Use a bulleted list with short phrases.

Procedure

Validate change scope.

Confirm what should be included in this commit.
If scope boundaries are unclear, ask for guidance before staging.

Group changes by meaningful granularity.

Prefer one logical change per commit.
If multiple changes must be included together, prepare a message body with a short list of included changes.

Review the diff before committing.

Verify no unrelated files are included.
If uncertainty exists about including a file, ask for guidance.

Create the commit message.

Header pattern: type(scope): :gitemoji: summary
Keep summary concise and specific.
For multi-change commits, add a body with change bullets.

Create the commit.

Commit only the intended staged changes.
Re-check commit output and hash.

Decide whether to push.

If explicit permission to push is present, push.
If permission is missing or ambiguous, ask for guidance and do not push.

Create or verify PR template.

Use repository template at .github/pull_request_template.md.
If missing, create it before opening a PR.

Create PR with gh.

Use gh pr create with target branch, title, and body from the template.
If base branch, reviewers, or labels are unclear, ask for guidance first.

Return the review URL only.

After PR creation, output only the PR review URL unless the user asks for more detail.

Decision Gates

Unknown commit scope: ask.
Unsure file inclusion: ask.
Push permission unclear: ask and stop.
PR metadata unclear: ask.

Quality Checks

Commit title follows conventional commit plus gitemoji pattern.
Commit granularity is meaningful.
Multi-change commit includes explicit change list in body.
Push happens only with permission.
PR is created via gh and uses the template.
Final response is concise and includes only the review URL when PR is created.

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.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

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