devoxx/git-commit-push-pr
.claude/skills/git-commit-push-pr/SKILL.md
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.
$ install --global
skillsauthnpx skillsauth add devoxx/devoxxgenieideaplugin git-commit-push-prInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
Security Scan Results
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
3
Scanners Passed
9
Scanners in report
Clean
TrivyContainer and dependency vulnerability scanner
95%
Clean
SemgrepStatic code analysis for vulnerabilities
95%
Clean
mcp-scan (Snyk)Model Context Protocol security validation
95%
Skipped
Snyk (dep)Open source security scanning
50%
Skipped
Socket.devSupply chain security analysis
50%
Skipped
VirusTotalMulti-engine malware detection
50%
Skipped
CrowdStrikeAdvanced threat intelligence
50%
Skipped
OSV-ScannerOpen Source Vulnerability database check
50%
Skipped
OWASP Dep-Check
50%
Last scanned: Apr 15, 2026, 5:25 PM4.4s1 file scanned
SKILL.md
- name:
- git-commit-push-pr
- description:
- 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.
- allowed-tools:
- Bash(git add:*), Bash(git status:*), Bash(git diff:*), Bash(git log:*), Bash(git commit:*), Bash(git push:*), Bash(git branch:*), Bash(git checkout:*), Bash(gh pr create:*)
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.envor 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.6 (1M context) <[email protected]> - Use a HEREDOC to pass the commit message for correct formatting.
Step 3 — Push
- If the current branch is
mainormaster, create a new feature branch first (use a descriptive name based on the changes). - Push the branch to origin with
-uto set upstream tracking.
Step 4 — Pull Request
- Create a PR using
gh pr createtargeting 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).
Related Skills
devoxx/start-task
tools
VerifiedTrustedCommunity
Create a feature branch for a backlog task, switch to it, and start implementation. Use when the user says "start task-123", "work on task-123", "implement task-123", or invokes /start-task with a task ID.
637SKILL.mdUpdated Apr 15, 2026
devoxx/review
development
VerifiedTrustedCommunity
Review local code changes for bugs, regressions, missing tests, and pragmatic improvements. Use when the user asks to review the current changes from `git status`, or to review a specific backlog task by id such as `task-65` or `TASK-65`. Also trigger when the user says things like "review", "review current changes", "check my changes", "look over the diff", or "review task-42".
637SKILL.mdUpdated Apr 15, 2026
devoxx/.claude/skills/release
tools
VerifiedTrustedCommunity
# Release Workflow 1. ASK the user for the target version number - do not assume 2. Update version in: build.gradle.kts, plugin.xml, application.properties, and any other version files 3. Skip local config files (e.g., local.properties) 4. Update plugin change-notes in plugin.xml with new version section 5. If CHANGELOG.md exists at the project root, add a new version section at the top with categorized entries (Added, Changed, Fixed, Documentation, Dependencies) based on merged PRs/commits sinc
637SKILL.mdUpdated Apr 15, 2026
devoxx/.claude/skills/pr
development
VerifiedTrustedCommunity
# Create PR Workflow 1. Ensure all changes are on a feature/fix branch (create one if on main/develop) 2. Run the build: `./gradlew build` 3. Run tests: `./gradlew test` 4. If build+tests pass, commit with a conventional commit message 5. Push the branch 6. Create a PR with a descriptive title and body summarizing changes 7. Report the PR URL
637SKILL.mdUpdated Apr 15, 2026