| --- |
| trigger: model_decision |
| description: rules to apply to pull request descriptions |
| --- |
| |
| @CONTRIBUTING.md |
| |
| # Pull Request Conventions |
| |
| Before drafting any pull request description, strictly adhere to the rules in |
| `CONTRIBUTING.md` above. |
| |
| ## Prevent Agent Oversight of `CONTRIBUTING.md` |
| * Always include `@CONTRIBUTING.md` in rule definitions so that PR formatting |
| rules are injected into context whenever PR workflows run. |
| |
| ## Commit & PR Types |
| * `fix:` / `feat:`: User-visible changes ONLY. |
| * `build:` / `build(release):`: Internal release tooling |
| (`tools/private/release/`), developer workflows, and build scripts. Always |
| prefer `build(release):` over `chore:` or `chore(release):`. |
| * `docs:`: Documentation and issue templates (`.github/ISSUE_TEMPLATE/`). |
| * `ci:`: `.bazelci` and Buildkite CI configurations. |
| * `workflow:` / `workflows:`: GitHub Actions workflow configurations |
| (`.github/workflows/`). |
| * `tests:`: Test-only changes and test-helper fixes (never `fix:` or |
| `fix(tests):`). |
| * `agents:` / `agents(<scope>):`: Agent rules, skills, and prompts |
| (`.agents/`). |
| |
| ## PR Commit Workflow Invariant |
| * Once a Pull Request is created, always make new commits or merge commits. |
| * **NEVER** amend or rebase commits on an active PR branch to avoid breaking |
| code review threads. |
| * **NEVER** include a list of per-file edits or changelog bullet points of |
| individual file modifications in PR descriptions or commit messages. |
| * High-level overview only: state *why* the change is made and *how* at a |
| conceptual level. Link related issues (e.g. `Work towards #<issue>`). |
