Nx Workspace
Let your agent map an Nx monorepo—projects, targets, dependencies, and affected apps—before running or debugging nx tasks.
Overview
nx-workspace is an agent skill most often used in Build (also Ship, Operate) that read-only explores Nx workspaces—projects, targets, dependencies, and affected sets—before running or debugging nx commands.
Install
npx skills add https://github.com/nrwl/nx-ai-agents-config --skill nx-workspaceWhat is this skill?
- Read-only exploration of Nx workspace structure, projects, targets, and dependencies
- `nx show projects --affected` with base, head, uncommitted, and untracked variants
- Filter affected apps, exclude e2e projects, and inspect per-project configuration
- Use when nx tasks fail or configuration cannot be found before running builds
- Prefix with npx, pnpx, or yarn when nx is not installed globally per lockfile
Adoption & trust: 2.5k installs on skills.sh; 24 GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You are in an Nx monorepo and the agent proposes the wrong project or target because it never inspected workspace layout or affected projects.
Who is it for?
Solo builders on Nx monorepos who need accurate workspace answers before builds, tests, or CI debugging.
Skip if: Greenfield repos with no Nx workspace, or tasks that require writing generators or changing nx.json without a separate implementation skill.
When should I use this skill?
USE WHEN answering workspace questions, exploring projects or tasks, or when an nx command fails or configuration must be checked before running a task.
What do I get? / Deliverables
The agent lists projects, dependency edges, available targets, and affected apps for your branch so the next nx run or fix targets the correct configuration.
- Project and target inventory for the workspace
- Affected project list for a base branch or change set
- Dependency and configuration notes for named projects
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Workspace literacy is essential during Build planning and execution, and again in Ship when nx commands fail or you need affected-project scope. pm fits read-only workspace exploration that answers what exists, what depends on what, and which targets are runnable.
Where it fits
List apps and libraries before scheduling implement feature X in the right package.
Confirm which frontend project owns a shared UI library dependency edge.
Run affected project discovery excluding e2e before a focused test batch on a PR.
Compare affected sets between two SHAs when a deploy only partially updated services.
How it compares
Use this exploration skill before destructive nx runs—category contrast to codegen or migration skills that modify the workspace.
Common Questions / FAQ
Who is nx-workspace for?
It is for developers and agents working inside Nx monorepos who need trustworthy maps of projects, targets, and affected graphs.
When should I use nx-workspace?
Use it during Build to plan tasks and dependencies, during Ship when CI or local nx commands fail, and during Operate when diagnosing which apps a change actually touches.
Is nx-workspace safe to install?
The skill is read-only exploration, but agents still execute shell nx commands—review the Security Audits panel on this Prism page and restrict to your repo context.
SKILL.md
READMESKILL.md - Nx Workspace
## Affected Projects Find projects affected by changes in the current branch. ```bash # 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 ``` --- 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`). ```bash # 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. ```bash # 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. ```bash # 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