// Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately.
Migrate an Nx package to build to a local dist/ directory with nodenext module resolution, exports map, and @nx/nx-source condition.
Apply or review multi-version support compliance for first-party Nx plugins. Primary entry point: a Linear task ID (NXC-XXXX) from the "Multi-version supported across plugins" milestone — the task carries the resolved support window, findings, and "Needs human decision" items. Falls back to self-discovery when no task exists. Use when asked to "fix multi-version compliance for @nx/X", "do NXC-XXXX", "review this compliance PR", or when working on a branch / PR titled "multi-version support compliance for @nx/X". Covers the canonical shape (assertSupportedPackageVersion, all-generators-enforce-floor.spec.ts, peer dep alignment, requires-gate auditing, user-pin preservation, executor / inferred-plugin feature gating).
Run Nx generators with prioritization for workspace-plugin generators. Use this when generating code, scaffolding new features, or automating repetitive tasks in the monorepo.
Diagnose Nx sandbox violations from a sandbox report. Use when asked to "diagnose sandbox", "analyze sandbox report", "investigate sandbox violations", "check violations", when given a sandbox report JSON file or URL to investigate, or when the user pastes a staging.nx.app sandbox-report URL. Also trigger when discussing unexpected reads/writes in Nx task execution. Guides structured investigation of why tasks read/write undeclared files, determines root causes, and recommends fixes.
Bump the dev.nx.gradle.project-graph plugin version. Use when updating the Gradle project graph plugin version across the codebase, creating the migration files, and updating migrations.json.
Check modified Nx documentation pages against the astro-docs style guide. Auto-trigger after writing or editing docs content in the nx repo. Also trigger on "check style", "style guide", "docs review", "validate docs". Should run as a final step whenever docs files are modified. IMPORTANT: anytime astro-docs/**/*.mdoc files are modified, this should always run automatically without being asked.
| name | nx-generate |
| description | Generate code using nx generators. USE WHEN scaffolding code or transforming existing code - for example creating libraries or applications, or anything else that is boilerplate code or automates repetitive tasks. ALWAYS use this first when generating code with Nx instead of calling MCP tools or running nx generate immediately. |
Nx generators are powerful tools that scaffold projects, make automated code migrations or automate repetitive tasks in a monorepo. They ensure consistency across the codebase and reduce boilerplate work.
This skill applies when the user wants to:
Use the Nx CLI to discover available generators:
npx nx list @nx/reactnpx nx listThis includes:
@nx/react:library, @nx/js:library)Based on the user's request, identify which generator(s) could fulfill their needs. Consider:
IMPORTANT: When both a local workspace generator and an external plugin generator could satisfy the request, always prefer the local workspace generator. Local generators are customized for the specific repo's patterns and conventions.
It's possible that the user request is something that no Nx generator exists for whatsoever. In this case, you can stop using this skill and try to help the user another way. HOWEVER, the burden of proof for this is high. Before aborting, carefully consider each and every generator that's available. Look into details for any that could be related in any way before making this decision.
Before running any generator, complete these steps:
Use the --help flag to understand all available options:
npx nx g @nx/react:library --help
Pay attention to:
Understanding what the generator actually does helps you:
To find generator source code:
node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));" to find the generators.json, then locate the source from therenode_modules/<plugin>/generators.jsontools/generators/ or a local plugin directory. You can search the repo for the generator name to find it.Once you have built up an understanding of what the selected generator does, reconsider: Is this the right generator to service the user request? If not, it's okay to go back to the Generator Discovery Flow and select a different generator before proceeding. If you do, make sure to go through the entire pre-execution checklist once more.
Before generating, examine the target area of the codebase:
For example, if similar libraries are using a specific test runner, build tool or linter, try to match that if possible. If projects or other artifacts are organized with a specific naming convention, try to match it.
Ensure all required options have values:
Keep in mind that you might have to prefix things with npx/pnpx/yarn if the user doesn't have nx installed globally. Many generators will behave differently based on where they are executed. For example, first-party nx library generators use the cwd to determine the directory that the library should be placed in. This is highly important.
Running with --dry-run first is strongly encouraged but not mandatory. Use your judgment:
Execute the generator with:
nx generate <generator-name> <options> --no-interactive
CRITICAL: Always include --no-interactive to prevent prompts that would hang the execution.
Example:
nx generate @nx/react:library --name=my-utils --no-interactive
If the generator fails:
Common failure reasons:
Generators provide a starting point, but the output may need adjustment to match the user's specific requirements:
Run formatting on all generated/modified files:
nx format --fix
Languages other than javascript/typescript might need other formatting invocations too.
Verify that the generated code works correctly. What this looks like will vary depending on the type of generator and the targets available. If the generator created a new project, run its targets directly Use your best judgement to determine what needs to be verified.
Example:
nx lint <new-project>
nx test <new-project>
nx build <new-project>
When verification fails:
If scope is manageable (a few lint errors, minor type issues):
If issues are extensive (many errors, complex problems):
Local generators first - Always prefer workspace/local generators over external plugin generators when both could work
Understand before running - Read both the schema AND the source code to fully understand what will happen
No prompts - Always use --no-interactive to prevent hanging
Generators are starting points - Modify the output as needed to fully satisfy the user's requirements
Verify changes work - Don't just generate; ensure the code builds, lints, and tests pass
Be proactive about fixes - Don't just report errors; attempt to resolve them automatically when possible
Match repo patterns - Study existing similar code in the repo and match its conventions