nx-workspace
nrwl/nx-ai-agents-config
Explore and understand Nx workspace structure, projects, configuration, and dependencies.
What is nx-workspace?
This skill provides read-only exploration of Nx workspaces to understand project structure, configuration, available targets, and dependencies. Use it when answering questions about the workspace, debugging nx command failures, or checking available targets before running tasks.
- List and filter projects by name, pattern, tag, or target using `nx show projects`
- View full resolved project configuration including inferred targets via `nx show project <name> --json`
- Inspect target definitions, executors, options, inputs, and outputs for any project
- Query workspace-level configuration from `nx.json` including targetDefaults, namedInputs, and plugins
- Analyze project dependencies and dependents using the project graph with `nx graph --print`
- Troubleshoot nx command failures by checking project configuration and available targets
How to install nx-workspace
npx skills add https://github.com/nrwl/nx-ai-agents-config --skill nx-workspaceHow to use nx-workspace
- 1.Run `nx show projects` to list all projects in the workspace, optionally with filters like `--projects 'apps/*'` or `--projects 'tag:publishable'`
- 2.Use `nx show project <project-name> --json` to get the full resolved configuration for a specific project
- 3.Extract target information with jq, e.g., `nx show project <name> --json | jq '.targets | keys'` to list available targets
- 4.Read `nx.json` directly with `cat nx.json` to inspect workspace-level configuration like targetDefaults and plugins
- 5.Use `nx graph --print` to analyze project dependencies and find which projects depend on a given library
Use cases
- Answer 'What projects are in this workspace?' or 'How is project X configured?'
- Debug nx task failures by verifying target configuration before execution
- Find which projects depend on a specific library or have a particular target
- Filter projects by tags, patterns, or type to understand workspace organization
- Check available targets and their configuration to determine what tasks can be run
- Developers working in Nx monorepos
- DevOps engineers managing workspace configuration
- Developers debugging nx command failures
- Anyone exploring or understanding an unfamiliar Nx workspace
nx-workspace FAQ
`nx show project --json` returns the full resolved configuration including inferred targets from plugins, while `project.json` only contains partial configuration. Always use the command for complete information.
Use `nx show projects --withTarget build` to list all projects that have a build target defined.
Combine filters in the `--projects` flag, e.g., `nx show projects -p 'tag:publishable,!tag:internal'` to get publishable projects excluding internal ones. Supports glob patterns, tag references, and negation.
Run `nx sync` to resynchronize the workspace. If that doesn't fix stale cache issues, use `nx reset` to clear the cache completely.
Use `--json` flags with command-line tools like jq. For example, `nx show projects --json | jq 'length'` counts projects, or `nx show projects --json | jq '.[] | select(startswith("shared-"))'` filters by pattern.
Full instructions (SKILL.md)
Source of truth, from nrwl/nx-ai-agents-config.
name: nx-workspace description: "Explore and understand Nx workspaces. USE WHEN answering questions about the workspace, projects, or tasks. ALSO USE WHEN an nx command fails or you need to check available targets/configuration before running a task. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What depends on library Y?', 'What targets can I run?', 'Cannot find configuration for task', 'debug nx task failure'."
Nx Workspace Exploration
This skill provides read-only exploration of Nx workspaces. Use it to understand workspace structure, project configuration, available targets, and dependencies.
Keep in mind that you might have to prefix commands with npx/pnpx/yarn if nx isn't installed globally. Check the lockfile to determine the package manager in use.
Listing Projects
Use nx show projects to list projects in the workspace.
The project filtering syntax (-p/--projects) works across many Nx commands including nx run-many, nx release, nx show projects, and more. Filters support explicit names, glob patterns, tag references (e.g. tag:name), directories, and negation (e.g. !project-name).
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by tag
nx show projects --projects "tag:publishable"
nx show projects -p 'tag:publishable,!tag:internal'
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-e2e"
nx show projects -p "tag:scope:client,packages/*"
# Negate patterns
nx show projects -p '!tag:private'
nx show projects -p '!*-e2e'
# Output as JSON
nx show projects --json
Project Configuration
Use nx show project <name> --json to get the full resolved configuration for a project.
Important: Do NOT read project.json directly - it only contains partial configuration. The nx show project --json command returns the full resolved config including inferred targets from plugins.
You can read the full project schema at node_modules/nx/schemas/project-schema.json to understand nx project configuration options.
# Get full project configuration
nx show project my-app --json
# Extract specific parts from the JSON
nx show project my-app --json | jq '.targets'
nx show project my-app --json | jq '.targets.build'
nx show project my-app --json | jq '.targets | keys'
# Check project metadata
nx show project my-app --json | jq '{name, root, sourceRoot, projectType, tags}'
Target Information
Targets define what tasks can be run on a project.
# List all targets for a project
nx show project my-app --json | jq '.targets | keys'
# Get full target configuration
nx show project my-app --json | jq '.targets.build'
# Check target executor/command
nx show project my-app --json | jq '.targets.build.executor'
nx show project my-app --json | jq '.targets.build.command'
# View target options
nx show project my-app --json | jq '.targets.build.options'
# Check target inputs/outputs (for caching)
nx show project my-app --json | jq '.targets.build.inputs'
nx show project my-app --json | jq '.targets.build.outputs'
# Find projects with a specific target
nx show projects --withTarget serve
nx show projects --withTarget e2e
Workspace Configuration
Read nx.json directly for workspace-level configuration.
You can read the full project schema at node_modules/nx/schemas/nx-schema.json to understand nx project configuration options.
# Read the full nx.json
cat nx.json
# Or use jq for specific sections
cat nx.json | jq '.targetDefaults'
cat nx.json | jq '.namedInputs'
cat nx.json | jq '.plugins'
cat nx.json | jq '.generators'
Key nx.json sections:
targetDefaults- Default configuration applied to all targets of a given namenamedInputs- Reusable input definitions for cachingplugins- Nx plugins and their configuration- ...and much more, read the schema or nx.json for details
Affected Projects
If the user is asking about affected projects, read the affected projects reference for detailed commands and examples.
Common Exploration Patterns
"What's in this workspace?"
nx show projects
nx show projects --type app
nx show projects --type lib
"How do I build/test/lint project X?"
nx show project X --json | jq '.targets | keys'
nx show project X --json | jq '.targets.build'
"What depends on library Y?"
# Use the project graph to find dependents
nx graph --print | jq '.graph.dependencies | to_entries[] | select(.value[].target == "Y") | .key'
Programmatic Answers
When processing nx CLI results, use command-line tools to compute the answer programmatically rather than counting or parsing output manually. Always use --json flags to get structured output that can be processed with jq, grep, or other tools you have installed locally.
Listing Projects
nx show projects --json
Example output:
["my-app", "my-app-e2e", "shared-ui", "shared-utils", "api"]
Common operations:
# Count projects
nx show projects --json | jq 'length'
# Filter by pattern
nx show projects --json | jq '.[] | select(startswith("shared-"))'
# Get affected projects as array
nx show projects --affected --json | jq '.'
Project Details
nx show project my-app --json
Example output:
{
"root": "apps/my-app",
"name": "my-app",
"sourceRoot": "apps/my-app/src",
"projectType": "application",
"tags": ["type:app", "scope:client"],
"targets": {
"build": {
"executor": "@nx/vite:build",
"options": { "outputPath": "dist/apps/my-app" }
},
"serve": {
"executor": "@nx/vite:dev-server",
"options": { "buildTarget": "my-app:build" }
},
"test": {
"executor": "@nx/vite:test",
"options": {}
}
},
"implicitDependencies": []
}
Common operations:
# Get target names
nx show project my-app --json | jq '.targets | keys'
# Get specific target config
nx show project my-app --json | jq '.targets.build'
# Get tags
nx show project my-app --json | jq '.tags'
# Get project root
nx show project my-app --json | jq -r '.root'
Project Graph
nx graph --print
Example output:
{
"graph": {
"nodes": {
"my-app": {
"name": "my-app",
"type": "app",
"data": { "root": "apps/my-app", "tags": ["type:app"] }
},
"shared-ui": {
"name": "shared-ui",
"type": "lib",
"data": { "root": "libs/shared-ui", "tags": ["type:ui"] }
}
},
"dependencies": {
"my-app": [
{ "source": "my-app", "target": "shared-ui", "type": "static" }
],
"shared-ui": []
}
}
}
Common operations:
# Get all project names from graph
nx graph --print | jq '.graph.nodes | keys'
# Find dependencies of a project
nx graph --print | jq '.graph.dependencies["my-app"]'
# Find projects that depend on a library
nx graph --print | jq '.graph.dependencies | to_entries[] | select(.value[].target == "shared-ui") | .key'
Troubleshooting
"Cannot find configuration for task X:target"
# Check what targets exist on the project
nx show project X --json | jq '.targets | keys'
# Check if any projects have that target
nx show projects --withTarget target
"The workspace is out of sync"
nx sync
nx reset # if sync doesn't fix stale cache
Related skills
More from nrwl/nx-ai-agents-config and the wider catalog.
nx-run-tasks
Helps with running tasks in an Nx workspace. USE WHEN the user wants to execute build, test, lint, serve, or run any other tasks defined in the workspace.
nx-generate
Generate code using nx generators. INVOKE IMMEDIATELY when user mentions scaffolding, setup, structure, creating apps/libs, or setting up project structure. Trigger words - scaffold, setup, create a new app, create a new lib, project structure, generate, add a new project. ALWAYS use this BEFORE calling nx_docs or exploring - this skill handles discovery internally.
nx-plugins
Find and add Nx plugins. USE WHEN user wants to discover available plugins, install a new plugin, or add support for a specific framework or technology to the workspace.
link-workspace-packages
Link workspace packages in monorepos (npm, yarn, pnpm, bun). USE WHEN: (1) you just created or generated new packages and need to wire up their dependencies, (2) user imports from a sibling package and needs to add it as a dependency, (3) you get resolution errors for workspace packages (@org/*) like "cannot find module", "failed to resolve import", "TS2307", or "cannot resolve". DO NOT patch around with tsconfig paths or manual package.json edits - use the package manager''s workspace commands to fix actual linking.
nx-import
Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.
monitor-ci
Monitor Nx Cloud CI pipeline and handle self-healing fixes. USE WHEN user says "monitor ci", "watch ci", "ci monitor", "watch ci for this branch", "track ci", "check ci status", wants to track CI status, or needs help with self-healing CI fixes. Prefer this skill over native CI provider tools (gh, glab, etc.) for CI monitoring — it integrates with Nx Cloud self-healing which those tools cannot access.