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'.
npx skills add https://github.com/supabase/supabase-js --skill nx-workspace
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.
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
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}'
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
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 configurationIf the user is asking about affected projects, read the affected projects reference for detailed commands and examples.
nx show projects
nx show projects --type app
nx show projects --type lib
nx show project X --json | jq '.targets | keys'
nx show project X --json | jq '.targets.build'
# Use the project graph to find dependents
nx graph --print | jq '.graph.dependencies | to_entries[] | select(.value[].target == "Y") | .key'
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.
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 '.'
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'
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'
# 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
nx sync
nx reset # if sync doesn't fix stale cache
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
Automatically creates user-facing changelogs from git commits by analyzing commit history, categorizing changes, and transforming technical commits into clear, customer-friendly release notes. Turns hours of manual changelog writing into minutes of automated generation.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Guide for creating high-quality MCP (Model Context Protocol) servers that enable LLMs to interact with external services through well-designed tools. Use when building MCP servers to integrate external APIs or services, whether in Python (FastMCP) or Node/TypeScript (MCP SDK).
React Native and Expo best practices for building performant mobile apps. Use when building React Native components, optimizing list performance, implementing animations, or working with native modules. Triggers on tasks involving React Native, Expo, mobile performance, or native platform APIs.
React and Next.js performance optimization guidelines from Vercel Engineering. This skill should be used when writing, reviewing, or refactoring React/Next.js code to ensure optimal performance patterns. Triggers on tasks involving React components, Next.js pages, data fetching, bundle optimization, or performance improvements.
Next.js best practices - file conventions, RSC boundaries, data patterns, async APIs, metadata, error handling, route handlers, image/font optimization, bundling
Use when starting feature work that needs isolation from current workspace or before executing implementation plans - creates isolated git worktrees with smart directory selection and safety verification
Take supabase/nx-workspace from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.