creating-pull-requests

Creating Pull Requests

PR Title

• Short, under 70 characters
• Use conventional commit prefix: feat:, fix:, chore:, refactor:, docs:
• Describe the behaviour change, not the technical change

PR Body

Use this format:

## Summary

{1-3 sentences describing what changed from the user's perspective. Focus on behaviour, not implementation details. No bullet lists of files changed.}

Rules

• No lists of file changes — the diff shows that
• No "Test plan" section — tests are in the code
• No "Generated with Claude Code" footer
• No Co-Authored-By trailers on commits
• Write like a human, not a bot. Short sentences, plain language.
• If there's something reviewers need to know (breaking change, follow-up needed, heads-up), add it after the summary as a paragraph prefixed with bold label.

Example

## Summary

Migration files are now version-controlled instead of generated on the fly. Scripts that previously deleted and regenerated migrations now use the committed ones directly.

This is the foundation for persistent databases (#1009). Safe to deploy under the current flow — the old deploy still wipes the DB, so committed migration files don't change anything yet. The actual switch happens in a follow-up PR.

**Heads up:** If you change a model, you now need to run `task makemigrations` and commit the resulting file. If you forget, tests will fail.

Process

1. Check git status, git diff, and git log to understand what's being submitted
2. Draft title and body following the format above
3. Show the draft to the user before creating
4. Push the branch and create the PR with gh pr create
5. Return the PR URL