General Guidelines for working with Nx

For navigating/exploring the workspace, invoke the nx-workspace skill first - it has patterns for querying projects, targets, and dependencies
For upgrading the Nx workspace version, invoke the nx-migrate-workspace skill - nx migrate one major at a time; after migrations finish, update backwards-compat CI, basic-test/e2e Node matrices, .nvmrc, root @types/node (major aligned with .nvmrc), and main required status checks for .nvmrc Node from the version in package.json
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
Prefix nx commands with the workspace's package manager (e.g., pnpm nx build, npm exec nx test) - avoids using globally installed CLI
You have access to the Nx MCP server and its tools, use them to help the user
For Nx plugin best practices, check node_modules/@nx/<plugin>/PLUGIN.md. Not all plugins have this file - proceed without it if unavailable.
NEVER guess CLI flags - always check nx_docs or --help first when unsure

Scaffolding & Generators

For scaffolding tasks (creating apps, libs, project structure, setup), ALWAYS invoke the nx-generate skill FIRST before exploring or calling MCP tools

USE for: advanced config options, unfamiliar flags, migration guides, plugin configuration, edge cases
DON'T USE for: basic generator syntax (nx g @nx/react:app), standard commands, things you already know
The nx-generate skill handles generator discovery internally - don't call nx_docs just to look up generator syntax

When creating or editing *.spec.ts / *.smoke.spec.ts files, follow .cursor/rules/tests-sifers.mdc:

Every test starts with one setup() call; setup returns all mocks/spies.
Never jest.spyOn / mock wiring inside it() or test() blocks.
Never beforeEach + outer let for per-test state.
Copy patterns from engine.spec.ts, generator.spec.ts, or write-dist-folder-path-on-deploy-target-options.spec.ts.