AGENTS.md: Follow CONTRIBUTING.md for contribution policy

Signed-off-by: Paweł Gronowski <pawel.gronowski@docker.com>

AGENTS.md

@@ -1,22 +1,12 @@
-# Commits
+# Contribution guidelines
 
-Keep each commit focused on one atomic, independently reviewable change.
-A pull request may contain multiple commits when they represent separate changes.
-Fold review fixes into the commits they correct before merging, rather than leaving a separate commit for each review fix.
-Temporary fixup commits are fine during review, but squash them into the appropriate commits before merging.
-Prefer separate commits for unrelated changes rather than squashing them just to make the pull request a single commit.
+Read and follow [CONTRIBUTING.md](CONTRIBUTING.md) before making changes or opening pull requests.
+It is the source of truth for contribution scope, coding style, testing, commits, DCO sign-off, review, AI usage, and release notes.
 
 # Pull requests
 
 When opening a pull request:
 
 - Follow `.github/PULL_REQUEST_TEMPLATE.md` and fill in the applicable sections.
-- Do not add `Co-Authored-By` trailers for LLMs or AI agents; reserve them for
-  human contributors.
+- Do not add `Co-Authored-By` trailers for LLMs or AI agents; reserve them for human contributors.
 - Add "Created with: <AGENT NAME>" note at the end of the PR body.
-
-## Release note section
-
-If the change is worthy putting in a user-facing release changelog, write a brief entry, ideally one sentence.
-Use present tense and imperative tone.
-Draw inspiration from past release notes: https://docs.docker.com/engine/release-notes/

CONTRIBUTING.md

@@ -43,6 +43,7 @@ Regenerate vendored files with the repository's vendoring tooling rather than ed
 ### Conventions
 
 Keep the pull request focused and explain the problem and solution in its description.
+Fill in the applicable sections of the [pull request template](.github/PULL_REQUEST_TEMPLATE.md).
 Put related issue and PR links there, using a closing keyword such as `Fixes` when appropriate.
 
 Include tests for your changes; see [TESTING.md](TESTING.md) for guidance and test filters.
@@ -55,6 +56,11 @@ User guides live in [docker/docs](https://github.com/docker/docs); follow its [s
 Check documentation for clarity, correctness, and broken links, and run the relevant validation.
 The `AUTHORS` file is generated from Git history; leave it unchanged.
 
+### Release notes
+
+For changes worth a user-facing changelog entry, include a brief release note, ideally one sentence.
+Use present tense and imperative tone; see [Docker Engine release notes](https://docs.docker.com/engine/release-notes/) for examples.
+
 ### Commit Messages
 
 Use a short imperative summary, prefixed with the affected component for scoped changes, such as `daemon:` or `client:`.
@@ -95,6 +101,7 @@ Signed-off-by: Joe Smith <joe.smith@email.com>
 
 Read and follow the shared [Moby and Docker AI usage policy](https://github.com/moby/.github/blob/main/AI_POLICY.md).
 Disclose which tools you used and roughly how much work they did in the issue or PR description, not in commit messages.
+For AI-assisted pull requests, add a `Created with: <AGENT NAME>` note at the end of the description.
 Review and edit AI-assisted content before posting; you remain responsible for the submission.
 Reserve `Co-Authored-By` trailers for human contributors, not LLMs or AI agents.