Replace PR template with updated CONTRIBUTING.md and AGENTS.md (#1516)

The checkboxes don't really add value and end up polluting the commit
messages.

.github/pull_request_template.md

diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
deleted file mode 100644
index 583f215..0000000
--- a/.github/pull_request_template.md
+++ /dev/null
@@ -1,14 +0,0 @@
-## Buildtools PR checklist
-
-- [ ] The code in this PR is covered by unit/integration tests.
-- [ ] I have tested these changes and provide testing instructions below.
-- [ ] I have either responded to, or resolved all Gemini comments on the PR.
-- [ ] I have read Google Eng Practices on [Small Changes](https://google.github.io/eng-practices/review/developer/small-cls.html), this PR either follows these guidelines or the description provides reasoning for why they can not be followed.
-
-## Description
-
-What does this PR do? Please follow [Google Eng Practices - Description](https://google.github.io/eng-practices/review/developer/cl-descriptions.html)
-
-### (optional) These changes were tested using the following steps
-
-Steps to reproduce / test the PR changes (if anything besides unit tests).

AGENTS.md

diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000..26f1de2
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,5 @@
+# Agent instructions
+
+Follow [CONTRIBUTING.md](CONTRIBUTING.md). It describes how to build and test
+the repository, how to regenerate checked-in generated files, and what a pull
+request needs to contain.

CONTRIBUTING.md

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 21e4c71..ca91e35 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,25 +1,93 @@
-Want to contribute? Great! First, read this page (including the small print at the end).
+# Contributing to buildtools
 
-### Before you contribute
-Before we can use your code, you must sign the
-[Google Individual Contributor License Agreement](https://cla.developers.google.com/about/google-individual)
-(CLA), which you can do online. The CLA is necessary mainly because you own the
-copyright to your changes, even after your contribution becomes part of our
-codebase, so we need your permission to use and distribute your code. We also
-need to be sure of various other things—for instance that you'll tell us if you
-know that your code infringes on other people's patents. You don't have to sign
-the CLA until after you've submitted your code for review and a member has
-approved it, but you must do it before we can put your code into our codebase.
+Want to contribute? Great! First, read this page.
+
+## Before you contribute
+
 Before you start working on a larger contribution, you should get in touch with
 us first through the issue tracker with your idea so that we can help out and
 possibly guide you. Coordinating up front makes it much easier to avoid
 frustration later on.
 
-### Code reviews
-All submissions, including submissions by project members, require review. We
-use Github pull requests for this purpose.
+## Building and testing
 
-### The small print
-Contributions made by corporations are covered by a different agreement than
-the one above, the
-[Software Grant and Corporate Contributor License Agreement](https://cla.developers.google.com/about/google-corporate).
+The repository is built with Bazel. Use [Bazelisk](https://github.com/bazelbuild/bazelisk)
+to get the version pinned in `.bazelversion`. The Go toolchain is managed by
+Bazel, so you don't need a local Go installation.
+
+Run the full test suite, which is what CI runs on Linux, macOS and Windows:
+
+```sh
+bazel test //...
+```
+
+Other commands you may need:
+
+* After adding, removing or renaming Go files or imports, regenerate the
+  `BUILD.bazel` files:
+
+  ```sh
+  bazel run //:gazelle
+  ```
+
+* After changing Go dependencies, tidy `go.mod`, `go.sum` and `MODULE.bazel`.
+  CI fails if they are out of date:
+
+  ```sh
+  bazel run @io_bazel_rules_go//go -- mod tidy
+  ```
+
+* Go code must be formatted with `gofmt`. Starlark files in this repository
+  must be formatted with buildifier itself, either via
+  [pre-commit](https://pre-commit.com/) (`pre-commit install`) or by running:
+
+  ```sh
+  bazel run //:buildifier
+  ```
+
+### Generated files
+
+Some generated files are checked in, and tests fail if they are stale:
+
+* Protobuf bindings (`*.gen.pb.go`) and `lang/tables.gen.go`:
+
+  ```sh
+  ./update_generated.sh
+  ```
+
+* `WARNINGS.md`, after editing `warn/docs/warnings.textproto`:
+
+  ```sh
+  bazel build //warn/docs:warnings_docs && cp bazel-bin/warn/docs/WARNINGS.md .
+  ```
+
+* `build/parse.y.go`, after editing the grammar in `build/parse.y`:
+
+  ```sh
+  bazel build //build:parse.y.go_yacc && tail -n +3 bazel-bin/build/parse.y.baz.go > build/parse.y.go
+  ```
+
+### Adding a linter warning
+
+Register the warning in one of the warning maps in `warn/warn.go`, add tests
+next to the implementation, document it in `warn/docs/warnings.textproto` and
+regenerate `WARNINGS.md` as described above. A test checks that every warning
+is documented.
+
+## Pull requests
+
+All submissions, including submissions by project members, require review. We
+use GitHub pull requests for this purpose. Pull requests are squash-merged, so
+the pull request title and description become the commit message.
+
+Before you open a pull request, please make sure that:
+
+* The change is small and focused. Read Google's engineering practices on
+  [small changes](https://google.github.io/eng-practices/review/developer/small-cls.html);
+  if your change can't follow them, explain why in the description.
+* The description explains what the change does and why, following Google's
+  guidance on [writing good descriptions](https://google.github.io/eng-practices/review/developer/cl-descriptions.html).
+* The code is covered by unit or integration tests.
+* If you tested the change in ways that aren't captured by automated tests,
+  the description includes the steps to reproduce that testing.
+* `bazel test //...` passes and all generated files are up to date.