Files

T

egutierrez 877aeda1a1 docs: restaurar comandos Claude eliminados por error

Recupera los 4 comandos de .claude/commands/ que fueron eliminados
en ff7600d: create-issue, fix-issue, git-branch y git-push.
Son esenciales para el flujo TBD del proyecto.

2026-04-09 00:46:40 +00:00

2.3 KiB

Raw Permalink Blame History

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

Verificar que estamos en master y limpio:

git branch --show-current
git status --short

Si no estamos en master, cambiar primero:

git checkout master

Si hay cambios sin commitear, avisar al usuario y no continuar hasta resolver.

Actualizar master desde remoto:

git pull --rebase

Crear la rama y cambiar a ella:

Para issues:

git checkout -b issue/<issue_number>-<slug>

Ejemplo: git checkout -b issue/0013-hot-reload

Para cambios rapidos:

git checkout -b quick/<slug>

Ejemplo: git checkout -b quick/fix-typo-readme

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).

2.3 KiB Raw Permalink Blame History