القائمة
Create a feature branch off master/develop/main when needed, stage and commit all changes, push, and immediately open a pull request via the gh CLI. Use when the user asks to open a PR, ship changes, or commit and create a pull request.
Perform deep, context-aware code reviews for GitHub pull requests or local branch changes. Use when the user asks to review a PR, analyze pull request changes, review current branch changes, run automated code review, or mentions PR
Perform a maximally thorough, CodeRabbit-style code review that fans out one focused sub-agent per changed file, runs every available linter/SAST/secret scanner, and reports every issue down to nitpicks. Use when the user asks for a deep, exhaustive, thorough, or nitpick-level review, a CodeRabbit-style review, to "find everything", to "leave no stone unturned", or wants maximum coverage on a PR or branch. Optimizes for recall; some noise is acceptable. For a fast, conservative, senior-engineer review that flags only what matters, use code-review instead.
Stage all repository changes and create a git commit with an auto-generated message after inspecting status, diff, and recent commit style. Use when the user asks to commit changes, save changes in git, stage and commit, or create a commit without needing confirmation.
| name | git-pr |
| description | Create a feature branch off master/develop/main when needed, stage and commit all changes, push, and immediately open a pull request via the gh CLI. Use when the user asks to open a PR, ship changes, or commit and create a pull request. |
| argument-hint | Optional summary of the work to ship |
Commit all current repository changes and immediately open a pull request. If the current branch is a protected base branch (master, main, or develop), create a feature branch first. Do not ask the user for confirmation — "open a PR" means do it.
Run in parallel:
git status --short — what will be stagedgit diff and git diff --stat — the actual changesgit branch --show-current — the current branchgit log -5 --oneline — to match the repo's existing commit styleIf there is nothing to commit, report that and stop. Do not create an empty commit or an empty PR.
CURRENT be the output of git branch --show-current.CURRENT is master, main, or develop (a protected base branch):
CURRENT.git switch -c feature/<slug>.CURRENT; do not create a new branch.develop if it exists: git ls-remote --exit-code --heads origin develop.gh repo view --json defaultBranchRef -q .defaultBranchRef.name.Build <slug> as a short kebab-case summary of the work, derived from the supplied
argument or the diff (e.g. feature/fix-login-redirect). If the supplied summary
contains a task/issue key such as ABC-123, include it: feature/ABC-123-fix-login-redirect.
Stage everything from the repository root: git add -A.
Generate a commit message following the same conventions as the git-commit skill:
Co-Authored-By lines.Commit using a HEREDOC so formatting is preserved:
git commit -m "$(cat <<'EOF'
<subject>
<body>
EOF
)"
git push -u origin <branch>
Use the commit subject as the title and a short summary as the body:
gh pr create --base <base> --head <branch> --title "<subject>" --body "$(cat <<'EOF'
## Summary
<2–4 sentence overview of the change and why it was made>
## Changes
- <key change>
- <key change>
EOF
)"
Report the PR URL printed by gh pr create. Verify success with git status.
gh is not installed or not authenticated (gh auth status fails), report that and stop after committing — do not lose the commit.git push fails (e.g. no remote, rejected, auth), report the exact error rather than retrying blindly.gh pr create will fail — report the existing PR (gh pr view --json url) instead of treating it as an error.