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.

Always include @CONTRIBUTING.md in rule definitions so that PR formatting rules are injected into context whenever PR workflows run.

fix: / feat:: User-visible changes ONLY.
build: / build(release):: Internal release tooling (dev/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/).
refactor:: Internal refactoring and fixes for unreleased changes. Never use fix: or feat: unless modifying released, user-visible behavior.

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.
PR Metadata Discrepancies: If a PR title or description diverges from the branch's actual scope, notify the user of the discrepancy and ask for confirmation before updating GitHub.
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>).
Conciseness & Style (Strunk & White): Omit needless words. Use clear, active, and direct phrasing for why and how.
Preserve Existing Descriptions: Preserve the author's wording unless instructed to change it. Wrap bodies at 72 columns.