AGENTS.md

1# Working with Metrolist as an AI agent
2 
3Metrolist is a 3rd party YouTube Music client written in Kotlin. It follows material 3 design guidelines closely.
4 
5## Rules for working on the project
6 
71. Always pull the latest changes from `main` before starting your work to minimize merge conflicts.
82. Commit names should be clear and follow the format: `type(scope): short description`. For example: `feat(ui): add dark mode support`. Including the scope is optional.
93. All string edits should be made to the `Metrolist/app/src/main/res/values/metrolist_strings.xml` file, NOT `Metrolist/app/src/main/res/values/strings.xml`. Do not touch other `strings.xml` or `metrolist_strings.xml` files in the project. ONLY edit the default (English) `metrolist_strings.xml` file, DO NOT EDIT OTHER LANGUAGES.
104. You are to follow best practices for Kotlin and Android development.
115. DO NOT EDIT THE APP'S DATABASE SCHEMA.
12 
13## AI-only guidelines
14 
151. You are strictly prohibited from making ANY changes to the readme/markdown files, including this one. This is to ensure that the documentation remains accurate and consistent for all contributors.
162. Unless explicitly requested, you are not allowed to commit, push, or merge any changes to any branch. If you are explicitly requested and authorized to commit/push/merge, you have the right to do so; the responsibility then lies with the author who requested it.
17   - You should absolutely NOT use any commands that would modify the git history, do force pushes (except for rebases on your own branch), or delete branches without explicit instructions from a human.
183. Always follow the guidelines and instructions provided by human contributors.
194. Ensure the absolutely highest code quality in all contributions, including proper formatting, clear variable naming, and comprehensive comments where necessary.
205. Comments should be added only for complex logic or non-obvious code. Avoid redundant comments that simply restate what the code does.
216. Prioritize performance, battery efficiency, and maintainability in all code contributions. Always consider the impact of your changes on the overall user experience and app performance.
227. If you have any doubts ask a human contributor. Never make assumptions about the requirements or implementation details without clarification.
238. If you do not test your changes using the instructions in the next section, you will be faced with reprimands from human contributors and may be asked to redo your work. Always ensure that you test your changes thoroughly before asking for a final review.
249. You are absolutely **not allowed to bump the version** of the app in ANY way. Version bumps are only done by the core development team after manual review.
25 
26## Building and testing your changes
27 
281. After making changes to the code, you should build the app to ensure that there are no compilation errors. Use the following command from the root directory of the project:
29 
30```bash
31./gradlew :app:assembleFossDebug
32```
33 
342. If the build is not successful, review the error messages, fix the issues in your code, and try building again.
353. Once the build is successful, you can test your changes on an emulator or a physical device. Install the generated APK located at `app/build/outputs/apk/universalFoss/debug/app-universal-foss-debug.apk` and ask a human for help testing the specific features you worked on.
36