{"owner":"hyprwm","repo":"Hyprland","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"files":{"AGENTS.md":"# AGENTS.md\n\n## Review guidelines\n\n- Prioritize correctness, lack of regressions, performance, API stability, and code clarity and readability.\n- For performance-sensitive paths, flag obvious algorithmic regressions or slow paths.\n- For tests, flag missing coverage for changed or new behavior, as long as the testing framework is capable of testing it.\n- For config changes (new / removed options) remind the author to make a separate wiki PR if they haven't linked one yet.\n- Flag silent config breakage: e.g. changing an existing option's behavior. This is not allowed.\n- Flag bad config style that breaks this project's style guidelines (further below) and suggest fixes.\n- Flag bad code approaches that break this project's core code guidelines (further below) and suggest improvements.\n\n## Style guidelines\n\n- Code must be clang-formatted according to `.clang-format`.\n- single-line if and else statements must come without braces. This rule applies only to if / else, not do / while / other.\n- Avoid function bodies in headers as much as possible.\n- Avoid namespace {} in source files to mark local functions. Prefer `static`.\n- Prefer guards in functions and loops: `if (!cond) continue;`\n- Prefer forward-declaration in headers to inclusion.\n- Leave a stray `,` at the end of brace-enclosed lists to make formatting easier to read.\n- Leave a `;` inside empty function bodies for formatting.\n- Naming conventions:\n - class: `CMyClass`\n - struct: `SMyStruct`\n - interface: `IMyInterface`\n - class (not struct) member variables: `m_variable`\n- Do not use absolute includes from `src/` in headers: instead of `#include \"a/b.hpp\"` use `#include \"../a/b.hpp\"` for example. Protocol headers do not require this.\n\n## Core code guidelines\n\n- Stick to good code practices:\n - Avoid complex classes / functions, prefer SRP.\n - Consider using an observer pattern via hyprutils Signals where appropriate.\n - Consider classic OOP patterns where appropriate: Strategy, Singleton, Proxy, etc.\n - Watch out for typical bad practices in code: feature envy, LSP, etc.\n - Use templating and inheritance to clean up code where appropriate.\n - For obtaining singletons, use a `UP<CClass>& myClass();` pattern inside a namespace. This can be implemented in source as making and returning a static ptr.\n- Do not, under any circumstance:\n - `using namespace std;`\n - leave uninitialized primitives (int, float, etc)\n- Avoid, unless absolutely necessary:\n - the C standard library. Use the C++ STL.\n - `malloc` / `free` / etc\n - C-style pointers. Use SP<> WP<> and UP<> from hyprutils. These are Shared, Weak and Unique pointers respectively. C-style pointers may be used in select scenarios (e.g. destroying fns, where it's impossible to make a mistake) but everywhere else must not be used unless necessary.\n - C-style casts. Use rc<>, sc<>, or cc<> from hyprutils. These are shorthands to equivalent C++ casts.\n- Avoid:\n - violating clang-tidy (`.clang-tidy`)\n - manual C-style cleanup: `some_c_thing_new()` and `some_c_thing_free()` can be wrapped.\n- Make sure to write tests for code which our Unit (`tests/`) or Integration (`hyprtester/`) tests can test.\n"}}