|
| 1 | +# GitHub PRs |
| 2 | + |
| 3 | +These rules apply to every developer and AI agent opening pull requests in this |
| 4 | +repository. |
| 5 | + |
| 6 | +## Repository and branch |
| 7 | + |
| 8 | +Open PRs against `master` in `PolicyEngine/policyengine-core`. |
| 9 | + |
| 10 | +Before creating or sharing a PR: |
| 11 | + |
| 12 | +1. Confirm the canonical repository is reachable: |
| 13 | + `gh repo view PolicyEngine/policyengine-core --json nameWithOwner`. |
| 14 | +2. Add the required towncrier changelog fragment under `changelog.d/`. |
| 15 | +3. Push the current branch to `PolicyEngine/policyengine-core`. |
| 16 | +4. Create the PR against `master`. |
| 17 | +5. Verify the PR head repository before reporting it: |
| 18 | + `gh pr view <PR> --repo PolicyEngine/policyengine-core --json headRepositoryOwner,headRepository`. |
| 19 | + |
| 20 | +If you cannot push to the canonical repository, stop and ask for access. Do not |
| 21 | +open a fork PR as a fallback unless the user explicitly asks for one. |
| 22 | + |
| 23 | +## Changelog fragment |
| 24 | + |
| 25 | +A changelog entry is required before opening, replacing, or sharing a PR. When a |
| 26 | +user asks an AI agent to open a PR, the agent must check for an appropriate |
| 27 | +fragment and add one if it is missing before running `gh pr create`. |
| 28 | + |
| 29 | +Use towncrier fragments in this format: |
| 30 | + |
| 31 | +```text |
| 32 | +changelog.d/<short-slug>.<type>.md |
| 33 | +``` |
| 34 | + |
| 35 | +Allowed `<type>` values are configured in `pyproject.toml`: |
| 36 | + |
| 37 | +- `breaking` |
| 38 | +- `added` |
| 39 | +- `changed` |
| 40 | +- `fixed` |
| 41 | +- `removed` |
| 42 | + |
| 43 | +Examples: |
| 44 | + |
| 45 | +```text |
| 46 | +changelog.d/fix-enum-utf8-bytes.fixed.md |
| 47 | +changelog.d/add-agent-pr-guidance.changed.md |
| 48 | +``` |
| 49 | + |
| 50 | +Write one concise Markdown sentence in the fragment. Use `fixed` for bug fixes, |
| 51 | +`added` for new user-facing capabilities, `changed` for behavior, documentation, |
| 52 | +tooling, or refactors, `removed` for removals, and `breaking` only for changes |
| 53 | +that intentionally break compatibility. Prefer updating an existing branch |
| 54 | +fragment over adding duplicate fragments for the same PR. |
| 55 | + |
| 56 | +Do not run `make changelog` for a PR. The release workflow builds |
| 57 | +`CHANGELOG.md` from fragments after merge. |
| 58 | + |
| 59 | +## PR title |
| 60 | + |
| 61 | +Do not add `[codex]`, `[claude]`, `[copilot]`, or other agent labels to PR |
| 62 | +titles. Use a plain descriptive title. |
| 63 | + |
| 64 | +## PR body |
| 65 | + |
| 66 | +Keep the description concrete: |
| 67 | + |
| 68 | +- Link the issue the PR fixes. |
| 69 | +- Summarize the user-visible behavior change. |
| 70 | +- List the tests or checks run. |
| 71 | +- Call out any commands that were not run and why. |
0 commit comments