// Commit all changes, push to a new branch, and create a pull request using the repo's PR template. Use when the user says to make a PR or submit changes.
| name | pr |
| description | Commit all changes, push to a new branch, and create a pull request using the repo's PR template. Use when the user says to make a PR or submit changes. |
| disable-model-invocation | true |
| allowed-tools | Bash Read Glob Grep Agent |
Create a branch, commit, push, and open a PR for the current changes.
Run in parallel:
git status (never use -uall)git diff and git diff --staged to understand all changesgit log --oneline -5 to see recent commit message styleIdentify which files should be committed. Do NOT commit files that are:
.env, credentials, etc.)If there are no meaningful changes to commit, tell the user and stop.
Branch names in this repo follow the pattern: <area>/<type>/<short-description>
Where:
<area> is one of: backend, web, frontend, mobile, devops, docs, or another area that matches the changed files. For cross-cutting changes spanning multiple areas, pick the one that best describes the change.<type> is one of: feature, bugfix, fix, refactor, or similar<short-description> is a short kebab-case descriptionInfer area and type from the changed files and the nature of the changes. Never use a username as the area.
Before committing, run the appropriate linters and formatters for the changed areas:
make format and make mypy from /app/backendFix any issues before proceeding. If linters produce changes, include those in the commit.
If there are already commits on the current branch and no uncommitted changes remain (e.g. changes were already committed earlier), skip the commit and proceed to pushing.
Otherwise:
git checkout -b <branch-name>
git add <specific files> # add only the relevant files by name
git commit -m "<message>"
Write a concise commit message (1-2 sentences) that describes what changed and why.
git push -u origin <branch-name>
Read the PR template from .github/pull_request_template.md in this repo. Fill it in based on the actual changes:
Fill in the description at the top (what and why)
Fill in the Testing section with what was done or what should be done
Include the appropriate checklist(s) — backend, web, or both — based on which areas were changed. Remove checklists that don't apply.
Keep the "For maintainers" section as-is
Append the following note as the very last line of the PR body, after the "For maintainers" section (separated by a blank line):
_This PR was created with the Couchers PR skill._
gh pr create --base develop --title "<short title>" --body "$(cat <<'EOF'
<filled-in PR template>
_This PR was created with the Couchers PR skill._
EOF
)"
Tell the user the PR URL when done.