Helper for inspecting Nx workspace structure, project targets, and dependencies.
Install
mkdir -p .claude/skills/nx-workspace && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/2614" && unzip -o skill.zip -d .claude/skills/nx-workspace && rm skill.zipInstalls to .claude/skills/nx-workspace
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Explore and understand Nx workspaces. USE WHEN answering any questions about the nx workspace, the projects in it or tasks to run. EXAMPLES: 'What projects are in this workspace?', 'How is project X configured?', 'What targets can I run?', 'What's affected by my changes?', 'Which projects depend on library Y?', or any questions about Nx workspace structure, project configuration, or available tasks.Key capabilities
- →List projects in workspace
- →Query resolved configuration for a project
- →Filter projects by target or type
- →Identify affected projects after changes
How it works
Uses internal nx command-line tools to extract the full resolved dependency graph and configuration.
Inputs & outputs
When to use nx-workspace
- →List all projects in the workspace
- →Check resolved configuration for a specific project
- →Identify projects affected by changes
- →Filter projects by type or target
About this skill
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.
# List all projects
nx show projects
# Filter by pattern (glob)
nx show projects --projects "apps/*"
nx show projects --projects "shared-*"
# Filter by project type
nx show projects --type app
nx show projects --type lib
nx show projects --type e2e
# Filter by target (projects that have a specific target)
nx show projects --withTarget build
nx show projects --withTarget e2e
# Find affected projects (changed since base branch)
nx show projects --affected
nx show projects --affected --base=main
nx show projects --affected --type app
# Combine filters
nx show projects --type lib --withTarget test
nx show projects --affected --exclude="*-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 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
Find projects affected by changes in the current branch.
# Affected since base branch (auto-detected)
nx show projects --affected
# Affected with explicit base
nx show projects --affected --base=main
nx show projects --affected --base=origin/main
# Affected between two commits
nx show projects --affected --base=abc123 --head=def456
# Affected apps only
nx show projects --affected --type app
# Affected excluding e2e projects
nx show projects --affected --exclude="*-e2e"
# Affected by uncommitted changes
nx show projects --affected --uncommitted
# Affected by untracked files
nx show projects --affected --untracked
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?"
# Find projects that may depend on Y by searching for imports
# (Nx doesn't have a direct "dependents" command via CLI)
grep -r "from '@myorg/Y'" --include="*.ts" --include="*.tsx" apps/ libs/
"What configuration options are available?"
cat node_modules/nx/schemas/nx-schema.json | jq '.properties | keys'
cat node_modules/nx/schemas/project-schema.json | jq '.properties | keys'
"Why is project X affected?"
# Check what files changed
git diff --name-only main
# See which project owns those files
nx show project X --json | jq '.root'
When not to use it
- →General non-Nx project structures
- →Direct manipulation of project.json files
- →Non-read-only configuration changes
Prerequisites
Limitations
- →Limited to workspace discovery
- →Does not directly edit source code
How it compares
It interacts with the workspace graph rather than manual file parsing.
Compared to similar skills
nx-workspace side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| nx-workspace (this skill) | 4 | 6mo | Review | Beginner |
| dependency-upgrade | 26 | 5mo | Review | Intermediate |
| upgrading-expo | 3 | 4mo | Review | Intermediate |
| ast-grep-find | 3 | 7mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by nrwl
View all by nrwl →You might also like
dependency-upgrade
wshobson
Manage major dependency version upgrades with compatibility analysis, staged rollout, and comprehensive testing. Use when upgrading framework versions, updating major dependencies, or managing breaking changes in libraries.
upgrading-expo
sickn33
Upgrade Expo SDK versions
ast-grep-find
parcadei
AST-based code search and refactoring via ast-grep MCP
pnpm
antfu
Node.js package manager with strict dependency resolution. Use when running pnpm specific commands, configuring workspaces, or managing dependencies with catalogs, patches, or overrides.
windsurf-linting-config
jeremylongshore
Configure and enforce code quality with AI-assisted linting. Activate when users mention "configure linting", "eslint setup", "code quality rules", "linting configuration", or "code standards". Handles linting tool configuration. Use when configuring systems or services. Trigger with phrases like "windsurf linting config", "windsurf config", "windsurf".
biome
TEN-framework
Enforce Biome formatting and lint discipline in this repository. Use when making any file edits, when asked to run format/lint, and immediately before any commit. Always execute `bun run lint` (from package.json), apply resulting fixes, and re-run until clean. Treat `bun run lint:links` as optional