diff --git a/AGENTS.md b/AGENTS.md
index b89e31407c8..018b8d23416 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -1,5 +1,7 @@
+## Build and tests
+
 On Windows we use msys2 and ucrt64 to compile.
-You need to prefix commands with `C:\msys64\msys2_shell.cmd -defterm -here -no-start -ucrt64 -c`.
+Prefix Windows build and test commands with `C:\msys64\msys2_shell.cmd -defterm -here -no-start -ucrt64 -c`.
 
 Prefix build directories with `cmake-build-`.
 
@@ -8,6 +10,19 @@ the build directory.
 
 The project uses gtest as a test framework.
 
+Add or update tests for new or modified methods and code. Target 100% coverage on changed code.
+
+## Python tooling and formatting
+
+From the repository root, run `uv sync --locked` to create or refresh `.venv` from `pyproject.toml` and `uv.lock`.
+Re-run it after switching branches or changing either file or the `third-party/lizardbyte-common` submodule.
+After changing dependency declarations or the submodule revision, run `uv lock` before syncing.
+
+After native code changes, run `uv run --locked lb-update-clang-format` from the repository root. The command is
+provided by `third-party/lizardbyte-common`; inspect the resulting diff for unrelated formatting changes.
+
+## Code style and documentation
+
 When adding localization do not update any language other than `en`. This also means to exclude en-US or other variants.
 
 Always add or update doxygen documentation.
@@ -29,8 +44,38 @@ Inline doxygen comments should use `///< ...` instead of `/**< ... */`.
 
 Always follow the style guidelines defined in .clang-format for c/c++ code.
 
-Do not ever create issues or pull requests.
-If asked to create an issue or pull request, do so in their fork instead of the LizardByte GitHub organization.
-Never create an issue or pull request in the LizardByte GitHub organization.
+Do not add decorative separator comments, including dashed banners that label groups of tests. Use descriptive
+test names and code structure to show the grouping instead.
 
-Add or update tests for new or modified methods and code. Target 100% coverage on changed code.
+## Issues and pull requests
+
+When asked to create an issue or pull request, use the templates provided by the LizardByte/.github repo or
+LizardByte/Sunshine repo, with the Sunshine templates taking precedence if both exist. At the end of the issue
+or pull request body, add an attribution naming the AI agent, model, and thinking level used to generate it.
+Repeat that attribution in a separate comment on the created issue or pull request. For example:
+
+```
+> This issue was generated by ChatGPT 6 Sol, extra high thinking level
+```
+
+When asked to create an issue, do only enough investigation to verify and accurately describe the problem unless the
+user also asks for an investigation. Keep the issue concise: state the observed behavior, expected behavior, and
+reproduction steps or evidence when available. Do not include an exhaustive root-cause analysis or implementation
+plan in the issue. This limit applies only to creating issues; investigate or fix issues fully when asked.
+
+## Code Review Rules
+
+Report concrete issues introduced by the change that the contributor can address. For each finding, explain the
+triggering condition, impact, and a practical fix; point to the relevant code or test. Keep workflow status separate
+from code findings.
+
+If GitHub Actions workflows are queued for maintainer approval, or a dependent check times out before its job can run,
+do not leave an inline comment, request changes, or ask the contributor to run the workflows. The maintainer controls
+approval. If the missing results materially limit the review, mention that once in the review summary as a verification
+limit for the maintainer. Review actual failed checks for change-related problems when their logs are available.
+
+For pull request reviews, verify the current PR head and mergeability against its target branch. If conflicts are
+confirmed, tell the author in the review summary that the PR needs to be rebased and the conflicts resolved before
+merging. Do not infer conflicts from an unknown or pending mergeability status.
+
+When approving a pull request, the approval itself is sufficient. Do not add a comment solely to accompany it.