{"owner":"mantinedev","repo":"mantine","hasSkills":true,"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md"],"skills":{"AGENTS.md":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n","CLAUDE.md":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n"},"files":{"AGENTS.md":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n","CLAUDE.md":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","title":"AGENTS.md","content":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n","category":"root","tokens":538},{"name":"CLAUDE.md","path":"CLAUDE.md","title":"CLAUDE.md","content":"## Links\n\n## Finalizing Your Work\n\nChoose these commands to run after finalizing your work:\n\n```bash\n# Always run these commands before finalizing your work\nnpm run typecheck\nnpx oxlint -c oxlint.config.mjs path/to/changed/files\nnpm run format:write:files path/to/changed/files\nnpm run build\n\n# Run tests for specific path related to your changes\nnpm run jest @mantine/charts\nnpm run jest path/to/changed/file.test.ts\n\n# Run stylelint only if you have made changes to styles or CSS files\nnpm run stylelint\n\n# Run this script if you've changed dependencies in any package.json\nnpm run syncpack\n```\n\nAfter running the commands above, check if `codex` CLI is available (`command -v codex`). If it is, run `/codex-code-review` to get an automated code review of unstaged changes and apply fixes.\n\n## Code Style\n\n**Comments Guidelines:**\n- **Do not include inline comments** that describe logic or implementation details unless explicitly requested\n- **Always preserve documentation comments** on interfaces, types, and function parameters (JSDoc-style comments with `/** */`)\n- The codebase prefers clean, self-documenting code for implementation\n- Type definitions and public APIs should maintain their documentation comments\n\n## Commit conventions\n\nMantine is a monorepo, thus it is important to write correct commit messages to keep the git history clean and consistent. All commits made in this repository are divided into 3 groups:\n\n- package commits – Related to any particular package.\n- docs commits – Related to the documentation.\n- core commits – Only related to repository tooling and not associated with any package.\n\nCommit messages consists of 3 parts:\n```\n[area] Optional title: Message\n```\n\nExamples:\n- `[core] Fix documentation deployment script` – Change made in repository script, it is not related to documentation or any package\n- `[mantine.dev] Update report issues link` – Change related to documentation website\n- `[@mantine/core] Button: Add theme focus styles` – Change in @mantine/core package at Button component\n- `[@mantine/hooks] use-list-state: Add remove handler` – Change in @mantine/hooks package at use-list-state hook\n","category":"root","tokens":538}]}