{"owner":"HMCL-dev","repo":"HMCL","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md"],"skills":{"AGENTS.md":"# Java Code Style Requirements\n\nThese rules apply to all Java code written or modified in this repository.\n\n## Nullability\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class declared in a newly added Java source file must be annotated with JetBrains Annotations `@NotNullByDefault`.\n- When writing or modifying Java code, any type, field, parameter, return value, local variable, or generic type argument that may be `null` must be explicitly annotated with `@Nullable`.\n- Nullability in code being written or modified must never be implicit.\n\n## Immutability\n\n- Immutable arrays and collections must be explicitly annotated with JetBrains Annotations `@Unmodifiable` or `@UnmodifiableView` as appropriate.\n- For arrays, use type-use syntax such as `String @Unmodifiable []`.\n\n## Documentation\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class, field, and method must have documentation.\n- Documentation must use `///` Markdown-style Javadoc comments.\n- Keep documentation accurate and specific to the actual behavior, constraints, and side effects.\n- Add concise implementation comments inside complex logic whenever they materially improve readability or explain non-obvious behavior.\n"},"files":{"AGENTS.md":"# Java Code Style Requirements\n\nThese rules apply to all Java code written or modified in this repository.\n\n## Nullability\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class declared in a newly added Java source file must be annotated with JetBrains Annotations `@NotNullByDefault`.\n- When writing or modifying Java code, any type, field, parameter, return value, local variable, or generic type argument that may be `null` must be explicitly annotated with `@Nullable`.\n- Nullability in code being written or modified must never be implicit.\n\n## Immutability\n\n- Immutable arrays and collections must be explicitly annotated with JetBrains Annotations `@Unmodifiable` or `@UnmodifiableView` as appropriate.\n- For arrays, use type-use syntax such as `String @Unmodifiable []`.\n\n## Documentation\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class, field, and method must have documentation.\n- Documentation must use `///` Markdown-style Javadoc comments.\n- Keep documentation accurate and specific to the actual behavior, constraints, and side effects.\n- Add concise implementation comments inside complex logic whenever they materially improve readability or explain non-obvious behavior.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"# Java Code Style Requirements\n\nThese rules apply to all Java code written or modified in this repository.\n\n## Nullability\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class declared in a newly added Java source file must be annotated with JetBrains Annotations `@NotNullByDefault`.\n- When writing or modifying Java code, any type, field, parameter, return value, local variable, or generic type argument that may be `null` must be explicitly annotated with `@Nullable`.\n- Nullability in code being written or modified must never be implicit.\n\n## Immutability\n\n- Immutable arrays and collections must be explicitly annotated with JetBrains Annotations `@Unmodifiable` or `@UnmodifiableView` as appropriate.\n- For arrays, use type-use syntax such as `String @Unmodifiable []`.\n\n## Documentation\n\nApply the following requirements when writing or modifying code. Do not use them as code-review criteria.\n\n- Every class, field, and method must have documentation.\n- Documentation must use `///` Markdown-style Javadoc comments.\n- Keep documentation accurate and specific to the actual behavior, constraints, and side effects.\n- Add concise implementation comments inside complex logic whenever they materially improve readability or explain non-obvious behavior.\n","category":"root","tokens":333}]}