diff --git a/.claude/commands/create-issue.md b/.claude/commands/create-issue.md
new file mode 100644
index 0000000..5b390d5
--- /dev/null
+++ b/.claude/commands/create-issue.md
@@ -0,0 +1,154 @@
+# Command: create issue
+
+Crea un issue nuevo en `dev/issues/` siguiendo **estrictamente** la regla `create_issue.md`. Si el issue es grande, lo desglosa automaticamente en sub-issues con feature flags.
+
+## Inputs
+
+Se necesitan los datos del issue. Si no se proporcionan, preguntar.
+
+- `titulo`: titulo corto y descriptivo (ej: "Hot reload de configuracion")
+- `descripcion`: objetivo/descripcion de lo que se quiere lograr
+- `dependencias` (opcional): issues de los que depende (ej: "Requiere issue 0010")
+
+## Flujo obligatorio
+
+### 1. Determinar el numero del issue
+
+Buscar el numero mas alto en `dev/issues/` y `dev/issues/completed/` y usar el siguiente.
+Formato: 4 digitos con ceros a la izquierda (`0023`, `0024`, etc.).
+
+```bash
+ls dev/issues/ dev/issues/completed/ | grep -oP '^\d{4}' | sort -rn | head -1
+```
+
+### 2. Generar slug
+
+A partir del titulo:
+- Lowercase
+- Palabras separadas por guiones
+- Conciso (2-4 palabras)
+- Ejemplo: "Hot reload de configuracion" → `hot-reload`
+
+### 3. Evaluar tamano del issue
+
+Antes de escribir el issue, analizar el alcance y determinar si cabe en **una sola rama corta (horas)**.
+
+**Criterios para desglosar en sub-issues:**
+- Toca mas de 2 capas del patron (pkg/ + shell/ + agents/ + tools/)
+- Requiere mas de ~3 fases de implementacion
+- El usuario lo indica explicitamente
+- La descripcion implica multiples componentes independientes
+
+**Si es un issue simple** (cabe en una rama):
+- Crear un solo archivo `dev/issues/<NNNN>-<slug>.md`
+- Seguir directo al paso 4
+
+**Si es un issue grande** (necesita desglose):
+- Crear el issue principal `dev/issues/<NNNN>-<slug>.md` con seccion `## Desglose multi-issue`
+- Crear cada sub-issue como `dev/issues/<NNNN><letra>-<sub-slug>.md` (ej: `0023a-types`, `0023b-client`)
+- Cada sub-issue es autocontenido: debe compilar, pasar tests, no romper master
+- Agregar feature flag en la descripcion del issue principal
+- Registrar todos los sub-issues en `dev/issues/README.md`
+
+### 4. Crear el issue desde el template
+
+Copiar `.claude/templates/issue.md` y rellenar **todas** las secciones:
+
+- **Objetivo**: 1-3 frases claras
+- **Contexto**: que existe, que falta, dependencias
+- **Arquitectura**: archivos afectados (marcar `NEW` los nuevos). Explicar que va en `pkg/` (puro) vs `shell/` (impuro)
+- **Tareas**: fases con tareas numeradas (`1.1`, `1.2`, etc.). Cada tarea concreta y verificable. Siempre incluir fase de tests y fase de cleanup/docs
+- **Ejemplo de uso**: flujo concreto
+- **Decisiones de diseno**: justificaciones clave
+- **Prerequisitos**: que debe existir antes
+- **Riesgos**: problemas potenciales y mitigacion
+
+### 5. Para issues multi-issue — contenido adicional
+
+En el issue principal, agregar despues de las tareas:
+
+```markdown
+## Desglose multi-issue
+
+Este issue se implementa en sub-issues independientes, cada uno en su propia rama.
+
+| Sub-issue | Rama | Alcance | Estado |
+|-----------|------|---------|--------|
+| <NNNN>a-<slug> | issue/<NNNN>a-<slug> | <que cubre> | pendiente |
+| <NNNN>b-<slug> | issue/<NNNN>b-<slug> | <que cubre> | pendiente |
+| ...
+
+### Feature flag
+
+Nombre: `<nombre-del-flag>`
+Se activa en el ultimo sub-issue cuando todo esta integrado.
+
+### Progreso por tarea
+
+- [ ] **1.1** <tarea> — sub-issue <NNNN>a
+- [ ] **1.2** <tarea> — sub-issue <NNNN>a
+- [ ] **2.1** <tarea> — sub-issue <NNNN>b
+...
+```
+
+Cada sub-issue individual debe tener su propio archivo con:
+- Objetivo especifico del sub-issue
+- Tareas que le corresponden del issue principal
+- Nota de que es parte de un issue mayor
+
+### 6. Registrar feature flag (solo multi-issue)
+
+Actualizar `dev/feature_flags.json`:
+
+```json
+{
+  "<nombre-del-flag>": {
+    "enabled": false,
+    "issue": "<NNNN>",
+    "description": "<descripcion breve>",
+    "added": "<YYYY-MM-DD>"
+  }
+}
+```
+
+### 7. Actualizar el indice
+
+En `dev/issues/README.md`, agregar filas al final de la tabla.
+
+**Issue simple:**
+```markdown
+| <N> | <Titulo> | [<NNNN>-<slug>.md](<NNNN>-<slug>.md) | pendiente |
+```
+
+**Issue multi-issue (agregar fila por cada sub-issue tambien):**
+```markdown
+| <N>  | <Titulo>           | [<NNNN>-<slug>.md](<NNNN>-<slug>.md)   | pendiente |
+| <N>a | <Titulo> (parte a) | [<NNNN>a-<slug>.md](<NNNN>a-<slug>.md) | pendiente |
+| <N>b | <Titulo> (parte b) | [<NNNN>b-<slug>.md](<NNNN>b-<slug>.md) | pendiente |
+```
+
+### 8. Verificar
+
+- [ ] Archivo(s) creado(s) en `dev/issues/`
+- [ ] Todas las secciones del template rellenadas
+- [ ] Fila(s) agregada(s) en `dev/issues/README.md`
+- [ ] Numero de issue es consecutivo (sin saltos ni duplicados)
+- [ ] Si es multi-issue: sub-issues creados, feature flag en `dev/feature_flags.json`, seccion de desglose en issue principal
+
+### 9. Reportar al usuario
+
+Mostrar resumen:
+- Numero y titulo del issue
+- Si fue desglosado: listar sub-issues con su alcance
+- Recordar: usar `/fix-issue <NNNN>` (o `/fix-issue <NNNN>a`, `<NNNN>b`, etc.) para implementar
+
+## Reglas criticas
+
+- Seguir `create_issue.md` de forma estricta
+- **Patron pure core / impure shell**: toda feature debe explicar que va en `pkg/` vs `shell/`
+- **Tareas atomicas**: cada tarea debe ser implementable de forma independiente
+- **Numeracion continua**: nunca reusar numeros
+- **Estado**: issues nuevos siempre `pendiente`
+- **Issues grandes**: desglosar en sub-issues con feature flags, nunca dejar una rama abierta por dias
+- **Feature flag != WIP**: un flag protege codigo terminado y testeado, no codigo a medias
+- **No commitear**: este comando solo crea archivos en `dev/issues/`. No hace commits ni crea ramas
diff --git a/.claude/commands/fix-issue.md b/.claude/commands/fix-issue.md
new file mode 100644
index 0000000..2022d32
--- /dev/null
+++ b/.claude/commands/fix-issue.md
@@ -0,0 +1,96 @@
+# Command: fix issue
+
+Ejecuta de punta a punta el flujo de implementacion/cierre de un issue siguiendo **estrictamente** la regla `fix_issue.md`.
+
+## Inputs
+
+Se necesita el issue objetivo. Si no se proporciona, preguntar.
+
+- `issue`: numero o nombre (ej: `0010` o `0010-access-control`)
+
+## Flujo obligatorio
+
+1. Resolver el issue objetivo:
+
+- Si viene solo numero (`0010`), buscar `dev/issues/0010-*.md`.
+- Si viene slug completo (`0010-access-control`), usar `dev/issues/0010-access-control.md`.
+- Si no existe en `dev/issues/`, **STOP** e informar al usuario.
+- Si ya esta en `dev/issues/completed/`, **STOP** e informar al usuario.
+
+2. Leer completo el issue y extraer:
+
+- objetivo
+- tareas/fases
+- arquitectura y limites (pure core / impure shell)
+
+3. Crear rama de trabajo (inline, sin invocar `/git-branch`):
+
+Verificar la rama actual:
+
+```bash
+git branch --show-current
+```
+
+- Si ya estamos en `issue/<NNNN>-<slug>` que coincide con el issue → continuar directamente a paso 4.
+- Si estamos en `master` o cualquier otra rama → crear la rama:
+
+```bash
+git checkout master
+git pull --rebase
+git checkout -b issue/<NNNN>-<slug>
+```
+
+Nunca trabajar directamente en `master`.
+
+4. Planificar con `TodoWrite`:
+
+- Crear plan basado en las tareas del issue.
+- Respetar el orden de fases.
+- Incluir siempre una tarea de tests.
+
+5. Implementar el issue completo:
+
+- Ejecutar tareas en orden.
+- Respetar pure core / impure shell (`pkg/` puro, `shell/` impuro).
+- Compilar frecuentemente: `go build -tags goolm ./...`.
+- Marcar progreso en `TodoWrite` al completar cada bloque.
+
+6. Tests obligatorios:
+
+```bash
+go test -tags goolm ./...
+```
+
+- Si falla, corregir antes de continuar.
+- No cerrar el issue sin tests pasando.
+
+7. Feature flags (si aplica):
+
+- Evaluar si es feature multi-issue o despliegue gradual.
+- Si aplica, actualizar `dev/feature_flags.json` en el commit correspondiente.
+- No usar flags para esconder codigo incompleto.
+
+8. Cerrar el issue al terminar:
+
+```bash
+mv dev/issues/<NNNN>-<slug>.md dev/issues/completed/
+```
+
+Actualizar `dev/issues/README.md`:
+
+- Link a `completed/<NNNN>-<slug>.md`
+- Estado a `completado`
+
+9. Integrar/publicar con `/git-push`:
+
+```text
+/git-push
+```
+
+## Reglas criticas
+
+- Seguir `fix_issue.md` de forma estricta.
+- No saltear tareas del issue.
+- No hacer commits WIP.
+- Commits atomicos por bloque logico (`feat:`, `fix:`, `test:`, `docs:`, `refactor:`, `chore:`).
+- Siempre usar `-tags goolm` en build/test.
\ No newline at end of file
diff --git a/.claude/commands/git-branch.md b/.claude/commands/git-branch.md
new file mode 100644
index 0000000..b2c6074
--- /dev/null
+++ b/.claude/commands/git-branch.md
@@ -0,0 +1,86 @@
+# Command: git branch (TBD)
+
+Crea una rama de trabajo. **Nunca trabajar directamente en master.**
+
+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:
+
+```
+Rama `<nombre-rama>` creada desde master actualizado.
+Puedes empezar a trabajar. Cuando termines, usa `/git-push` para integrar a master.
+```
+
+## 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`)
+
+## Features multi-issue
+
+Para features que no caben en una sola rama, usar 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).
diff --git a/.claude/commands/git-push.md b/.claude/commands/git-push.md
new file mode 100644
index 0000000..89ba52c
--- /dev/null
+++ b/.claude/commands/git-push.md
@@ -0,0 +1,157 @@
+# Command: git push
+
+Integra cambios a master y publica. Soporta ramas `issue/*` y `quick/*`.
+
+## Flujo obligatorio
+
+### 1. Verificar rama actual y estado
+
+```bash
+git branch --show-current
+git status --short
+```
+
+#### Si estamos en una rama `issue/*` o `quick/*`
+
+Continuar directamente al paso 2.
+
+#### Si estamos en `master` con cambios pendientes
+
+Crear una rama automaticamente antes de continuar:
+
+1. Preguntar al usuario: **¿Este cambio esta asociado a un issue existente?**
+2. **Si es un issue**: pedir el numero y slug, crear rama `issue/<NNNN>-<slug>`.
+3. **Si NO es un issue**: pedir un slug descriptivo, crear rama `quick/<slug>`.
+
+```bash
+# Para issues:
+git checkout -b issue/<NNNN>-<slug>
+# Para cambios rapidos:
+git checkout -b quick/<slug>
+```
+
+4. Continuar al paso 2 con los cambios ya en la rama nueva.
+
+**IMPORTANTE**: No inventar numeros de issue. Solo usar `issue/` si el issue existe en `dev/issues/`.
+
+#### Si estamos en `master` sin cambios
+
+**STOP**: no hay nada que publicar.
+
+### 2. Revisar cambios y crear commits por bloque
+
+```bash
+git status --short
+git diff --stat
+git diff
+```
+
+Crear commits **atomicos por bloque logico**. Cada commit agrupa cambios de la misma naturaleza:
+
+```bash
+git add <archivos_del_bloque_1>
+git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol explicando que cambia, por que se hizo, impacto esperado y alcance del bloque."
+
+git add <archivos_del_bloque_2>
+git commit -m "<tipo>: <resumen breve>" -m "Descripcion larga en espanol."
+```
+
+**Reglas criticas de commits:**
+- **No WIP**: nunca commitear "wip", "tmp", "fix fix" ni codigo a medias. Cada commit debe ser atomico y completo.
+- **No mezclar tipos**: no combinar `feat:` + `test:` en un mismo commit. Separar por bloque logico.
+- **No squash**: los commits individuales se preservan en master via `--no-ff`. Usar `git log --first-parent master` para ver solo merge commits.
+- **No rebase interactivo**: si los commits ya son limpios, no reescribir historia.
+
+### 3. Ejecutar tests
+
+**Obligatorio antes de mergear.** Si el proyecto tiene tests, ejecutarlos:
+
+```bash
+go test -tags goolm ./...
+```
+
+- Si los tests **fallan** → **STOP**: corregir antes de continuar. No mergear codigo roto.
+- Si los tests **pasan** → continuar al paso 4.
+- Si no hay tests aplicables (e.g. solo cambios de docs/config) → indicar al usuario y continuar.
+
+### 4. Evaluar feature flags
+
+Feature flags se usan cuando el issue es **parte de una feature multi-issue** o el cambio tiene riesgo y necesita poder desactivarse. **Feature flag ≠ WIP** — un flag protege codigo terminado y testeado, no codigo a medias.
+
+Si se modifico `dev/feature_flags.json` o si los cambios son parte de una feature que se despliega en fases:
+
+1. Verificar que `dev/feature_flags.json` existe y esta actualizado.
+2. Confirmar que el flag correspondiente tiene el estado correcto (`enabled: true/false`).
+3. Incluir el archivo en el commit correspondiente (no crear commit separado solo para flags).
+
+Si el issue es autocontenido (se completa en esta rama), no necesita flag. Saltar este paso.
+
+### 5. Actualizar master y hacer merge --no-ff
+
+```bash
+git checkout master
+git pull --rebase
+git merge --no-ff <rama> -m "merge: <rama> — <titulo breve>"
+```
+
+El merge commit debe tener formato:
+- Titulo: `merge: <rama> — <descripcion corta>`
+- Cuerpo (opcional): resumen de lo que entra
+
+Ejemplos:
+- `merge: issue/0021-threads-default-config — habilitar threads en agentes`
+- `merge: quick/fix-typo-readme — corregir typo en README`
+
+Si hay conflictos durante el merge:
+1. Resolver los conflictos
+2. `git add` los archivos resueltos
+3. `git commit` (sin -m, para mantener el mensaje de merge)
+
+### 6. Push a remoto
+
+```bash
+git push
+```
+
+### 7. Limpiar rama local
+
+```bash
+git branch -d <rama>
+```
+
+### 8. Confirmar al usuario
+
+```
+Rama `<rama>` integrada a master y publicada.
+Rama local eliminada.
+```
+
+## Convencion de commits
+
+- `feat:` nueva funcionalidad
+- `fix:` correccion de error
+- `refactor:` cambio estructural sin cambio funcional
+- `docs:` documentacion
+- `chore:` mantenimiento
+- `test:` tests nuevos o modificados
+- `merge:` commit de merge (generado por --no-ff)
+
+## Regla de mensajes
+
+- El titulo (`-m` corto) debe resumir el bloque.
+- El cuerpo (`-m` largo) debe estar en espanol y explicar:
+  - que se cambio,
+  - por que se cambio,
+  - que impacto tiene,
+  - que no se toco.
+
+## Checklist rapido
+
+- [ ] Todos los cambios estan commiteados en una rama `issue/*` o `quick/*`.
+- [ ] Se separaron cambios distintos en commits diferentes.
+- [ ] Cada commit tiene descripcion larga en espanol.
+- [ ] Tests ejecutados y pasando (o no aplican).
+- [ ] Feature flags evaluados (o no aplican).
+- [ ] `git merge --no-ff` ejecutado desde master.
+- [ ] `git push` ejecutado correctamente.
+- [ ] Rama local eliminada.