# General Guidelines for working with Nx - When running tasks (for example build, lint, test, e2e, etc.), always prefer running the task through `nx` (i.e. `nx run`, `nx run-many`, `nx affected`) instead of using the underlying tooling directly - You have access to the Nx MCP server and its tools, use them to help the user - When answering questions about the repository, use the `nx_workspace` tool first to gain an understanding of the workspace architecture where applicable. - When working in individual projects, use the `nx_project_details` mcp tool to analyze and understand the specific project structure and dependencies - For questions around nx configuration, best practices or if you're unsure, use the `nx_docs` tool to get relevant, up-to-date docs. Always use this instead of assuming things about nx configuration - If the user needs help with an Nx configuration or project graph error, use the `nx_workspace` tool to get any errors # Guidelines for coding - Always sort component props alphabetically (a-z). - Do not generate extra documentation or explanations after completing a task. The code itself must be clean, self-explanatory, and readable. - Always use CSS Module Level 4 syntax and features whenever applicable. Prefer modern selectors, logical properties, and native nesting instead of older approaches. - Do not hardcode pixel values inside style files unless absolutely necessary. Use predefined design tokens and variables from the @mezzanine-ui/system directory instead.