@saulwade/swl-ses 1.0.0

package/habilidades/build-errors-go/SKILL.md

@@ -0,0 +1,306 @@
+---
+name: build-errors-go
+description: >
+  Resolución de errores de compilación Go: go build, go vet, go mod, import
+  cycles, cgo, race conditions y linters estáticos. Cargar cuando un build Go
+  falle o haya errores de compilación, módulos o vet.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep]
+exclusiones:
+  - "No cargar para errores de lógica o comportamiento del programa Go en ejecución — si `go build` pasa pero el programa produce resultados incorrectos, es un bug de lógica; no es un error de compilación."
+  - "No cargar para errores de pruebas que fallan por assertions incorrectas (testify, gomock) — si `go test` compila pero los tests fallan por valores incorrectos, eso es un error de lógica de tests, no de build."
+  - "No cargar para diseñar la arquitectura de módulos Go o decidir la estructura de packages — si la pregunta es cómo organizar los paquetes del proyecto, cargar `go-patrones` o `go-experto`."
+  - "No cargar cuando el error es exclusivo de cgo y el proyecto embebe C — los errores de cgo tienen dependencias del compilador C y son un dominio separado que requiere conocimiento de C además de Go."
+evolvable: true  # default para skill estandar
+---
+# Build Errors Go — Diagnóstico y Solución
+
+Go es estricto en tiempo de compilación: variables no usadas, imports no usados
+y type mismatches son errores, no warnings. Este skill cubre los errores más
+frecuentes del compilador, del sistema de módulos y de las herramientas de
+análisis estático.
+
+## Cuándo NO cargar
+
+- `go build` compila pero el programa falla en ejecución — no es un error de build; diagnosticar con `-race` o logs.
+- Los tests fallan por valores incorrectos (assertion failure) aunque compilan — es un error de lógica, no de compilación.
+- La pregunta es cómo estructurar paquetes o módulos Go — para diseño de paquetes cargar `go-patrones`.
+
+## Cuándo cargar este skill
+
+Invoca `Skill("build-errors-go")` cuando:
+
+- `go build` o `go test` falle con errores de compilación
+- `go vet` reporte problemas
+- Haya errores de `go mod` (módulos, versiones, replace)
+- Se detecten import cycles
+- `go build -race` detecte race conditions
+- Linters como `staticcheck` o `golangci-lint` fallen en CI
+
+## Conceptos clave
+
+### Errores vs Warnings en Go
+
+Go no tiene warnings — todo es un error que impide la compilación. Un import
+sin usar o una variable declarada sin usar genera un error de compilación.
+Esto es intencional: mantiene el código limpio por construcción.
+
+### Go Modules (go.mod)
+
+Cada módulo tiene un `go.mod` que declara el module path y las dependencias.
+`go.sum` contiene los checksums criptográficos de cada dependencia. Ambos
+se versionan en git. Las dependencias se cachean en `$GOPATH/pkg/mod`.
+
+### Build Constraints
+
+Los build constraints (`//go:build linux`) condicionan la compilación por OS,
+arquitectura u otras condiciones. Un archivo `.go` que no cumple los constraints
+del ambiente actual se ignora completamente, lo que puede causar errores de
+"undefined" si la implementación está en el archivo excluido.
+
+## Errores de go build — causa y solución
+
+### `undefined: NombreFuncion` o `undefined: paquete.Tipo`
+
+**Causa 1**: La función/tipo no está en el paquete importado.
+```bash
+# Verificar que existe en la version del modulo que se usa
+go doc paquete.Funcion
+```
+
+**Causa 2**: La función está en un archivo con build constraint excluido.
+```bash
+# Ver que archivos se incluyen en el build actual
+go list -f '{{.GoFiles}}' ./paquete/
+go list -f '{{.IgnoredGoFiles}}' ./paquete/
+```
+
+**Causa 3**: Import cycle impide que el paquete compile.
+```bash
+go build ./... 2>&1 | grep "import cycle"
+```
+
+### `declared but not used` (variable sin usar)
+
+```go
+// MAL — Go no compila con variables sin usar
+func calcular() int {
+    resultado := 42  // ERROR si no se usa
+    return 0
+}
+
+// BIEN — usar la variable o usar _ si el valor no importa
+func calcular() (int, error) {
+    resultado, err := operacionConError()
+    if err != nil {
+        return 0, err
+    }
+    return resultado, nil
+}
+
+// Para ignorar un valor de retorno explícitamente:
+_, err := operacion()
+```
+
+### `imported and not used: "paquete"`
+
+```go
+// MAL — import que Go no acepta si no se usa
+import (
+    "fmt"
+    "os"   // ERROR si no se llama ningún símbolo de "os"
+)
+
+// BIEN — remover el import no usado
+// O usar goimports para limpiar automáticamente:
+// goimports -w archivo.go
+```
+
+### `cannot use X (type T1) as type T2`
+
+```go
+// Causa común: tipos nombrados no son intercambiables aunque tengan el mismo tipo base
+type MetrosCuadrados float64
+type Kilogramos float64
+
+var area MetrosCuadrados = 10.0
+var peso Kilogramos = area  // ERROR: tipos distintos aunque ambos son float64
+
+// Solución: conversión explícita
+var peso Kilogramos = Kilogramos(area) // solo si la conversión tiene sentido semántico
+```
+
+### Import cycle — `import cycle not allowed`
+
+**Causa**: Paquete A importa B, B importa A (directamente o transitivamente).
+
+**Diagnóstico**:
+```bash
+go build ./... 2>&1
+# Output: package miapp/pkgA: import cycle not allowed
+# miapp/pkgA -> miapp/pkgB -> miapp/pkgA
+```
+
+**Soluciones en orden de preferencia**:
+1. Extraer los tipos compartidos a un tercer paquete que ninguno de los dos importa
+2. Usar una interface en lugar de un tipo concreto para romper el ciclo
+3. Reestructurar los paquetes para eliminar la dependencia circular
+
+```
+# Estructura que crea ciclo:
+pkgA imports pkgB
+pkgB imports pkgA
+
+# Solucion: extraer tipos compartidos
+pkgTypes (tipos compartidos, no importa a nadie)
+pkgA imports pkgTypes
+pkgB imports pkgTypes
+```
+
+## Errores de go mod — causa y solución
+
+### `no required module provides package X`
+
+```bash
+# Agregar el modulo faltante
+go get github.com/paquete/necesitado@v1.2.3
+
+# O si es un subpaquete, agregar el modulo raiz
+go get github.com/paquete/raiz
+```
+
+### `ambiguous import: found package X in multiple modules`
+
+**Causa**: Dos módulos exponen el mismo import path. Ocurre en fork/rename.
+
+```bash
+# Identificar cuáles módulos proveen el path
+go mod why github.com/path/en/conflicto
+```
+
+**Solución con replace en go.mod**:
+```
+replace github.com/paquete/original => github.com/fork/alternativo v1.0.0
+```
+
+### `go: updates to go.sum needed; to update it: go mod tidy`
+
+```bash
+# Regenerar go.sum para que coincida con go.mod
+go mod tidy
+
+# Si hay errores de checksum:
+go clean -modcache
+go mod download
+```
+
+### `verifying X: checksum mismatch`
+
+**Causa**: El checksum en `go.sum` no coincide con lo descargado. Posible
+modificación del módulo upstream o corrupción de cache.
+
+```bash
+# Limpiar cache y re-descargar
+go clean -modcache
+GONOSUMCHECK=* go mod download   # solo para diagnostico, no en produccion
+go mod verify
+```
+
+## Errores de go vet — causa y solución
+
+### `printf: format %s has arg X of wrong type`
+
+```go
+// MAL — tipo incorrecto para el formato
+var n int = 42
+fmt.Printf("%s", n)  // vet error: %s espera string, se paso int
+
+// BIEN
+fmt.Printf("%d", n)
+```
+
+### `copylocks: X passes lock by value`
+
+```go
+// MAL — Mutex no debe pasarse por valor (se copia el estado)
+type MiStruct struct {
+    mu sync.Mutex
+}
+
+func procesar(s MiStruct) { ... }       // ERROR: copia el Mutex
+
+// BIEN — pasar por puntero
+func procesar(s *MiStruct) { ... }
+```
+
+## Race conditions — `go build -race`
+
+```bash
+# Compilar y ejecutar con detector de race conditions
+go test -race ./...
+go run -race main.go
+```
+
+**Patrón común detectado**:
+```go
+// MAL — acceso concurrente sin sincronización
+var contador int
+go func() { contador++ }()
+go func() { contador++ }()
+// DATA RACE: dos goroutines escriben contador sin mutex
+
+// BIEN — usar sync.Mutex o atomic
+var mu sync.Mutex
+go func() { mu.Lock(); contador++; mu.Unlock() }()
+// O mejor con sync/atomic:
+var contador int64
+go func() { atomic.AddInt64(&contador, 1) }()
+```
+
+## Errores de staticcheck comunes
+
+### `SA1006: Printf with dynamic first argument and no further arguments`
+
+```go
+msg := "hola mundo"
+fmt.Printf(msg)       // staticcheck SA1006: posible format injection
+fmt.Printf("%s", msg) // BIEN
+fmt.Print(msg)        // O usar Print si no hay formato
+```
+
+### `S1039: Unnecessary use of fmt.Sprintf`
+
+```go
+// MAL — Sprintf innecesario
+nombre := fmt.Sprintf("Juan")    // staticcheck S1039
+
+// BIEN
+nombre := "Juan"
+```
+
+## Gotchas / Errores comunes no obvios
+
+- **`go mod tidy` genera un `go.sum` distinto en CI aunque no hubo cambios de dependencias**: la versión de Go difiere entre el entorno local y CI, ya que módulos directos y sus dependencias pueden resolverse con versiones de Go diferentes. Causa: Go embebe la versión mínima de Go en go.mod con `go 1.21`, y `go mod tidy` con una versión distinta puede agregar o quitar entradas del `go.sum`. Solución: fijar la versión de Go exacta en CI usando la misma que en `go.mod` (`go 1.21.x`).
+- **`go build -race` reporta DATA RACE solo en CI, no localmente**: el detector de race conditions es no-determinista y depende del scheduling del OS. Causa: la ventana de concurrencia es demasiado pequeña para reproducirse con la carga de trabajo del laptop pero se manifiesta bajo la carga de CI. Solución: ejecutar el test con `-race -count=10` para aumentar la probabilidad de detección local; una vez detectado, el report de `go build -race` muestra exactamente las goroutines y líneas en conflicto.
+- **Import cycle introducido por agregar un interface en el paquete A para que B no importe A directamente**: mover la interface al paquete "receptor" (A) no rompe el ciclo si B igual importa A para instanciar el tipo concreto. Causa: la interface en A solo mueve el punto de importación pero no elimina la dependencia si B sigue necesitando un tipo concreto de A. Solución: extraer la interface a un tercer paquete `pkgTypes` que ni A ni B importan entre sí, y que ambos referencian.
+- **`staticcheck` SA4006 reporta variable asignada pero nunca usada en la línea del error handler**: el patrón `if err != nil { log.Error(err); return }` hace que la variable `err` de la siguiente asignación sea considerada "sobrescrita sin leer". Causa: el analyzer cuenta la asignación previa de `err` como usada solo si el valor se lee antes de la siguiente asignación — en cadenas de manejo de error con `err =` múltiple, la primera asignación puede quedar sin leer. Solución: en cadenas largas de errores, usar `:=` en cada asignación nueva para que el scope sea claro, no reutilizar la variable `err` con `=`.
+
+## Checklist de diagnóstico
+
+- [ ] `go build ./...` para ver todos los errores de una vez
+- [ ] `go vet ./...` para detectar problemas de corrección
+- [ ] `go mod tidy` si hay errores de módulos
+- [ ] `go list -f '{{.IgnoredGoFiles}}' ./paquete/` para build constraints
+- [ ] `go build -race ./...` si hay sospechas de concurrencia
+- [ ] `staticcheck ./...` o `golangci-lint run` para análisis estático completo
+- [ ] Para import cycles: `go build ./... 2>&1 | grep cycle`
+
+## Referencias
+
+- [Go Build Constraints](https://pkg.go.dev/cmd/go#hdr-Build_constraints)
+- [Go Modules Reference](https://go.dev/ref/mod)
+- [staticcheck](https://staticcheck.dev/docs/checks)
+- [golangci-lint](https://golangci-lint.run/usage/linters/)
+
+---
+*Skill creado con swl:crear-skill el 2026-03-31. Versión 1.0.0.*

package/habilidades/build-errors-java/SKILL.md

@@ -0,0 +1,278 @@
+---
+name: build-errors-java
+description: >
+  Resolución de errores de compilación Java: javac, Maven, Gradle, conflictos
+  de dependencias, annotation processors y problemas de classpath. Cargar cuando
+  un build Java falle o haya errores de compilación o de dependencias.
+version: "1.0.0"
+herramientasPermitidas: [Read, Bash, Grep]
+exclusiones:
+  - "No cargar para errores de lógica de la aplicación Java en ejecución (NullPointerException, IllegalArgumentException en runtime) — el build compila exitosamente; el error es de lógica de negocio."
+  - "No cargar para fallos de tests unitarios (JUnit assertions incorrectas, Mockito stubs mal configurados) — si `mvn test-compile` pasa pero los tests fallan en assertions, no es un error de build."
+  - "No cargar para diseñar la arquitectura Maven multi-módulo desde cero — si la pregunta es cómo organizar módulos padre-hijo en un nuevo proyecto, cargar `java-patrones` o `java-experto`."
+  - "No cargar para errores de Spring Boot en contexto de arranque (ApplicationContext failed to load) que no son de compilación — si el JAR se construye pero `java -jar` falla, son errores de configuración de Spring, no de build."
+evolvable: true  # default para skill estandar
+---
+# Build Errors Java — Diagnóstico y Solución
+
+Los errores de build de Java pueden venir del compilador, del sistema de build
+(Maven/Gradle) o de las dependencias. Este skill cubre los errores más frecuentes
+con su causa exacta y la solución paso a paso.
+
+## Cuándo NO cargar
+
+- El build compila pero la aplicación falla en ejecución (NPE, ClassCastException) — no es un error de compilación; revisar la lógica directamente.
+- Los tests JUnit fallan por assertions incorrectas aunque compilan — es un error de lógica de tests.
+- La pregunta es cómo organizar el proyecto Maven multi-módulo — para diseño cargar `java-patrones`.
+
+## Cuándo cargar este skill
+
+Invoca `Skill("build-errors-java")` cuando:
+
+- `mvn compile` o `gradle build` falle con errores
+- Haya errores `cannot find symbol` o `package does not exist`
+- Existan conflictos de versión entre dependencias
+- Fallen los annotation processors (Lombok, MapStruct, etc.)
+- Haya errores de classpath en runtime después de un build exitoso
+
+## Conceptos clave
+
+### Separacion build-time vs runtime
+
+Algunos errores solo aparecen en runtime aunque el build compile correctamente.
+Las dependencias con scope `provided` o `compileOnly` no se incluyen en el
+artefacto final — si se necesitan en runtime, hay un ClassNotFoundException.
+
+### Dependency convergence en Maven/Gradle
+
+Cuando dos dependencias A y B requieren distintas versiones de C, el build
+necesita una sola versión. Maven usa la versión más cercana al POM raíz.
+Gradle usa la versión más alta. Ambos pueden introducir incompatibilidades.
+
+## Errores de javac — causa y solución
+
+### `error: cannot find symbol`
+
+**Causa**: La clase, método o variable referenciada no existe en el classpath
+en tiempo de compilación. Puede ser un typo, un import faltante, o una
+dependencia no declarada.
+
+**Diagnostico**:
+```bash
+# Ver el classpath completo que usa javac
+mvn dependency:build-classpath -Dmdep.outputFile=classpath.txt
+cat classpath.txt
+
+# O con Gradle
+./gradlew dependencies --configuration compileClasspath
+```
+
+**Soluciones**:
+1. Verificar que el import está presente en el archivo Java
+2. Verificar que la dependencia está en `pom.xml` / `build.gradle`
+3. Si es una clase generada (Lombok, QueryDSL), ejecutar `mvn generate-sources` primero
+
+### `error: package X does not exist`
+
+**Causa**: El paquete no está en el classpath. Diferente a `cannot find symbol`
+en que afecta al package entero, no a una clase específica.
+
+**Solucion**:
+```xml
+<!-- Maven: agregar la dependencia faltante -->
+<dependency>
+    <groupId>org.springframework.boot</groupId>
+    <artifactId>spring-boot-starter-web</artifactId>
+</dependency>
+```
+
+### `error: incompatible types: X cannot be converted to Y`
+
+**Causa**: Asignación o llamada con tipo incorrecto. Frecuente al mezclar
+tipos genéricos o al usar APIs que cambiaron su tipo de retorno.
+
+```java
+// Ejemplo: List<Object> no es asignable a List<String>
+List<String> nombres = new ArrayList<Object>(); // ERROR
+List<String> nombres = new ArrayList<>();       // OK — inferencia de tipo
+```
+
+### `error: unreported exception X; must be caught or declared to be thrown`
+
+**Causa**: Llamada a método que lanza checked exception sin catch ni declaración
+en la firma del método.
+
+```java
+// MAL — IOException no manejada
+public void leerArchivo(String ruta) {
+    Files.readString(Path.of(ruta)); // throws IOException
+}
+
+// BIEN — declarar o capturar
+public void leerArchivo(String ruta) throws IOException {
+    String contenido = Files.readString(Path.of(ruta));
+}
+```
+
+## Errores de Maven — causa y solución
+
+### `Could not resolve dependencies` / `Artifact not found`
+
+**Diagnostico**:
+```bash
+mvn dependency:resolve -U   # -U fuerza update de snapshots
+mvn dependency:tree         # ver el arbol de dependencias
+```
+
+**Causas y soluciones**:
+1. Repositorio no configurado: agregar en `pom.xml` o `settings.xml`
+2. Credenciales de repositorio privado incorrectas en `~/.m2/settings.xml`
+3. Artefacto realmente no existe: verificar en https://search.maven.org
+
+### `Plugin execution not covered by lifecycle configuration` (Eclipse/m2e)
+
+**Causa**: El plugin de Maven no tiene binding en m2e para Eclipse.
+**Solución**: Agregar `<pluginManagement>` en el pom para ignorar en m2e:
+
+```xml
+<pluginManagement>
+    <plugins>
+        <plugin>
+            <groupId>org.eclipse.m2e</groupId>
+            <artifactId>lifecycle-mapping</artifactId>
+            <version>1.0.0</version>
+            <configuration>
+                <lifecycleMappingMetadata>
+                    <pluginExecutions>
+                        <pluginExecution>
+                            <pluginExecutionFilter>
+                                <groupId>org.apache.maven.plugins</groupId>
+                                <artifactId>maven-enforcer-plugin</artifactId>
+                                <versionRange>[1.0,)</versionRange>
+                                <goals><goal>enforce</goal></goals>
+                            </pluginExecutionFilter>
+                            <action><ignore /></action>
+                        </pluginExecution>
+                    </pluginExecutions>
+                </lifecycleMappingMetadata>
+            </configuration>
+        </plugin>
+    </plugins>
+</pluginManagement>
+```
+
+### Conflictos de version — `NoSuchMethodError` en runtime
+
+**Diagnostico**:
+```bash
+mvn dependency:tree -Dverbose -Dincludes=com.fasterxml.jackson.core
+# Buscar lineas con "omitted for conflict"
+```
+
+**Solución con dependencyManagement**:
+```xml
+<dependencyManagement>
+    <dependencies>
+        <!-- Forzar versión única de Jackson en todo el proyecto -->
+        <dependency>
+            <groupId>com.fasterxml.jackson.core</groupId>
+            <artifactId>jackson-databind</artifactId>
+            <version>2.17.0</version>
+        </dependency>
+    </dependencies>
+</dependencyManagement>
+```
+
+## Errores de Gradle — causa y solución
+
+### `Could not resolve com.example:lib:1.0`
+
+**Diagnostico**:
+```bash
+./gradlew dependencies --configuration runtimeClasspath
+./gradlew dependencyInsight --dependency lib --configuration runtimeClasspath
+```
+
+**Solucion**: Verificar `repositories {}` en `build.gradle`:
+```kotlin
+repositories {
+    mavenCentral()
+    maven { url = uri("https://repo.empresa.com/maven2") }
+}
+```
+
+### `Execution failed for task ':compileJava'` — error de annotation processor
+
+**Causa frecuente**: Lombok o MapStruct no configurados como annotation processor.
+
+```kotlin
+// build.gradle.kts — configuración correcta de Lombok
+dependencies {
+    compileOnly("org.projectlombok:lombok:1.18.32")
+    annotationProcessor("org.projectlombok:lombok:1.18.32")
+    testCompileOnly("org.projectlombok:lombok:1.18.32")
+    testAnnotationProcessor("org.projectlombok:lombok:1.18.32")
+}
+```
+
+### Dependency locking — `FAILED` en version diferente a la bloqueada
+
+```bash
+# Actualizar el lock file cuando se cambian dependencias intencionalmente
+./gradlew dependencies --write-locks
+```
+
+## Errores de classpath en runtime
+
+### `ClassNotFoundException` o `NoClassDefFoundError`
+
+**Diferencia**:
+- `ClassNotFoundException`: la clase no está en el classpath — falta una jar
+- `NoClassDefFoundError`: la clase estaba en compilación pero no en runtime
+  — dependencia con scope `provided` no incluida en el fat jar
+
+**Solucion en Spring Boot**:
+```xml
+<!-- Cambiar scope de provided a compile si se necesita en el jar final -->
+<dependency>
+    <groupId>javax.servlet</groupId>
+    <artifactId>javax.servlet-api</artifactId>
+    <!-- Quitar: <scope>provided</scope> si el contenedor no lo provee -->
+</dependency>
+```
+
+### Multi-module projects — `Module not found`
+
+```bash
+# Compilar el módulo padre primero para que los módulos hijo lo encuentren
+mvn install -pl modulo-comun
+mvn compile -pl modulo-api
+
+# O compilar todo el reactor en orden
+mvn compile --projects modulo-comun,modulo-api
+```
+
+## Gotchas / Errores comunes no obvios
+
+- **Lombok `@Data` compila sin errores pero en runtime falla con `NoSuchMethodError` para los getters/setters**: el annotation processor de Lombok no está configurado en `annotationProcessor` de Gradle o en `<annotationProcessorPaths>` de Maven, solo en `compileOnly`. Causa: `compileOnly` incluye el JAR en el classpath de compilación pero no activa el processor, por lo que los métodos generados no existen. Solución: agregar Lombok tanto en `compileOnly` como en `annotationProcessor` (Gradle) o en `annotationProcessorPaths` del `maven-compiler-plugin` (Maven).
+- **`mvn dependency:tree` no muestra conflicto pero en runtime hay `ClassNotFoundException`**: la dependencia conflictiva está marcada con `provided` en el POM hijo pero `compile` en el padre. Causa: Maven elige el scope más restrictivo en jerarquía de módulos y la clase no llega al fat JAR final. Solución: ejecutar `mvn dependency:tree -Dincludes=grupo:artefacto:*:*` para ver todas las ocurrencias del artefacto con sus scopes en el árbol, y unificar a `compile` en el módulo que genera el ejecutable.
+- **Gradle Kotlin DSL (`build.gradle.kts`) reporta error de `Unresolved reference` en el bloque `dependencies`**: el IDE muestra el error pero `./gradlew build` compila bien. Causa: el IDE usa un análisis estático de Kotlin para el DSL que difiere del evaluador de Groovy/Kotlin de Gradle en runtime. Solución: ejecutar `./gradlew build --rerun-tasks` desde línea de comandos para confirmar si el error es real — si pasa, el error del IDE es un falso positivo del análisis estático; sincronizar el proyecto Gradle en el IDE.
+- **`cannot find symbol` apunta a una clase generada por MapStruct que sí existe en `target/generated-sources`**: el directorio de fuentes generadas no está incluido en el source set del compilador. Causa: algunos builds con Maven no agregan automáticamente `target/generated-sources/annotations` al source path. Solución: agregar explícitamente `<generatedSourcesDirectory>` en la configuración del `maven-compiler-plugin` o verificar que `build-helper-maven-plugin` incluye el directorio generado.
+
+## Checklist de diagnóstico
+
+- [ ] `mvn dependency:tree` o `./gradlew dependencies` para ver el árbol completo
+- [ ] Buscar "omitted for conflict" en el árbol de dependencias
+- [ ] Verificar que annotation processors están en `annotationProcessor`, no solo en `compileOnly`
+- [ ] `mvn compile -X` o `./gradlew compileJava --info` para log verbose
+- [ ] Para errores de runtime: verificar diferencia de scope `compile` vs `provided`
+- [ ] En builds multi-módulo: compilar dependencias en orden correcto
+
+## Referencias
+
+- [Maven Dependency Plugin](https://maven.apache.org/plugins/maven-dependency-plugin/)
+- [Gradle Dependency Management](https://docs.gradle.org/current/userguide/dependency_management.html)
+- [Lombok Setup](https://projectlombok.org/setup/gradle)
+
+---
+*Skill creado con swl:crear-skill el 2026-03-31. Versión 1.0.0.*