How do I install the Git Commit Push Pr skill?

Run npx skillmds@latest add devoxx/git-commit-push-pr in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Git Commit Push Pr safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Git Commit Push Pr?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Git Commit Push Pr free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Git Commit Push Pr?

devoxx (@devoxx) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Git Commit Push Pr by devoxx — Agent Skill

Name: Git Commit Push Pr
Author: devoxx

File contents

Git Commit, Push & PR

Context

Current git status: !git status
Current git diff (staged and unstaged changes): !git diff HEAD
Current branch: !git branch --show-current
Main branch: !git rev-parse --verify main 2>/dev/null && echo main || echo master
Recent commits: !git log --oneline -10

Your task

Review the changes in the repo and ship them as a pull request in one go.

Step 1 — Analyze changes and plan commits

Before committing, analyze git status and git diff HEAD to identify logically distinct groups of changes. Group by feature or concern — for example:

New files that form a self-contained module → one commit
Modifications to an existing file that depend on the new module → separate commit
Config or tooling changes → separate commit

Print a short commit plan (list of planned commits with the files in each) so the grouping is visible.

Step 2 — Commit

Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never git add -A; never stage .env or credential files).
Write a clean, descriptive commit message for each commit using conventional commits style.
End every commit message with: Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Use a HEREDOC to pass the commit message for correct formatting.

Step 3 — Push

If the current branch is main or master, create a new feature branch first (use a descriptive name based on the changes).
Push the branch to origin with -u to set upstream tracking.

Step 4 — Pull Request

Create a PR using gh pr create targeting the main branch.
Keep the PR title short (under 70 characters), using conventional commit style.
Use a HEREDOC for the PR body with this format:

## Summary
<1-3 bullet points describing the changes>

## Test plan
- [ ] <testing checklist items>

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Step 5 — Report

Print the PR URL so the user can see it.

Rules

Do all steps in as few messages as possible. Parallelize independent tool calls.
Do not read or explore code beyond what git provides in the context above.
Do not use interactive git flags (-i).
Never force-push or amend existing commits.
If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).

---name: git-commit-push-prdescription: Commit all changes, push to remote, and open a pull request in one go. Use when the user says "commit push pr", "ship it", "open a pr", or invokes /git-commit-push-pr.---# Git Commit, Push & PR## Context- Current git status: !`git status`- Current git diff (staged and unstaged changes): !`git diff HEAD`- Current branch: !`git branch --show-current`- Main branch: !`git rev-parse --verify main 2>/dev/null && echo main || echo master`- Recent commits: !`git log --oneline -10`## Your taskReview the changes in the repo and ship them as a pull request in one go.### Step 1 — Analyze changes and plan commitsBefore committing, analyze `git status` and `git diff HEAD` to identify logically distinct groups of changes. Group by feature or concern — for example:- New files that form a self-contained module → one commit- Modifications to an existing file that depend on the new module → separate commit- Config or tooling changes → separate commitPrint a short commit plan (list of planned commits with the files in each) so the grouping is visible.### Step 2 — Commit- Create one commit per logical group identified above. Stage only the files for that group using explicit file names (never `git add -A`; never stage `.env` or credential files).- Write a clean, descriptive commit message for each commit using conventional commits style.- End every commit message with: `Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>`- Use a HEREDOC to pass the commit message for correct formatting.### Step 3 — Push- If the current branch is `main` or `master`, create a new feature branch first (use a descriptive name based on the changes).- Push the branch to origin with `-u` to set upstream tracking.### Step 4 — Pull Request- Create a PR using `gh pr create` targeting the main branch.- Keep the PR title short (under 70 characters), using conventional commit style.- Use a HEREDOC for the PR body with this format:```## Summary<1-3 bullet points describing the changes>## Test plan- [ ] <testing checklist items>🤖 Generated with [Claude Code](https://claude.com/claude-code)```### Step 5 — Report- Print the PR URL so the user can see it.## Rules- Do all steps in as few messages as possible. Parallelize independent tool calls.- Do not read or explore code beyond what git provides in the context above.- Do not use interactive git flags (`-i`).- Never force-push or amend existing commits.- If a pre-commit hook fails, fix the issue and create a NEW commit (do not amend).

Frequently asked questions

Git Commit Push Pr