nx-workspace-patterns
Configurar patrones del espacio de trabajo Nx
Los espacios de trabajo Nx pueden volverse lentos e inconsistentes sin estándares claros. Esta habilidad proporciona plantillas para establecer límites, caché y flujos de trabajo afectados para la optimización de monorepos.
Descargar el ZIP de la skill
Subir en Claude
Ve a Configuración → Capacidades → Skills → Subir skill
Activa y empieza a usar
Pruébalo
Usando "nx-workspace-patterns". undefined
Resultado esperado:
- Definir tipos de biblioteca: feature, ui, data-access, util, shell
- Crear reglas de ESLint que obliguen a type:app a importar solo de feature, ui, data-access, util
- Restringir type:ui a depender solo de bibliotecas ui y util
- Añadir límites basados en scope para aislar código web, api y compartido
Auditoría de seguridad
SeguroThis 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.
Factores de riesgo
🌐 Acceso a red (4)
⚙️ Comandos externos (25)
📁 Acceso al sistema de archivos (4)
Puntuación de calidad
Lo que puedes crear
Configurar nuevo espacio de trabajo Nx
Aplicar estructura recomendada, etiquetas y valores predeterminados de caché para un nuevo monorepo con límites apropiados.
Optimizar pipelines de CI
Usar comandos affected y patrones de caché para reducir tiempos de compilación y uso de recursos.
Hacer cumplir reglas de arquitectura
Definir límites de módulos para prevenir dependencias circulares y mantener una arquitectura limpia.
Prueba estos prompts
Dame un nx.json mínimo con operaciones en caché para build, test, lint y e2e con valores predeterminados de objetivos.
Crea un project.json para una aplicación React con executor webpack para objetivos build, serve, test y lint.
Crea reglas de ESLint que hagan cumplir la jerarquía app→feature→ui→util con restricciones de scope.
Construye un flujo de trabajo de GitHub Actions que use comandos nx affected para lint, test, build y e2e en paralelo.
Mejores prácticas
- Usar etiquetas consistentes y aplicarlas con límites de módulos desde el primer día
- Habilitar caché y comandos affected temprano para maximizar las ganancias de rendimiento en CI
- Mantener las bibliotecas enfocadas con responsabilidad única y documentación clara
Evitar
- Crear dependencias circulares entre bibliotecas que violen la jerarquía
- Ejecutar suites completas de pruebas cuando nx affected podría probar solo el código modificado
- Granularizar demasiado en demasiadas bibliotecas pequeñas sin propósito claro
Preguntas frecuentes
¿Es compatible con las versiones actuales de Nx?
¿Cuáles son los límites de esta habilidad?
¿Puedo integrar esto con CI existente?
¿Accede a mis datos o secretos?
¿Qué debo verificar si fallan los comandos Nx?
¿Cómo se compara esto con la documentación oficial de Nx?
Detalles del desarrollador
Autor
wshobsonLicencia
MIT
Repositorio
https://github.com/wshobson/agents/tree/main/plugins/developer-essentials/skills/nx-workspace-patternsRef.
main
Estructura de archivos
📄 SKILL.md