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
This commit is contained in:
2026-05-08 20:44:50 +02:00
parent bf8651020e
commit 25eefbd5e3
6 changed files with 279 additions and 255 deletions
+40 -67
View File
@@ -1,86 +1,59 @@
# Command: git branch (TBD)
Crea una rama de trabajo. **Nunca trabajar directamente en master.**
Wrapper sobre `tbd_branch_create_bash_infra`. La función del registry maneja toda la lógica determinista (verificar limpio, autodetectar master/main, pull --rebase, validar slug + número de issue, crear rama). Este comando solo decide los inputs.
Soporta dos tipos de rama:
- `issue/<NNNN>-<slug>` — para implementar un issue existente de `dev/issues/`
- `quick/<slug>` — para cambios pequeños sin issue asociado (fixes, config, docs, etc.)
## Inputs
Preguntar al usuario si el cambio esta asociado a un issue o no.
### Si es un issue:
- `issue_number`: numero de 4 digitos (e.g. `0020`)
- `slug`: nombre corto separado por guiones (e.g. `hot-reload`)
### Si es un cambio rapido (sin issue):
- `slug`: nombre corto descriptivo separado por guiones (e.g. `fix-typo-readme`)
## Flujo obligatorio
1. Verificar que estamos en master y limpio:
```bash
git branch --show-current
git status --short
```
Si no estamos en master, cambiar primero:
```bash
git checkout master
```
Si hay cambios sin commitear, **avisar al usuario** y no continuar hasta resolver.
2. Actualizar master desde remoto:
```bash
git pull --rebase
```
3. Crear la rama y cambiar a ella:
**Para issues:**
```bash
git checkout -b issue/<issue_number>-<slug>
```
Ejemplo: `git checkout -b issue/0013-hot-reload`
**Para cambios rapidos:**
```bash
git checkout -b quick/<slug>
```
Ejemplo: `git checkout -b quick/fix-typo-readme`
4. Confirmar al usuario:
## Uso
```
Rama `<nombre-rama>` creada desde master actualizado.
Puedes empezar a trabajar. Cuando termines, usa `/git-push` para integrar a master.
/git-branch # preguntar al usuario
/git-branch issue 0021 hot-reload
/git-branch quick fix-typo-readme
```
## Pasos del asistente
1. **Decidir modo e inputs**:
- Preguntar si el cambio está asociado a un issue o no.
- Si es issue: pedir `<NNNN>` (4 dígitos) y `<slug>` kebab-case.
- Si es quick: pedir `<slug>` kebab-case descriptivo.
2. **Llamar la función del registry**:
```bash
source /home/lucas/fn_registry/bash/functions/infra/tbd_branch_create.sh
tbd_branch_create issue 0021 hot-reload
# o
tbd_branch_create quick fix-typo-readme
```
La función:
- Verifica que el working tree esté limpio (aborta si dirty).
- Cambia a master/main (autodetecta).
- `git pull --rebase` desde la rama base.
- Valida `<NNNN>` (regex 4 dígitos) y `<slug>` (kebab-case ASCII).
- `git checkout -b <rama>`.
- Imprime confirmación.
## Convenciones
- **Formato de rama issue**: `issue/<NNNN>-<slug>` (siempre 4 digitos)
- **Formato de rama quick**: `quick/<slug>` (sin numero)
- **Ramas cortas**: idealmente horas, no dias
- **Una rama por issue**: no mezclar issues en la misma rama
- **Nunca pushear la rama al remoto**: el push se hace desde master despues del merge
- **No rebase interactivo**: si los commits son limpios desde el inicio, no reescribir historia
- **No commits WIP**: cada commit en la rama debe ser atomico y con mensaje real (ver convencion en `/git-push`)
- **Formato issue**: `issue/<NNNN>-<slug>` (4 dígitos siempre).
- **Formato quick**: `quick/<slug>` (sin número).
- **Ramas cortas**: idealmente horas, no días.
- **Una rama por issue**: no mezclar issues en la misma rama.
- **Nunca pushear la rama al remoto**: el push se hace desde master después del merge (ver `/git-push`).
- **No commits WIP**: cada commit atómico con mensaje real.
## Features multi-issue
Para features que no caben en una sola rama, usar sub-issues con sufijo letra:
Para features que no caben en una sola rama, sub-issues con sufijo letra:
```
issue/0015a-telegram-types
issue/0015b-telegram-client
issue/0015c-telegram-listener
issue/0015d-telegram-enable
```
Cada sub-rama sigue el mismo flujo: crear → implementar → merge --no-ff → delete.
El codigo parcial se protege con **feature flags** en `dev/feature_flags.json` (no con commits WIP).
Cada sub-rama sigue el mismo flujo. El código parcial se protege con **feature flags** en `dev/feature_flags.json`.
## Para tocar la lógica
Editar `tbd_branch_create_bash_infra` en `bash/functions/infra/tbd_branch_create.sh`, no este wrapper.