add initial AGENTS.md file, change coderrabit (#484)

.coderabbit.yml

@@ -1,46 +1,17 @@
 reviews:
+  auto_approvals:
+    enabled: true
   tools:
     github-checks:
       enabled: true
   path_instructions:
     - path: "README.md"
       instructions: |
-        When reviewing changes to README.md, only evaluate list entries/links that are newly added by this pull request (new lines in the diff). Do not re-validate or flag pre-existing entries that the PR did not touch, even if they would fail one of the checks below.
+        When reviewing changes to README.md, only evaluate list entries/links that are newly added by this pull request (new `- ` / `* ` lines introducing a link). Do not re-validate or flag pre-existing entries that the PR did not touch, even if they would fail one of the checks below. If an existing entry was only repositioned (e.g. as a side effect of inserting a new entry) without any content change, do not flag it, but still use it as context to confirm the resulting order is correct.
 
-        ## 1. Scope - New Links Only
-        - Identify only the list entries added by this PR (new `- ` / `* ` lines introducing a link).
-        - Entries that already existed before the PR, and were not modified, must be ignored even if they are out of order, missing an emoji, or otherwise non-compliant.
-        - If an existing entry was only repositioned (e.g. as a side effect of inserting a new entry) without any content change, do not flag it, but still use it as context to confirm the resulting order is correct.
+        Apply the full "Rules that apply to any change to README.md" checklist from AGENTS.md at the repo root to every newly added entry: alphabetical ordering within its section, required license emoji (with the documented exceptions for Blogs and Portals, Videos/Podcasts, Game Jams, and Communities), link validation (https:// only, well-formed, reachable, 100+ GitHub stars for repo links), and game-development relevance.
 
-        ## 2. Alphabetical Ordering
-        - Each section/subsection (e.g. `#### Assets/Placeholders`, `#### Spritesheet Tools`, `### Books`, etc.) must have its entries sorted A-Z by link text (the text inside `[]`).
-        - For every newly added entry, verify it was inserted in the correct alphabetical position relative to the other entries (new and pre-existing) already in that section.
-        - Flag a new entry if it is not in the correct alphabetical position.
-
-        ## 3. License Emoji Validation
-        - Every newly added entry must start with one of these emojis:
-          - `:free:` - Free
-          - `:tada:` - Open Source
-          - `:moneybag:` - Paid
-          - `:money_with_wings:` - Partially Free
-        - Exception: new entries added under `### Blogs and Portals`, `### Videos/Podcasts`, `### Game Jams`, and `### Communities` are NOT required to have one of these emojis.
-        - For all other sections, flag any new entry that:
-          - Is missing an emoji entirely
-          - Uses an invalid/different emoji (not one of the four above)
-          - Uses an inconsistent emoji format (e.g. `🆓` instead of `:free:`)
-
-        ## 4. Link Validation
-        - Every newly added link must be a valid, well-formed URL using the `https://` scheme only. Flag `http://` links and any other protocol (ftp, file, mailto, javascript, etc.).
-        - Flag malformed or unreachable (broken/dead) URLs.
-        - If a newly added link points to a GitHub repository (e.g. `https://github.com/<owner>/<repo>`), look up the repository and flag it if it has fewer than 100 stars.
-
-        ## 5. Game Development Relevance
-        - Every newly added link must be explicitly about game development (e.g. engines, game-specific tools, game art/audio assets, game tutorials/books, game-dev communities, etc).
-        - Flag new links to general-purpose tools or resources that are not specifically focused on game development, even if they could incidentally be used while making a game.
-
-        ## 6. Reporting Failures
-        - If any check above fails for a newly added link, comment directly on that line, tag the PR author, and clearly explain which check(s) failed and what needs to be fixed.
-        - When any new link fails a check, request changes on the review instead of approving.
+        If any check fails for a newly added link, comment directly on that line, tag the PR author, and clearly explain which check(s) failed and what needs to be fixed. When any new link fails a check, request changes on the review instead of approving.
   pre_merge_checks:
     custom_checks:
       - name: "README New Links Validation"