Fetches nx-workspace from nrwl/nx-ai-agents-config and configures it for Cursor.
3
Select Cursor when prompted
The CLI shows a list of agents. Use arrow keys and space to select Cursor:
◆ Which agents do you want to install to?
│
│ ── Universal (.agents/skills) ────────────────
│ · Cline · Codex · Goose · Windsurf
│ ●Cursor(selected)
│ · Cursor · Aider · Continue
4
Verify installation
Confirm successful installation by checking the skill directory location:
.cursor/skills/nx-workspace
Restart Cursor to activate nx-workspace. Access via /nx-workspace in your agent's command palette.
⚠
Security Notice
We perform automated surface-level scans (Gen AI Scanner, Socket, Snyk) during installation. These checks detect common vulnerabilities but do not guarantee complete security. Always review skill source code and verify the publisher's reputation before production use.
Skills execute code in your environment. Always review source, verify the publisher, and test in isolation before production.
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 projectsnx show projects
# Filter by pattern (glob)nx show projects --projects"apps/*"nx show projects --projects"shared-*"# Filter by tagnx 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 filtersnx show projects --type lib --withTargettestnx show projects --affected--exclude="*-e2e"nx show projects -p"tag:scope:client,packages/*"# Negate patternsnx show projects -p'!tag:private'nx show projects -p'!*-e2e'# Output as JSONnx 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 configurationnx show project my-app --json# Extract specific parts from the JSONnx 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 metadatanx 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 projectnx show project my-app --json| jq '.targets | keys'# Get full target configurationnx show project my-app --json| jq '.targets.build'# Check target executor/commandnx show project my-app --json| jq '.targets.build.executor'nx show project my-app --json| jq '.targets.build.command'# View target optionsnx 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 targetnx 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.jsoncat nx.json
# Or use jq for specific sectionscat 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 name
namedInputs - Reusable input definitions for caching
plugins - 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 dependentsnx 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.
# Count projectsnx show projects --json| jq 'length'# Filter by patternnx show projects --json| jq '.[] | select(startswith("shared-"))'# Get affected projects as arraynx show projects --affected--json| jq '.'
# Get target namesnx show project my-app --json| jq '.targets | keys'# Get specific target confignx show project my-app --json| jq '.targets.build'# Get tagsnx show project my-app --json| jq '.tags'# Get project rootnx show project my-app --json| jq -r'.root'
›Access to product documentation and roadmap tools (Jira, Notion, etc.)
›Understanding of product management frameworks (RICE, Jobs-to-be-Done, etc.)
›Stakeholder contact information and communication channels
Time Estimate
30-60 minutes to see productivity improvements
Steps
1Install product management skill
2Start with user story generation for known feature
3Progress to competitive analysis: research 2-3 competitors
4Use for roadmap prioritization: apply RICE/ICE scoring
5Draft stakeholder communications and refine based on feedback
6Build template library for recurring PM tasks
7Share effective prompts with product team
Common Pitfalls
⚠Not validating competitive research—verify facts before sharing
⚠Accepting user stories without involving engineering team
⚠Over-relying on frameworks without qualitative judgment
⚠Not customizing outputs to company culture and communication style
⚠Skipping stakeholder validation of generated requirements
Best Practices
✓ Do
+Validate research and competitive analysis with real data
+Collaborate with engineering when generating technical requirements
+Customize frameworks and templates to your company context
+Use skill for first drafts, refine with stakeholder input
+Document successful prompt patterns for PM tasks
+Combine AI efficiency with human judgment and intuition
✗ Don't
−Don't publish competitive analysis without fact-checking
−Don't finalize user stories without engineering review
−Don't make prioritization decisions solely on AI scoring
−Don't skip customer validation of generated requirements
−Don't ignore company-specific context and culture
💡 Pro Tips
★Provide context: company goals, constraints, customer feedback
★Ask for alternatives: 'Show 3 ways to prioritize this roadmap'
★Request stakeholder-specific formatting: 'Executive summary vs. engineering spec'
★Use skill for 70% generation + 30% customization to company needs
When to Use This
✓ Use when
Use for user story writing, competitive research, roadmap prioritization, stakeholder communication, and PRD drafting. Best for reducing repetitive documentation and research work.
✗ Avoid when
Avoid for strategic product vision (requires deep customer empathy), pricing decisions (needs market and financial expertise), or when face-to-face customer discovery is more valuable than speed.
Learning Path
1Basic: user stories, feature specs, status updates
