--- name: pr description: Create a pull request following project conventions. Triggers on any request to create, open, make, submit, file, send, push, spin up, put up, draft, raise, or prepare a PR/pull request. allowed-tools: Bash, Read, Grep, Glob user-invocable: true --- # Create Pull Request Create a pull request following the project's PR conventions. @docs/pull-request-guidelines.md ## Steps **IMPORTANT: Follow ALL steps in order. Do not skip any step, even if the PR seems simple.** 1. **Verify branch.** Confirm you are NOT on `trunk`. If on trunk, stop and ask the user to create a feature branch first. 2. **Check for uncommitted changes.** Run `git status`. If there are uncommitted changes, stop and ask the user whether to commit them first. 3. **Analyze the diff.** Run `git diff trunk...HEAD` to understand ALL changes that will be in the PR. Also run `git log --oneline trunk..HEAD` to see all commits. 4. **Check diff size.** Count non-test lines changed. If the diff is very large, mention it to the user. 5. **Review changes.** Scan for: - Architecture compliance (MVVM layers, Hilt DI, Compose patterns) - Missing tests for new logic - Any `FIXME`, `!!`, wildcard imports, or other violations - Whether `RELEASE-NOTES.txt` needs updating (user-facing changes) 6. **Check RELEASE-NOTES.txt.** If changes are user-facing, remind the user to update `RELEASE-NOTES.txt`. Use `[Internal]` for non-user-facing changes. 7. **Push the branch.** Run `git push -u origin `. 8. **Create the PR.** Read `.github/PULL_REQUEST_TEMPLATE.md` and use it as the body. Strip the HTML comments and fill in each section, following the conventions from the guidelines doc above: - **Description**: start with `Fixes WOOMOB-XYZ` on its own line, then a short summary of what changed and why. - Keep it to what a reviewer needs: what was wrong, what this changes, and anything they can't see in the diff. A couple of sentences of plain prose is usually right — no section headers beyond the template's. If the PR fixes several distinct things, one line each is fine. - The conversation that produced the PR is not the PR. Don't retell the investigation — no debugging path, no narrative of how you got there, no measurements unless the measurement is the reason for the change. - Do pre-empt what a reviewer would actually raise: a decision they'd disagree with, or an obvious alternative they'd ask "why not X?" about. A sentence or a clause each, in prose. The bar is "they'd bring this up in review", not "this was interesting to figure out". Most PRs have nothing that clears it; if you end up with a list, you're padding. - Write so a reviewer who never saw this branch can follow it — carry the context, not the derivation. - References the reviewer can follow (a Linear issue, a linked Slack thread, a prior PR) are fine. What's not fine is referencing things the reviewer has no access to: the Claude session, findings-by-number from a private review ("HIGH-#2"), or severity labels from a one-off discussion. If you write "as discussed," make sure "discussed" is a link the reviewer can open. - **Test Steps**: numbered manual verification steps — a reviewer tapping through the app or reproducing a scenario. Do NOT include "run the unit tests" (or any `./gradlew test*` invocation) as a step — CI already runs them, so they add noise without helping the reviewer. - **Images/gif**: include if applicable, otherwise `N/A`. - Keep the release-notes checkbox line as-is. Pass the filled template via a HEREDOC: ```bash gh pr create --draft --title "[WOOMOB-XYZ] " --body "$(cat <<'EOF' EOF )" ``` 9. **Add labels.** Add labels using `gh pr edit --add-label "