nx-workspace
Skill18 starsChanged 6 months agoMITView on GitHub
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'.
18 other projects use a version of this, 15 of them edited.
Adopted by
Most recently taken up by
- getlarge/themoltnetedited, first seen Nov 3, 2026
- code-dimension/code-dimension-skillsedited, first seen Oct 17, 2026
- daveyplate/better-auth-uiedited, first seen Oct 9, 2026
- nrwl/nx-consoleedited, first seen Oct 8, 2026
- ever-co/ever-teamsedited, first seen Oct 8, 2026
- dotCMS/coreedited, first seen Oct 8, 2026
Other versions18 projects use a version of this.
Word for word · 2
- supabase/supabase-js★ 4.6k100% same
- anayatkhan1/kit★ 16100% same
Edited · 15
- nrwl/nx★ 29k100% same
- tsparticles/tsparticles★ 9.1k100% same
- better-auth-ui/better-auth-ui★ 1.7k100% same
- daveyplate/better-auth-ui★ 1.7k100% same
- nrwl/nx-console★ 1.4k100% same
- dotCMS/core★ 971100% same
- ever-co/ever-teams★ 606100% same
- epam/ai-dial-chat★ 501100% same
- getlarge/themoltnet★ 2895% same
- langchain-ai/macaw-design-system★ 12100% same
5 more not listed
Wrote their own version · 1
- jander99/skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository55 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- ai-cost-manager-reducerSkill
- api-contract-reviewerSkill
- apps-language-rulesSkill
- cli-developerSkill
- contract-dto-consistency-reviewerSkill
- database-schema-reviewerSkill
- deep-code-reviewerSkill
- docs-managerSkill
- docs-publication-managerSkill
- feature-slice-designerSkill
- github-issue-solverSkill
- grasp-ooad-reviewSkill
- language-integratorSkill
- link-workspace-packagesSkill
- mcp-managerSkill
- migration-risk-reviewerSkill
- mobile-app-designerSkill
- mobile-app-integratorSkill
- mobile-app-product-ownerSkill
- mobile-app-reviewerSkill
- mobile-language-checkerSkill
- mobile-rulesetSkill
- mobil-ui-ux-rulesetSkill
- monitor-ciSkill
- nx-generateSkill
- nx-importSkill
- nx-pluginsSkill
- nx-run-tasksSkill
- nx-workspaceSkill
- product-owner-deciderSkill
- react-native-performance-reviewerSkill
- react-vite-performance-reviewerSkill
- release-readiness-reviewerSkill
- repo-architecture-auditorSkill
- repo-performance-guardSkill
- repository-pattern-reviewerSkill
- security-reviewerSkill
- smart-commitSkill
- supabase-api-rpc-reviewerSkill
- supabase-index-trigger-reviewerSkill
- supabase-rls-security-reviewerSkill
- supabase-schema-reviewerSkill
- tailwind-ui-ux-reviewerSkill
- ui-contract-guardSkill
- test-managerSkill
- unit-test-plannerSkill
- vite-performance-engineerSkill
- link-workspace-packagesSkill
- monitor-ciSkill
- nx-generateSkill
- nx-importSkill
- nx-pluginsSkill
- nx-run-tasksSkill
The file
We split this skill into the rules it gives an agent
7 rules. 2 are common, 0 are distinctive, and 5 are very specific to this project.
2
Common
Most of the 16 edited versions we read keep these.
0
Distinctive
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Keep in mind that you might have to prefix commands with npx/pnpx/yarn if nx isn't installed globally.
- Very specific: line 14
Use nx show projects to list projects in the workspace.
- Very specific: line 48
Use nx show project <name> --json to get the full resolved configuration for a project.
- Very specific: line 50
Important: Do NOT read project.json directly - it only contains partial configuration.
- Very specific: line 96
Read nx.json directly for workspace-level configuration.
- Common: line 119
If the user is asking about affected projects, read the affected projects reference for detailed commands and examples.
- Common: line 147
When processing nx CLI results, use command-line tools to compute the answer programmatically rather than counting or parsing output …
“Common” is measured: kept by at least 6 in 10 of the 16 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
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 --jsonProject 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 e2eWorkspace 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 --jsonExample 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 --jsonExample 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 --printExample 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 cacheDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

