chore: sync local config — caveman plugin, command/skill tweaks

- settings.json: enable caveman marketplace+plugin, effortLevel=high
- commands/git-branch + git-push: refactor docs
- skills/parallel-fix-issues: SKILL.md + scripts updates

.claude/skills/parallel-fix-issues/SKILL.md

@@ -89,20 +89,27 @@ El prompt de cada agente debe incluir:
 3. **Contenido completo del issue** (copiar el markdown entero)
 4. **Instrucciones de ejecución** (ver template abajo)
 
-#### Detección del build tag
+#### Detección del stack y comandos build/test
 
-Antes de lanzar los agentes, detectar el build tag del proyecto para los comandos `go build`/`go test`:
+Antes de lanzar los agentes, detectar el stack del proyecto y los comandos correspondientes. La skill es **agnostica del lenguaje**: soporta Go, C++, Rust, Node, Python o cualquier otro stack via override.
 
-```bash
-# Heurísticas (en orden):
-# 1. grep en go files por comentarios //go:build <tag>
-# 2. Makefile con -tags <tag>
-# 3. README con mención explícita
-# Si no se encuentra ninguno, dejar la variable vacía (go build/test sin -tags)
-BUILD_TAG=$(grep -rh "//go:build " --include="*.go" . 2>/dev/null | head -1 | sed -E 's|^.*//go:build ([^ ]+).*|\1|' || true)
-```
+**Resolucion de comandos** (en orden de prioridad):
 
-Pasar `BUILD_TAG` al agente. Si está vacío, el agente usa `go build ./...` sin `-tags`.
+1. **Override explicito** del usuario (env vars `BUILD_CMD` y `TEST_CMD` o argumentos al invocar la skill).
+2. **Manifest opcional** `.parallel-fix-issues.yml` en la raiz del repo:
+   ```yaml
+   build: "cmake -S cpp -B cpp/build && cmake --build cpp/build -j"
+   test:  "ctest --test-dir cpp/build --output-on-failure"
+   ```
+3. **Auto-deteccion** segun ficheros raiz:
+   - `go.mod`         → `go build [-tags X] ./...`        + `go test [-tags X] ./...` (X auto-detectado de `//go:build`)
+   - `CMakeLists.txt` (raiz o `cpp/`) → `cmake -S <dir> -B <dir>/build -DCMAKE_BUILD_TYPE=Release && cmake --build <dir>/build -j` + `ctest --test-dir <dir>/build --output-on-failure || true`
+   - `Cargo.toml`     → `cargo build`                     + `cargo test`
+   - `package.json`   → `npm run build --if-present`      + `npm test --if-present`
+   - `pyproject.toml` / `setup.py` → (sin build)          + `pytest`
+4. Si nada se detecta, **preguntar al usuario** que comandos usar antes de continuar.
+
+**Mostrar al usuario los comandos resueltos** y pedir confirmacion antes de seguir. Pasar tanto `BUILD_CMD` como `TEST_CMD` (ya resueltos) al prompt de cada agente.
 
 #### Template de prompt para cada agente
 
@@ -117,13 +124,19 @@ Usa SIEMPRE esta ruta como prefijo en paths absolutos.
 Variable de conveniencia para comandos:
   W=<RUTA_ABSOLUTA_DEL_WORKTREE>
 
-## Build tag Go
+## Comandos build/test del proyecto
 
-BUILD_TAG=<VALOR_DETECTADO_O_VACIO>   # ej: fts5, goolm, o vacío
+BUILD_CMD=<COMANDO_RESUELTO>   # ej: "cmake -S cpp -B cpp/build && cmake --build cpp/build -j"
+TEST_CMD=<COMANDO_RESUELTO>    # ej: "ctest --test-dir cpp/build --output-on-failure"
 
-Úsalo solo si está definido:
-  GO_BUILD="go build ${BUILD_TAG:+-tags $BUILD_TAG} ./..."
-  GO_TEST="go test ${BUILD_TAG:+-tags $BUILD_TAG} ./..."
+Estos comandos ya estan resueltos por el orquestador (auto-deteccion, override o manifest
+.parallel-fix-issues.yml). Usalos tal cual desde la raiz del worktree:
+
+  Bash({ command: "cd $W && eval \"$BUILD_CMD\"", dangerouslyDisableSandbox: true })
+  Bash({ command: "cd $W && eval \"$TEST_CMD\"",  dangerouslyDisableSandbox: true })
+
+Si el issue requiere comandos adicionales (ej. `./fn index` tras añadir funciones, `npm install`,
+`uv sync`), ejecutalos antes/despues segun corresponda.
 
 ## Permisos
 
@@ -144,18 +157,20 @@ Sigue este flujo estrictamente:
 1. **Leer el issue** — ya lo tienes arriba, entiende objetivo, tareas y arquitectura.
 
 2. **Implementar todas las tareas** en orden:
-   - Respetar pure core / impure shell (pkg/ puro, shell/ impuro)
-   - Hacer commits atómicos por bloque lógico
+   - Respetar las convenciones del proyecto (pure core / impure shell si aplica)
+   - Hacer commits atomicos por bloque logico
    - Prefijos: feat:, fix:, test:, docs:, refactor:, chore:
-   - NO hacer commits WIP ni código a medias
+   - NO hacer commits WIP ni codigo a medias
    - Compilar frecuentemente:
-     Bash({ command: "cd $W && $GO_BUILD", dangerouslyDisableSandbox: true })
+     Bash({ command: "cd $W && eval \"$BUILD_CMD\"", dangerouslyDisableSandbox: true })
 
-3. **Tests obligatorios**:
-   - Escribir tests para todo código nuevo
+3. **Tests obligatorios** (en el lenguaje/framework apropiado del stack):
+   - Escribir tests para todo codigo nuevo. Usar el framework convencional del lenguaje:
+     Go → testing pkg, C++ → ctest/Catch2/gtest, Rust → cargo test, Python → pytest, etc.
    - Ejecutar:
-     Bash({ command: "cd $W && $GO_TEST", dangerouslyDisableSandbox: true })
+     Bash({ command: "cd $W && eval \"$TEST_CMD\"", dangerouslyDisableSandbox: true })
    - NO continuar si los tests fallan
+   - Si el issue requiere paso de indexacion u otros (ej. `./fn index`, `npm install`), ejecutarlo aqui
 
 4. **Cerrar el issue** — solo mover el archivo, NO tocar README:
    - Bash({ command: "cd $W && git mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/", dangerouslyDisableSandbox: true })
@@ -182,19 +197,22 @@ Después de cada wave, verificar TODOS los worktrees completados:
 ```
 
 El script verifica:
-- `go build ${BUILD_TAG:+-tags $BUILD_TAG} ./...` — compila sin errores
-- `go test ${BUILD_TAG:+-tags $BUILD_TAG} ./...` — tests pasan
+- `$BUILD_CMD` — compila sin errores (auto-detectado o pasado por env/arg)
+- `$TEST_CMD`  — tests pasan
 - Issue movido a `dev/issues/completed/`
 - Al menos 1 commit en la branch
 
-El script acepta `BUILD_TAG` como variable de entorno (detectada en Fase 3) o como segundo argumento:
+Pasar `BUILD_CMD` y `TEST_CMD` como variables de entorno o argumentos posicionales:
 
 ```bash
-BUILD_TAG=fts5 .claude/skills/parallel-fix-issues/scripts/verify-worktree.sh worktrees/<slug>
-# o
-.claude/skills/parallel-fix-issues/scripts/verify-worktree.sh worktrees/<slug> fts5
+BUILD_CMD="cmake --build cpp/build" TEST_CMD="ctest --test-dir cpp/build" \
+  .claude/skills/parallel-fix-issues/scripts/verify-worktree.sh worktrees/<slug>
+# o posicionales
+.claude/skills/parallel-fix-issues/scripts/verify-worktree.sh worktrees/<slug> "go build ./..." "go test ./..."
 ```
 
+Si no se pasan, el script auto-detecta el stack (go.mod, CMakeLists.txt, Cargo.toml, package.json, pyproject.toml).
+
 **Si un worktree falla verificación**:
 1. Reportar al usuario qué falló
 2. Preguntar si quiere: (a) intentar arreglar, (b) excluir ese issue, (c) abortar todo
@@ -213,13 +231,14 @@ El script hace para cada branch:
 2. `git merge --no-ff issue/<slug>` con mensaje descriptivo
 3. Si hay **merge conflict**: PARAR e informar al usuario
 
-**Después de cada merge**, re-verificar que master compila:
+**Despues de cada merge**, re-verificar que master compila usando los `BUILD_CMD`/`TEST_CMD` resueltos:
 
 ```bash
-go build ${BUILD_TAG:+-tags $BUILD_TAG} ./... && go test ${BUILD_TAG:+-tags $BUILD_TAG} ./...
+eval "$BUILD_CMD" && eval "$TEST_CMD"
 ```
 
-Si falla después de un merge, PARAR e informar — no continuar con más merges.
+`integrate-worktrees.sh` ya verifica el build post-merge si `BUILD_CMD` esta exportado.
+Si falla despues de un merge, PARAR e informar — no continuar con mas merges.
 
 ### Fase 6: Actualizar README de issues
 
@@ -275,7 +294,7 @@ Ejecutar: git push
 
 ## Notas importantes
 
-- **Build tag Go**: detectar del proyecto en Fase 3 (ver "Detección del build tag"). Si el proyecto no usa build tags, omitir `-tags` en todos los comandos
+- **Stack agnostico**: la skill detecta el stack (Go, C++, Rust, Node, Python) en Fase 3. Si la auto-deteccion falla o el proyecto es exotico, el usuario puede pasar `BUILD_CMD`/`TEST_CMD` por env var o crear `.parallel-fix-issues.yml` en la raiz. Si el proyecto no tiene build/test, esos pasos se omiten con WARN
 - **Siempre usar `dangerouslyDisableSandbox: true`** en todas las llamadas Bash de los agentes paralelos
 - **Nunca hacer push automáticamente** — el usuario decide cuándo pushear
 - **Si hay merge conflicts**, parar y pedir intervención manual