nx-workspace-patterns
Configure Nx workspace patterns
Nx workspaces can become slow and inconsistent without clear standards. This skill provides templates to set boundaries, caching, and affected workflows for monorepo optimization.
Download the skill ZIP
Upload in Claude
Go to Settings → Capabilities → Skills → Upload skill
Toggle on and start using
Test it
Using "nx-workspace-patterns". I need to set up module boundaries for my Nx monorepo
Expected outcome:
- Define library types: feature, ui, data-access, util, shell
- Create ESLint rules enforcing type:app can only import from feature, ui, data-access, util
- Restrict type:ui to only depend on ui and util libraries
- Add scope-based boundaries to isolate web, api, and shared code
Security Audit
SafeThis skill contains only static documentation and configuration templates for Nx workspaces. All 41 static findings are false positives: network URLs are legitimate metadata/doc links, external commands are example bash commands in documentation code blocks, path traversal sequences are standard relative paths in JSON config examples, and cryptographic alerts are misidentified schema file paths. The skill has no executable code, no file operations, no data handling, and no network access capability.
Risk Factors
🌐 Network access (4)
⚙️ External commands (25)
📁 Filesystem access (4)
Quality Score
What You Can Build
Set up new Nx workspace
Apply recommended structure, tags, and caching defaults for a new monorepo with proper boundaries.
Optimize CI pipelines
Use affected commands and caching patterns to reduce build times and resource usage.
Enforce architecture rules
Define module boundaries to prevent circular dependencies and maintain clean architecture.
Try These Prompts
Give me a minimal nx.json with cacheable operations for build, test, lint, and e2e with target defaults.
Create a project.json for a React app with webpack executor for build, serve, test, and lint targets.
Create ESLint rules that enforce app→feature→ui→util dependency hierarchy with scope restrictions.
Build a GitHub Actions workflow that uses nx affected commands for lint, test, build, and e2e in parallel.
Best Practices
- Use consistent tags and enforce them with module boundaries from day one
- Enable caching and affected commands early to maximize CI performance gains
- Keep libraries focused with single responsibility and clear documentation
Avoid
- Creating circular dependencies between libraries that violate the hierarchy
- Running full test suites when nx affected could test only changed code
- Over-granularizing into too many tiny libraries without clear purpose